search

cuhacking / 2025

Flagship platform for cuHacking's 2025 hackathon.
4 stars 4 forks source link

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

Closed JeremyFriesenGitHub closed 3 days ago

JeremyFriesenGitHub commented 2 weeks ago

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
image image

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:

Chores:

Summary by CodeRabbit

netlify[bot] commented 2 weeks ago

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

Name Link
Latest commit 08212ab05bb48c1cbd5c9f3cb48ebda280e50eb9
Latest deploy log https://app.netlify.com/sites/cuhacking-portal-dev/deploys/66e51e3b52958c00083a91a0
JeremyFriesenGitHub commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

@sourcery-ai review

sourcery-ai[bot] commented 1 week ago

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](https://app.sourcery.ai): - Enable or disable the Sourcery-generated pull request summary or reviewer's guide; - Change the review language; - You can always [contact us](mailto:support@sourcery.ai) if you have any questions or feedback.
coderabbitai[bot] commented 1 week ago
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 - #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](https://discord.com/channels/1134356397673414807/1283929536186155099).

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](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai) - [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai) - [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai) - [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code)
Tips ### Chat There are 3 ways to chat with [CodeRabbit](https://coderabbit.ai): - Review comments: Directly reply to a review comment made by CodeRabbit. Example: - `I pushed a fix in commit .` - `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](https://docs.coderabbit.ai/guides/configure-coderabbit) 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](https://coderabbit.ai/docs) for detailed information on how to use CodeRabbit. - Join our [Discord Community](https://discord.com/invite/GsXnASn26c) to get help, request features, and share feedback. - Follow us on [X/Twitter](https://twitter.com/coderabbitai) for updates and announcements.
MFarabi619 commented 1 week ago

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?

JeremyFriesenGitHub commented 3 days ago

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