|
1 |
| -# Contributing to Mozilla.ai `mcpd-sdk-python` |
| 1 | +# Contributing to `mcpd-sdk-python` |
2 | 2 |
|
3 |
| -Thank you for your interest in contributing to the `mcpd` project! This project supports the mozilla.ai goal of empowering developers to integrate AI capabilities into their projects using open-source tools and models. |
4 |
| - |
5 |
| -We welcome all kinds of contributions, from improving customization, to extending capabilities, to fixing bugs. Whether you’re an experienced developer or just starting out, your support is highly appreciated. |
| 3 | +Thank you for your interest in contributing to the `mcpd` project! |
| 4 | +We welcome contributions from everyone and are grateful for your help in making this project better. |
6 | 5 |
|
7 | 6 | By contributing to this project, you agree to abide by our [Code of Conduct](CODE_OF_CONDUCT.md).
|
8 | 7 |
|
9 | 8 | ---
|
10 | 9 |
|
11 |
| -## **How to Contribute** |
| 10 | +## **Guidelines for Contributions** |
| 11 | + |
| 12 | +### Ground Rules |
| 13 | + |
| 14 | +- Review issue discussion fully before starting work. Engage in the thread first when an issue is under discussion. |
| 15 | +- PRs must build on agreed direction where ones exist. If there is no agreed direction, seek consensus from the core maintainers. |
| 16 | +- PRs with "drive-by" unrelated changes or untested refactors will be closed. |
| 17 | +- Untested or failing code is not eligible for review. |
| 18 | +- PR description **must** follow the PR template and explain **what** changed, **why**, and **how to test**. |
| 19 | +- Links to related issues are required. |
| 20 | +- Duplicate PRs will be automatically closed. |
| 21 | +- Only have 1-2 PRs open at a time. Any further PRs will be closed. |
| 22 | + |
| 23 | +**Maintainers reserve the right to close issues and PRs that do not align with the library roadmap.** |
| 24 | + |
| 25 | +### Code Clarity and Style |
| 26 | + |
| 27 | +- **Readability first:** Code must be self-documenting—if it is not self-explanatory, it should include clear, concise comments where logic is non-obvious. |
| 28 | +- **Consistent Style:** Follow existing codebase style (e.g., function naming, Python conventions). |
| 29 | +- **No dead/debug code:** Remove commented-out blocks, leftover debug statements, unrelated refactors. |
| 30 | +- Failure modes must be documented and handled with robust error handling. |
| 31 | + |
| 32 | +### Testing Requirements |
| 33 | + |
| 34 | +- **Coverage:** All new functionality must include unit tests covering both happy paths and relevant edge cases. |
| 35 | +- **Passing tests:** All linting and formatting checks must pass (see below on how to run). |
| 36 | +- **No silent failures:** Tests should fail loudly on errors. No placeholder tests. |
| 37 | + |
| 38 | +### Scope and Size |
| 39 | + |
| 40 | +- **One purpose per PR:** No kitchen-sink PRs mixing bugfixes, refactors, and features. |
| 41 | +- **Small, reviewable chunks:** If your PR is too large to review in under 30 minutes, break it up into chunks. |
| 42 | +- Each chunk must be independently testable and reviewable |
| 43 | +- If you can't explain why it can't be split, expect an automatic request for refactoring. |
| 44 | +- Pull requests that are **large** (>500 LOC changed) or span multiple subsystems will be closed with automatic requests for refactoring. |
| 45 | +- If the PR is to implement a new feature, please first make a GitHub issue to suggest the feature and allow for discussion. We reserve the right to close feature implementations and request discussion via an issue. |
12 | 46 |
|
13 |
| -### **Customize for your use-case or Extend It** 🔧 |
14 |
| -- Fork this repo and customize it for your own use-case or even extend its capabilities. |
15 |
| -- We'd love to see what you've built! |
| 47 | +## How to Contribute |
16 | 48 |
|
17 | 49 | ### **Browse Existing Issues** 🔍
|
18 | 50 | - Check the Issues page to see if there are any tasks you'd like to tackle.
|
19 | 51 | - Look for issues labeled **`good first issue`** if you're new to the project—they're a great place to start.
|
20 | 52 |
|
21 | 53 | ### **Report Issues** 🐛
|
22 |
| -- Found a bug? Open a Bug Report by clicking on 'New Issue' |
23 |
| -- Provide as much detail as possible, including the steps to reproduce the issue and expected vs. actual behavior |
| 54 | +- **Bugs:** Please use our [Bug Report template](.github/ISSUE_TEMPLATE/bug_report.yaml) to provide clear steps to reproduce and environment details. |
| 55 | +- **Search First:** Before creating a new issue, please search existing issues to see if your topic has already been discussed. |
| 56 | +- Provide as much detail as possible, including the steps to reproduce the issue and expected vs. actual behavior. |
24 | 57 |
|
25 | 58 | ### **Suggest Features** 🚀
|
26 |
| -- Have an idea for improving the project? Open a Feature Request by clicking on 'New Issue' |
27 |
| -- Share why the feature is important and any alternative solutions you’ve considered. |
| 59 | +- **Features:** Please use our [Feature Request template](.github/ISSUE_TEMPLATE/feature_request.yaml) to describe the problem your idea solves and your proposed solution. |
| 60 | +- Share why the feature is important and any alternative solutions you've considered. |
| 61 | +- If the PR is to implement a new feature, please first make a GitHub issue to suggest the feature and allow for discussion. |
28 | 62 |
|
29 |
| -### **Submit Pull Requests** 💻 |
30 |
| -- Fork the repository and create a new branch for your changes. |
31 |
| -- Install [pre-commit](https://pre-commit.com/) to ensure the code is formatted and standardized correctly, by running `uv sync --group lint` and then `pre-commit install`. |
32 |
| -- Ensure your branch is up-to-date with the main branch before submitting the PR |
33 |
| -- Please follow the PR template, adding as much detail as possible, including how to test the changes |
34 |
| - |
35 |
| ---- |
36 |
| - |
37 |
| -### **Guidelines for Contributions** |
38 |
| - |
39 |
| -**Coding Standards** |
40 |
| -- Follow PEP 8 for Python formatting. |
41 |
| -- Use clear variable and function names and add comments to improve readability. |
| 63 | +### Requirements |
42 | 64 |
|
43 |
| -**Testing** |
44 |
| -- Test changes locally to ensure functionality. |
45 |
| -- Install the package using development dependencies before testing: `uv sync --group dev` |
| 65 | +* `make setup` |
46 | 66 |
|
47 |
| -**Documentation** |
48 |
| -- Update docs for changes to functionality and maintain consistency with existing docs. |
| 67 | +### **Submit Pull Requests** 💻 |
49 | 68 |
|
50 |
| ---- |
| 69 | +1. **Fork** the repository on GitHub. |
| 70 | +2. **Clone** your forked repository to your local machine. |
| 71 | + ```bash |
| 72 | + git clone https://github.com/{YOUR_GITHUB_USERNAME}/mcpd-sdk-python.git |
| 73 | + cd mcpd-sdk-python |
| 74 | + ``` |
| 75 | +3. **Create a new branch** for your changes based on the `main` branch. |
| 76 | + ```bash |
| 77 | + git checkout main |
| 78 | + git pull origin main |
| 79 | + git checkout -b your-feature-or-bugfix-branch |
| 80 | + ``` |
| 81 | +4. **Format and Lint:** Ensure your code passes linting and formatting checks: |
| 82 | + ```bash |
| 83 | + make lint |
| 84 | + ``` |
| 85 | +5. **Add Unit Tests:** All new features and bug fixes should be accompanied by relevant unit tests. Run tests with: |
| 86 | + ```bash |
| 87 | + make test |
| 88 | + ``` |
| 89 | +6. **Commit your changes** with a clear and descriptive message. |
| 90 | + |
| 91 | +7. **Push your branch** to your forked repository. |
| 92 | + |
| 93 | +8. **Open a Pull Request** from your branch to the `main` branch of the upstream `mozilla-ai/mcpd-sdk-python` repository. |
| 94 | + - Follow the [Guidelines for Contributions](#guidelines-for-contributions) |
| 95 | + - Ensure your branch is up-to-date with the main branch before submitting the PR |
| 96 | + - Please follow the PR template, adding as much detail as possible, including how to test the changes |
| 97 | + - Reference the relevant GitHub issue in your PR summary |
| 98 | + |
| 99 | +> [!IMPORTANT] |
| 100 | +> Ensure that any related documentation is updated both in code comments and in markdown before submitting the PR. |
51 | 101 |
|
52 | 102 | ## Security Vulnerabilities
|
53 | 103 |
|
54 | 104 | If you discover a security vulnerability, please **DO NOT** open a public issue. Report it responsibly by following our [Security Policy](SECURITY.md).
|
55 | 105 |
|
56 |
| ---- |
57 |
| - |
58 | 106 | ## License
|
59 | 107 |
|
60 | 108 | By contributing, you agree that your contributions will be licensed as described in [LICENSE](LICENSE.md).
|
0 commit comments