Conversation
This PR adds a contributing guide to help new contributors.
📝 WalkthroughWalkthroughA new CONTRIBUTING.md file has been added to provide documentation on how developers can contribute to the project, including sections on getting started, development setup, coding guidelines, commit formats, pull request procedures, issue reporting, and community standards. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 46a8c389e8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 3. Navigate to the project directory. | ||
| cd REPOSITORY_NAME | ||
| 4. Install required dependencies. | ||
| pip install -r requirements.txt |
There was a problem hiding this comment.
Point setup command at existing dependency file
The getting-started flow tells contributors to run pip install -r requirements.txt, but this repository has no top-level requirements.txt (dependencies are project-specific under directories like GSoC25_H/requirements.txt), so following these steps from a fresh clone fails immediately with a missing-file error. This makes the new contributor guide non-functional for the default path and should be updated to direct users to a concrete subproject setup path or its README first.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
CONTRIBUTING.md (1)
17-25: Fence the shell commands inside the lists.The
git/pipcommands are currently plain text, which is harder to scan and copy. Wrapping them in indented fenced code blocks will make the guide much easier to follow.Suggested Markdown shape
1. Fork the repository. 2. Clone your fork to your local machine. - git clone https://github.com/YOUR_USERNAME/REPOSITORY_NAME.git + ```bash + git clone https://github.com/YOUR_USERNAME/REPOSITORY_NAME.git + ``` 3. Navigate to the project directory. - cd REPOSITORY_NAME + ```bash + cd REPOSITORY_NAME + ```Also applies to: 45-46
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@CONTRIBUTING.md` around lines 17 - 25, Wrap the inline shell commands in the CONTRIBUTING.md steps into fenced code blocks (use ```bash ... ```), e.g., enclose "git clone https://github.com/YOUR_USERNAME/REPOSITORY_NAME.git", "cd REPOSITORY_NAME", "pip install -r requirements.txt", and "git checkout -b feature/your-feature-name" in their own ```bash ... ``` blocks so they are visually fenced and copyable; also apply the same change to the commands referenced at lines 45-46.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@CONTRIBUTING.md`:
- Around line 51-58: Update the "Reporting Issues" section to include guidance
and a template for feature requests/enhancement proposals in addition to bug
reports: add a new subsection (e.g., "Feature Requests / Enhancements") under
the existing heading that lists required information such as a clear summary,
motivation/use case, proposed solution or API changes, alternatives considered,
and any backward-compatibility implications; include a short markdown
template/example that contributors can copy (title, problem statement, proposed
change, benefits, migration notes, and links to related issues/PRs) so
maintainers and reviewers have consistent info for evaluating enhancements.
- Around line 15-32: Extend the "Getting Started" section in CONTRIBUTING.md to
include concrete local run, test, and formatting steps: add commands and brief
notes for how to start the application locally (development server or entrypoint
and environment variables), how to run the test suite (unit/integration test
command and any test setup), and the project's coding-style/formatting workflow
(which formatter/linter to use, the exact commands such as format and lint, and
any pre-commit or CI hooks to install/run). Reference the existing "Getting
Started" header and add a short "Run & Test" subsection and a "Formatting &
Linting" subsection so new contributors can verify setup and ensure PRs follow
style before submitting.
---
Nitpick comments:
In `@CONTRIBUTING.md`:
- Around line 17-25: Wrap the inline shell commands in the CONTRIBUTING.md steps
into fenced code blocks (use ```bash ... ```), e.g., enclose "git clone
https://github.com/YOUR_USERNAME/REPOSITORY_NAME.git", "cd REPOSITORY_NAME",
"pip install -r requirements.txt", and "git checkout -b
feature/your-feature-name" in their own ```bash ... ``` blocks so they are
visually fenced and copyable; also apply the same change to the commands
referenced at lines 45-46.
| ## Getting Started | ||
|
|
||
| 1. Fork the repository. | ||
| 2. Clone your fork to your local machine. | ||
| git clone https://github.com/YOUR_USERNAME/REPOSITORY_NAME.git | ||
| 3. Navigate to the project directory. | ||
| cd REPOSITORY_NAME | ||
| 4. Install required dependencies. | ||
| pip install -r requirements.txt | ||
| 5. Create a new branch for your changes. | ||
| git checkout -b feature/your-feature-name | ||
|
|
||
| ## Coding Guidelines | ||
| - Write clean and readable code. | ||
| - Follow standard coding conventions. | ||
| - Add comments where necessary. | ||
| - Update documentation if required. | ||
| - Test your changes before submitting. |
There was a problem hiding this comment.
Document the actual local run, test, and formatting workflow.
This section stops at cloning and pip install -r requirements.txt. Issue #40 also asks for instructions to run the project locally plus concrete coding-style/formatting rules, so a new contributor still cannot verify their setup or prepare a compliant change before opening a PR.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CONTRIBUTING.md` around lines 15 - 32, Extend the "Getting Started" section
in CONTRIBUTING.md to include concrete local run, test, and formatting steps:
add commands and brief notes for how to start the application locally
(development server or entrypoint and environment variables), how to run the
test suite (unit/integration test command and any test setup), and the project's
coding-style/formatting workflow (which formatter/linter to use, the exact
commands such as format and lint, and any pre-commit or CI hooks to
install/run). Reference the existing "Getting Started" header and add a short
"Run & Test" subsection and a "Formatting & Linting" subsection so new
contributors can verify setup and ensure PRs follow style before submitting.
| ## Reporting Issues | ||
| When reporting issues include: | ||
|
|
||
| - Description of the problem | ||
| - Steps to reproduce | ||
| - Expected behavior | ||
| - Screenshots or logs if available | ||
|
|
There was a problem hiding this comment.
Add contribution guidance for feature requests, not just bugs.
The linked issue asks for guidelines for both reporting bugs and suggesting features, but this section only covers bug reports. Please add the expected path/template for enhancement proposals so the document fully addresses issue #40.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CONTRIBUTING.md` around lines 51 - 58, Update the "Reporting Issues" section
to include guidance and a template for feature requests/enhancement proposals in
addition to bug reports: add a new subsection (e.g., "Feature Requests /
Enhancements") under the existing heading that lists required information such
as a clear summary, motivation/use case, proposed solution or API changes,
alternatives considered, and any backward-compatibility implications; include a
short markdown template/example that contributors can copy (title, problem
statement, proposed change, benefits, migration notes, and links to related
issues/PRs) so maintainers and reviewers have consistent info for evaluating
enhancements.
This PR adds a contributing guide to help new contributors.
Fixes #40
Summary by CodeRabbit