docs(contribution-guidelines): add github issue and pull request guidelines and templates

[JeremyFriesenGitHub]

Description

Describe the PR with the following guidelines

What changes does this PR add?

This PR adds PR guidelines and a PR checklist to the writing documentation page on the docs site. Additionally, PR templates have also been created as well (in the .github directory).

Why do we need to add to the docs? How does this PR address the issue(s)?

This tries to attempt to make decent writing guidelines and solve the todo's for that page specifically. Automated PR templates are also a must and can help create contribution consistency among developpers.

Dependency Changes (if applicable)

N/A

Before and After Screenshots (if applicable)

Here is a before and after for the writing documentation page:

Before	After

Additional comments (if applicable)

I've put this in draft because I wanted input on this so far (in terms of frontend layout, resources that we can use, etc.) I know right now this is not very pretty (nor perhaps as informative as it should be). Its definitely an issue I think that takes a strong second opinion for review. This is linked to issue #77. Issue #78 is also very likely to be incorporated into this PR as well, since its similar and also a todo for the writing documentation.

Summary by Sourcery

Enhance the contribution guidelines by adding comprehensive pull request guidelines, issue guidelines, and templates for features, tests, and documentation. Update the documentation to include a checklist for code quality and PR review, and remove the outdated pull request template.

Documentation:

• Add detailed guidelines for creating pull requests, including a checklist for code quality and PR review, to the contribution guidelines documentation.
• Introduce a section on finding the correct type for commits, issues, and pull requests, with definitions for various types like fix, feat, docs, test, chore, style, refactor, perf, build, ci, and revert.
• Provide guidelines for writing GitHub issues, including title, description, labels, and assignees.

Chores:

• Remove the old pull request template file from the .github directory.

Summary by CodeRabbit

• New Features

  • Introduced a "Pull Request Guidelines" section detailing best practices for submitting PRs.
  • Added a "Pull Request Checklist" to assist contributors in ensuring code quality before submission.

• Documentation

  • Enhanced documentation guidelines with a focus on categorizing contributions and best practices for writing GitHub issues.
  • Removed the "index" page from the navigation of the Contribution Guidelines and Knowledge Base sections to improve clarity and user navigation.
  • Simplified the Tools Overview documentation structure by removing the "pages" key from the metadata.

[netlify]

❌ Deploy Preview for cuhacking-portal-dev failed. Why did it fail? →

Name	Link
🔨 Latest commit	08212ab
🔍 Latest deploy log	https://app.netlify.com/sites/cuhacking-portal-dev/deploys/66e51e3b52958c00083a91a0

[JeremyFriesenGitHub]

i think for the most part (issues + prs + commits including), ppl don't know the correct type to use (difference between a fix vs a chore), so I think clearly explaining/defining them in a page would be very beneficial. A decision chart could also be helpful with this as well..

[JeremyFriesenGitHub]

I'm also wondering what is the convention when naming issues (perhaps even prs as well), the templates currently setup [Type] but I don't know if this should be the standard or not (considering that some have also been named similar to their PRs).

[JeremyFriesenGitHub]

I'm also wondering what is the convention when naming issues (perhaps even prs as well), the templates currently setup [Type] but I don't know if this should be the standard or not (considering that some have also been named similar to their PRs).

this would also help with maybe creating more issue templates as well

[MFarabi619]

I'm also wondering what is the convention when naming issues (perhaps even prs as well), the templates currently setup [Type] but I don't know if this should be the standard or not (considering that some have also been named similar to their PRs).

What I was thinking is to keep it simple like:

Issue:

feat(ui/portal): add sign in button to navbar

PR:

feat(ui/portal): add sign in button to navbar

Branch:

jfriesen/feat-ui-portal/84-add-sign-in-button-to-navbar

or

jfriesen/feat/ui/portal/84-add-sign-in-button-to-navbar

Let me know what you think

[JeremyFriesenGitHub]

I'm also wondering what is the convention when naming issues (perhaps even prs as well), the templates currently setup [Type] but I don't know if this should be the standard or not (considering that some have also been named similar to their PRs).

What I was thinking is to keep it simple like:

Issue:

feat(ui/portal): add sign in button to navbar

PR:

feat(ui/portal): add sign in button to navbar

Branch:

jfriesen/feat-ui-portal/84-add-sign-in-button-to-navbar

or

jfriesen/feat/ui/portal/84-add-sign-in-button-to-navbar

Let me know what you think

Ok cool, it was just issues I was wondering about. Also, I didn't know that scopes could be included in branches. Would that be recommended, or is just listing name/type/issue-number-and-name ok?

[MFarabi619]

@sourcery-ai review

[sourcery-ai]

Reviewer's Guide by Sourcery

This pull request adds comprehensive guidelines for creating pull requests, issues, and templates to improve the contribution process. It includes changes to the documentation and introduces new PR templates.

File-Level Changes

Change	Details	Files
Added detailed pull request guidelines and checklist	Introduced guidelines for creating pull requests Added a PR checklist covering code quality and review aspects Included instructions for different types of PRs (features, tests, docs) Provided guidance on PR titles and descriptions	apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx
Enhanced documentation on writing guidelines and issue types	Added definitions for different types of contributions (fix, feat, docs, etc.) Included guidelines for creating GitHub issues Updated TODO list for remaining documentation tasks	apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx
Created pull request templates for different contribution types	Added template for documentation PRs Added template for feature PRs Added template for test PRs Removed old PR template	.github/PULL_REQUEST_TEMPLATE/docs.md .github/PULL_REQUEST_TEMPLATE/feature.md .github/PULL_REQUEST_TEMPLATE/test.md .github/PULL_REQUEST_TEMPLATE/pull_request_template_1.md

---

Tips

• Trigger a new Sourcery review by commenting @sourcery-ai review on the pull request.
• Continue your discussion with Sourcery by replying directly to review comments.
• You can change your review settings at any time by accessing your dashboard:
  • Enable or disable the Sourcery-generated pull request summary or reviewer's guide;
  • Change the review language;
• You can always contact us if you have any questions or feedback.

[sourcery-ai]

Hey @JeremyFriesenGitHub - I've reviewed your changes - here's some feedback:

Overall Comments:

• Consider simplifying the PR templates slightly to focus on the most critical information. This could help prevent overwhelming new contributors.
• The GitHub issues guidelines section is incomplete. Please finish documenting the guidelines for issue titles and descriptions.

Here's what I looked at during the review

• 🟡 General issues: 2 issues found
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.}

[coderabbitai]

Walkthrough

Walkthrough

The changes involve the removal of the "index" page from the meta.json files across various documentation sections, including Contribution Guidelines, Knowledge Base, and Tools Overview. Additionally, a new section titled "Pull Request Guidelines" has been introduced in the Contribution Guidelines, detailing best practices and a checklist for contributors when submitting pull requests. These modifications indicate a restructuring of the documentation to enhance clarity and usability.

Changes

Files	Change Summary
apps/docs/src/content/docs/contribution-guidelines/meta.json, apps/docs/src/content/docs/knowledge-base/meta.json, apps/docs/src/content/docs/tools-overview/meta.json	Removed the "index" page from the pages array in the meta.json files, indicating a shift in documentation structure and navigation.
apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx	Added a new section titled "Pull Request Guidelines," outlining best practices, templates, and a checklist for PR submissions.

Possibly related PRs

• test(docs-e2e): add mobile and tablet tests for docs site #73: The changes in this PR involve enhancements to the documentation site, including mobile and tablet layout tests, which relate to the main PR's focus on improving documentation contributions and clarity through structured templates.

Suggested labels

testing

Poem

🐇 In the garden of code, we hop and we play,
With templates and guidelines, we brighten the way.
Each pull request crafted, with care and delight,
Together we flourish, our project takes flight!
So let’s share our changes, both big and small,
A community thriving, together we’ll stand tall! 🌼

Tip

OpenAI O1 model for chat

• We have deployed OpenAI's latest O1 model for chat.
• OpenAI claims that this model has superior reasoning capabilities than their GPT-4o model.
• Please share any feedback with us in the discussions post.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 8

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 82b03db and 515bbb1.

Files selected for processing (5)

• .github/PULL_REQUEST_TEMPLATE/docs.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/feature.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/test.md (1 hunks)
• apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx (1 hunks)
• apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx (1 hunks)

Files skipped from review due to trivial changes (3)

• .github/PULL_REQUEST_TEMPLATE/docs.md
• .github/PULL_REQUEST_TEMPLATE/feature.md
• .github/PULL_REQUEST_TEMPLATE/test.md

Additional context used

LanguageTool

apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx

[uncategorized] ~27-~27: Possible missing article found.
Context: ...t for making sure your contributions to project are in the right format! Finding the ...

(AI_HYDRA_LEO_MISSING_THE)

---

[style] ~54-~54: Using many exclamation marks might seem excessive (in this case: 4 exclamation marks for a text that’s 1298 characters long)
Context: ... the correct type for your contributions! ## GitHub issues guidelines GitHub is...

(EN_EXCESSIVE_EXCLAMATION)

apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx

[uncategorized] ~13-~13: It appears that hyphens are missing in the adjective “up-to-date”.
Context: ...quest. This ensures that your branch is up to date with the latest changes in the main bra...

(UP_TO_DATE_HYPHEN)

---

[style] ~15-~15: ‘exact same’ might be wordy. Consider a shorter alternative.
Context: ...ue per pull request, and always use the exact same PR title as the issue name. This makes ...

(EN_WORDINESS_PREMIUM_EXACT_SAME)

---

[style] ~15-~15: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...b.com/jesseduffield/lazygit) makes this very quick and easy to do cleanly. ## Pull Reques...

(EN_WEAK_ADJECTIVE)

Additional comments not posted (2)

apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx (1)

23-55: Excellent addition for contribution clarity.

The "Finding Your Type" section is a valuable addition, providing clear definitions and examples for different types of contributions. This will greatly assist contributors in categorizing their work correctly.

Tools

LanguageTool

[uncategorized] ~27-~27: Possible missing article found.
Context: ...t for making sure your contributions to project are in the right format! Finding the ...

(AI_HYDRA_LEO_MISSING_THE)

---

[style] ~54-~54: Using many exclamation marks might seem excessive (in this case: 4 exclamation marks for a text that’s 1298 characters long)
Context: ... the correct type for your contributions! ## GitHub issues guidelines GitHub is...

(EN_EXCESSIVE_EXCLAMATION)

apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx (1)

11-12: Consider updating the phrasing for clarity.

The phrase "Always simple rebase" might be confusing. Consider rephrasing to enhance clarity:

-Always simple rebase your branch onto main before creating a pull request.
+Always perform a simple rebase of your branch onto main before creating a pull request.

This change clarifies the action to be taken and aligns with common documentation standards.

Likely invalid or redundant comment.

[coderabbitai]

Caution

Inline review comments failed to post

Actionable comments posted: 1

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 515bbb1 and 9aad86e.

Files selected for processing (5)

• .github/PULL_REQUEST_TEMPLATE/docs.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/feature.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/test.md (1 hunks)
• apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx (1 hunks)
• apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx (1 hunks)

Files skipped from review due to trivial changes (2)

• .github/PULL_REQUEST_TEMPLATE/feature.md
• .github/PULL_REQUEST_TEMPLATE/test.md

Files skipped from review as they are similar to previous changes (1)

• .github/PULL_REQUEST_TEMPLATE/docs.md

Additional context used

LanguageTool

apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx

[uncategorized] ~30-~30: You might be missing the article “the” here.
Context: ...t for making sure your contributions to project are in the right format! Finding the ...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

Additional comments not posted (4)

apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx (2)

26-49: Well-structured contribution types section.

The new section "Finding Your Type" is well-structured and provides clear definitions for various types of contributions, which will help contributors categorize their contributions accurately.

Tools

LanguageTool

[uncategorized] ~30-~30: You might be missing the article “the” here.
Context: ...t for making sure your contributions to project are in the right format! Finding the ...

(AI_EN_LECTOR_MISSING_DETERMINER_THE)

---

50-57: Clear and actionable GitHub issues guidelines.

The new section "GitHub issues guidelines" provides clear and actionable guidelines for writing GitHub issues, enhancing the usability of the documentation and aligning with the PR objectives.

apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx (2)

11-13: Essential guidance on rebasing.

The section "Always Simple Rebase" provides essential guidance on rebasing onto main before creating a PR, aligning with best practices for maintaining a clean and up-to-date branch history.

---

17-113: Comprehensive PR guidelines and checklist.

The sections "Pull Request Guidelines" and "Pull Request Checklist" provide comprehensive guidance and a structured checklist for creating PRs. These enhancements align with the PR objectives to streamline PR submissions and improve collaboration within the project.

Comments failed to post (1)

apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx (1)

22-25: Reminder: Address or update the TODO comment.

The TODO comment lists important tasks related to project management setup. It's crucial to address these tasks to ensure proper project management and communication channels are established.

Would you like me to help update this section or track the completion of these tasks in a project management tool?

[coderabbitai]

Actionable comments posted: 1

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 9aad86e and bc29510.

Files selected for processing (5)

• .github/PULL_REQUEST_TEMPLATE/docs.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/feature.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/test.md (1 hunks)
• apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx (1 hunks)
• apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx (1 hunks)

Files skipped from review due to trivial changes (3)

• .github/PULL_REQUEST_TEMPLATE/docs.md
• .github/PULL_REQUEST_TEMPLATE/feature.md
• .github/PULL_REQUEST_TEMPLATE/test.md

Files skipped from review as they are similar to previous changes (1)

• apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx

Additional context used

LanguageTool

apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx

[uncategorized] ~30-~30: Possible missing article found.
Context: ...t for making sure your contributions to project are in the right format! Finding the ...

(AI_HYDRA_LEO_MISSING_THE)

Additional comments not posted (3)

apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx (3)

22-25: Address the TODO for project management setup.

The TODO at lines 22-25 mentions important setup tasks that need to be completed. It's crucial to address these to ensure proper project management and communication channels are established. This aligns with the previous comment by coderabbitai[bot] and remains relevant.

---

26-49: Review and approve the new section "Finding Your Type".

This new section provides clear definitions and examples for various contribution types, which is a significant enhancement to the documentation. It aligns well with the PR objectives and addresses the concerns raised in the comments about clarifying the differences between types like "fix" and "chore". The structured format and examples will aid contributors in accurately categorizing their contributions.

Tools

LanguageTool

[uncategorized] ~30-~30: Possible missing article found.
Context: ...t for making sure your contributions to project are in the right format! Finding the ...

(AI_HYDRA_LEO_MISSING_THE)

---

50-57: Review and approve the "GitHub issues guidelines" section.

The new section on GitHub issues guidelines at lines 50-57 offers detailed advice on crafting titles, descriptions, using labels, and assigning issues. This section enhances the usability of the documentation by providing clear, actionable guidelines for contributors, which can lead to more effective project management and communication. The inclusion of an example issue link at line 59 is a practical addition, providing a real-world application of these guidelines.

[MFarabi619]

I'm also wondering what is the convention when naming issues (perhaps even prs as well), the templates currently setup [Type] but I don't know if this should be the standard or not (considering that some have also been named similar to their PRs).

What I was thinking is to keep it simple like:

Issue:

feat(ui/portal): add sign in button to navbar

PR:

feat(ui/portal): add sign in button to navbar

Branch:

jfriesen/feat-ui-portal/84-add-sign-in-button-to-navbar
or
jfriesen/feat/ui/portal/84-add-sign-in-button-to-navbar
Let me know what you think

Ok cool, it was just issues I was wondering about. Also, I didn't know that scopes could be included in branches. Would that be recommended, or is just listing name/type/issue-number-and-name ok?

Yes scopes could be included in branches. I'm not sure how recommended it would be, I haven't seen many projects do it. It does give us more specificity into what the purpose of the branch is though; the challenge is that if the issue name changes we now need to propagate those changes to the PR and the branch as well.

What do you think?

[coderabbitai]

Actionable comments posted: 1

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 189186d and b7bc781.

Files selected for processing (19)

• .github/ISSUE_TEMPLATE/architectural-design-record--adr-.md (1 hunks)
• .github/ISSUE_TEMPLATE/bug_report.md (1 hunks)
• .github/ISSUE_TEMPLATE/build.md (1 hunks)
• .github/ISSUE_TEMPLATE/chore.md (2 hunks)
• .github/ISSUE_TEMPLATE/ci.md (1 hunks)
• .github/ISSUE_TEMPLATE/docs.md (1 hunks)
• .github/ISSUE_TEMPLATE/feature.md (2 hunks)
• .github/ISSUE_TEMPLATE/perf.md (1 hunks)
• .github/ISSUE_TEMPLATE/test.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/build.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/chore.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/ci.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/docs.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/feature.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/fix.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/perf.md (1 hunks)
• .github/PULL_REQUEST_TEMPLATE/test.md (1 hunks)
• apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx (1 hunks)
• apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx (1 hunks)

Files skipped from review due to trivial changes (16)

• .github/ISSUE_TEMPLATE/architectural-design-record--adr-.md
• .github/ISSUE_TEMPLATE/build.md
• .github/ISSUE_TEMPLATE/chore.md
• .github/ISSUE_TEMPLATE/ci.md
• .github/ISSUE_TEMPLATE/docs.md
• .github/ISSUE_TEMPLATE/feature.md
• .github/ISSUE_TEMPLATE/perf.md
• .github/ISSUE_TEMPLATE/test.md
• .github/PULL_REQUEST_TEMPLATE/build.md
• .github/PULL_REQUEST_TEMPLATE/chore.md
• .github/PULL_REQUEST_TEMPLATE/ci.md
• .github/PULL_REQUEST_TEMPLATE/docs.md
• .github/PULL_REQUEST_TEMPLATE/feature.md
• .github/PULL_REQUEST_TEMPLATE/fix.md
• .github/PULL_REQUEST_TEMPLATE/perf.md
• .github/PULL_REQUEST_TEMPLATE/test.md

Additional context used

LanguageTool

apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx

[style] ~48-~48: Using many exclamation marks might seem excessive (in this case: 4 exclamation marks for a text that’s 2896 characters long)
Context: ... the correct type for your contributions! ## GitHub issues guidelines GitHub is...

(EN_EXCESSIVE_EXCLAMATION)

apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx

[uncategorized] ~13-~13: A comma might be missing here.
Context: ...R rules are set up for the repo just in case as a guardrail. Do your best to close ...

(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)

Additional comments not posted (6)

.github/ISSUE_TEMPLATE/bug_report.md (2)

4-4: Improved title format for bug reports.

The change to the title format encourages more descriptive bug reports, which can help in quicker identification and resolution of issues.

---

5-5: Automatic labeling for bug reports.

Setting the label to 'bug' automatically categorizes bug reports appropriately, aiding in efficient issue tracking and management.

apps/docs/src/content/docs/contribution-guidelines/writing-documentation.mdx (2)

26-47: Clear guidance on categorizing contributions.

The new section "Finding Your Type" provides clear definitions and examples for various types of contributions, enhancing the clarity and usability of the documentation.

---

50-57: Enhanced guidelines for GitHub issues.

The new section on GitHub issues guidelines offers detailed and actionable advice for crafting effective issues, which can lead to better project management and communication.

apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx (2)

11-24: Comprehensive Pull Request Guidelines.

The new section on Pull Request Guidelines provides detailed and clear instructions for contributors, enhancing the clarity and consistency of PR submissions.

Tools

LanguageTool

[uncategorized] ~13-~13: A comma might be missing here.
Context: ...R rules are set up for the repo just in case as a guardrail. Do your best to close ...

(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)

---

34-113: Effective Pull Request Checklist.

The Pull Request Checklist is well-structured and covers essential aspects of code quality and PR review readiness, aiding contributors in ensuring their submissions meet the project's standards.

[MFarabi619]

Great PR, docs are very nicely written and formatted, and thanks for adding the templates too 🙏

[HasithDeAlwis]

Very, very nice work on this 👍

[HasithDeAlwis]

Very small nitpick, I don't really mind, but would like your opinion on this as well. We can use MD to write these:
Example:

• checkbox

I did this with "- [ ] checkbox"
Lmk your thoughts

[JeremyFriesenGitHub]

does not work in mdx...

[JeremyFriesenGitHub]

or at least you won't be able to interact with the checkbox at all

[HasithDeAlwis]

Really, on my end I can interact with it? It also persists, so if I check it and leave the page for me, I can still see it as checked.

[JeremyFriesenGitHub]

weird, for me it was not working nicely at all...

[HasithDeAlwis]

Does it work for you in this comment?

[JeremyFriesenGitHub]

yes, but mdx is not rly md, i talked to farabi abt it and he said it was normal

[HasithDeAlwis]

Yea, i'm aware, but from waht I know checkboxes work in MDX and MD.

Refer to the PR below and you can interact with the checkboxes:
PR #60 is a good example

[HasithDeAlwis]

nice touch 🔥

[HasithDeAlwis]

nice link to the medium article 👍

[JeremyFriesenGitHub]

Very, very nice work on this 👍

thx, still tons left actually on the docs, but we need to at least get this through right now for better issue + pr documentation

[coderabbitai]

Actionable comments posted: 0

Outside diff range and nitpick comments (2)

apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx (2)

13-13: Correct the hyphenation in "up-to-date".

According to standard English usage, the phrase "up to date" should be hyphenated when used as an adjective:

-This ensures that your branch is up to date with the latest changes in the main branch.
+This ensures that your branch is up-to-date with the latest changes in the main branch.

---

37-116: The Pull Request Checklist looks great!

The checklist is comprehensive and covers important aspects of code quality and PR review readiness. It ensures that contributors self-assess their code before submitting a pull request.

The past review comment by coderabbitai[bot] suggesting the addition of a section on security best practices and a reminder for accessibility checks is still valid and can be considered for future enhancements to further improve the checklist.

Add a comma in line 25 as suggested by LanguageTool:

-PR is clear and comprehensible
+PR is clear and comprehensible,

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between a26f957 and 08212ab.

Files selected for processing (4)

• apps/docs/src/content/docs/contribution-guidelines/meta.json (0 hunks)
• apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx (1 hunks)
• apps/docs/src/content/docs/knowledge-base/meta.json (1 hunks)
• apps/docs/src/content/docs/tools-overview/meta.json (1 hunks)

Files not reviewed due to no reviewable changes (1)

• apps/docs/src/content/docs/contribution-guidelines/meta.json

Files skipped from review as they are similar to previous changes (2)

• apps/docs/src/content/docs/knowledge-base/meta.json
• apps/docs/src/content/docs/tools-overview/meta.json

Additional context used

LanguageTool

apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx

[uncategorized] ~25-~25: Possible missing comma found.
Context: ...s solution-specific (describes only the solution since the issue describes the problem a...

(AI_HYDRA_LEO_MISSING_COMMA)

Additional comments not posted (8)

apps/docs/src/content/docs/contribution-guidelines/pull-requests.mdx (8)

11-11: LGTM!

The heading is clear and concise.

---

15-15: The past review comment by HasithDeAlwis appreciating the link to the Medium article is still valid and applicable.

---

17-24: The new Pull Request Guidelines section looks great!

The section provides clear and comprehensive guidance on creating pull requests. It covers important aspects such as being mindful of the contribution type, using appropriate templates, aligning PR scope and subject with commits, creating draft PRs for unfinished work, linking PRs with issues, and making the PR description solution-specific.

The past review comment by coderabbitai[bot] suggesting the addition of examples or more detailed explanations is still valid and can be considered for future enhancements to further assist contributors.

---

28-28: LGTM!

The suggestion to use Git Worktrees is helpful for contributors who frequently switch branches and want to avoid stashing changes or amending commits.

---

29-30: LGTM!

The example of a well-documented pull request is helpful for contributors to understand what a good pull request looks like.

---

31-32: LGTM!

The link to GitHub PR templates is helpful for contributors to use as a starting point for creating pull requests.

---

33-34: LGTM!

The guidance on creating pull requests that address multiple issues is clear and helpful. Breaking them down into smaller, more focused PRs that tackle one issue at a time is a good approach to avoid overwhelming reviewers and to make the documentation process easier.

---

35-36: LGTM!

The guidance on handling issues that blow up and cannot be split into multiple issues is clear and helpful. Keeping the issue open and making multiple PRs that complete it in increments is a good approach. The example provided is a good reference for contributors to understand how to handle such situations.