Enhance contribution workflow and guidelines #131
Conversation
Thanks for creating a PR for your Issue!
|
Summary of ChangesHello @neeru24, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly refines the project's contribution guidelines to make the onboarding process smoother and more intuitive for new and existing contributors. By providing comprehensive instructions and best practices, it aims to reduce confusion, encourage consistent contributions, and ultimately enhance the overall quality and maintainability of the project's codebase through improved documentation. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This PR provides a significant improvement to the project's contribution guidelines by creating a clear, step-by-step workflow that is much more comprehensive and beginner-friendly. The new structure and added details on best practices are valuable additions. I've provided a couple of suggestions to enhance clarity and consistency even further, such as including missing git commands and aligning with the project's conventional commit standards. A key high-level suggestion is to consolidate the contribution guidelines from the README.md into this Contributing.md file to create a single source of truth. Overall, this is an excellent documentation update.
| ### 5. Commit Your Changes | ||
|
|
||
| git add . | ||
| git commit -m "Short description of the change" | ||
| Write clear, concise, and meaningful commit messages. | ||
|
|
||
| **Commit message best practices:** | ||
| - Use the imperative mood (e.g., “Add”, “Fix”, “Improve”) | ||
| - Keep the first line short and descriptive | ||
| - Avoid vague messages like “update” or “changes” | ||
|
|
||
| **Good examples:** | ||
| **Examples of good commit messages:** | ||
| - `Add dark mode toggle to navbar` | ||
| - `Fix broken route in frontend` | ||
| - `Improve error handling for login API` | ||
| - `Update README with setup instructions` | ||
|
|
There was a problem hiding this comment.
This section on commit messages can be improved for clarity and consistency with project standards.
- Include Commands: For a beginner-friendly guide, it's helpful to include the
git addandgit commitcommands. - Conventional Commits: The project's
README.md(lines 1624-1633) specifies using Conventional Commits. The examples here should follow that format (e.g.,feat: ...,fix: ...). This will ensure consistency.
Here's a suggested update that incorporates these points.
| ### 5. Commit Your Changes | |
| git add . | |
| git commit -m "Short description of the change" | |
| Write clear, concise, and meaningful commit messages. | |
| **Commit message best practices:** | |
| - Use the imperative mood (e.g., “Add”, “Fix”, “Improve”) | |
| - Keep the first line short and descriptive | |
| - Avoid vague messages like “update” or “changes” | |
| **Good examples:** | |
| **Examples of good commit messages:** | |
| - `Add dark mode toggle to navbar` | |
| - `Fix broken route in frontend` | |
| - `Improve error handling for login API` | |
| - `Update README with setup instructions` | |
| ### 5. Commit Your Changes | |
| Write clear, concise, and meaningful commit messages following the [Conventional Commits](https://www.conventionalcommits.org/) specification. | |
| ```bash | |
| git add . | |
| git commit -m "feat: Add dark mode toggle to navbar" |
Commit message best practices:
- Use the imperative mood (e.g., “Add”, “Fix”, “Improve”) but as part of the description after the type.
- The format should be
<type>: <description>. - Common types include
feat,fix,docs,style,refactor,test,chore.
Examples of good commit messages:
feat: Add dark mode toggle to navbarfix: Correct broken route in frontenddocs: Update setup instructions in READMErefactor: Improve error handling for login API
| To avoid conflicts, regularly sync your fork with the upstream repository before starting new work. | ||
|
|
||
| ```bash | ||
| git remote add upstream https://github.com/original-owner/LocalMind.git |
There was a problem hiding this comment.
To make the guide more user-friendly and reduce potential for errors, it's best to replace the placeholder original-owner with the actual repository owner, NexGenStudioDev. This allows contributors to copy and paste the command directly.
| git remote add upstream https://github.com/original-owner/LocalMind.git | |
| git remote add upstream https://github.com/NexGenStudioDev/LocalMind.git |
2 participants
fixes #129 @abhishek-nexgen-dev
This PR improves the project’s contribution guidelines by:
These updates aim to streamline contributions, reduce confusion for first-time contributors, and maintain consistency across the project.
No functional code changes are included; this update focuses solely on documentation.