|
1 | | -## How to contribute |
2 | | -We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow. |
3 | | - |
4 | | -### Submitting a patch |
5 | | - |
6 | | - 1. It's generally best to start by opening a new issue describing the bug or |
7 | | - feature you're intending to fix. Even if you think it's relatively minor, |
8 | | - it's helpful to know what people are working on. Mention in the initial |
9 | | - issue that you are planning to work on that bug or feature so that it can |
10 | | - be assigned to you. |
11 | | - |
12 | | - 2. Follow the normal process of [forking][] the project, and setup a new |
13 | | - branch to work in. It's important that each group of changes be done in |
14 | | - separate branches in order to ensure that a pull request only includes the |
15 | | - commits related to that bug or feature. |
16 | | - |
17 | | - 3. To ensure properly formatted code, please make sure to use 4 |
18 | | - spaces to indent the code. The easy way is to run on your bash the provided |
19 | | - script: ./code_formatter.sh. You should also run [pylint][] over your code. |
20 | | - It's not strictly necessary that your code be completely "lint-free", |
21 | | - but this will help you find common style issues. |
22 | | - |
23 | | - 4. Any significant changes should almost always be accompanied by tests. The |
24 | | - project already has good test coverage, so look at some of the existing |
25 | | - tests if you're unsure how to go about it. We're using [coveralls][] that |
26 | | - is an invaluable tools for seeing which parts of your code aren't being |
27 | | - exercised by your tests. |
28 | | - |
29 | | - 5. Do your best to have [well-formed commit messages][] for each change. |
30 | | - This provides consistency throughout the project, and ensures that commit |
31 | | - messages are able to be formatted properly by various git tools. |
32 | | - |
33 | | - 6. Finally, push the commits to your fork and submit a [pull request][]. Please, |
34 | | - remember to rebase properly in order to maintain a clean, linear git history. |
35 | | - |
36 | | -[forking]: https://help.github.com/articles/fork-a-repo |
37 | | -[pylint]: https://www.pylint.org/ |
38 | | -[coveralls]: https://coveralls.io |
39 | | -[well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html |
40 | | -[pull request]: https://help.github.com/articles/creating-a-pull-request |
| 1 | +# Contributing to PINA |
| 2 | + |
| 3 | +First off, thanks for taking the time to contribute to **PINA**! 🎉 Your help makes the project better for everyone. This document outlines the process for contributing, reporting issues, suggesting features, and submitting pull requests. |
| 4 | + |
| 5 | +--- |
| 6 | + |
| 7 | +## Table of Contents |
| 8 | + |
| 9 | +1. [How to Contribute](#how-to-contribute) |
| 10 | +2. [Reporting Bugs](#reporting-bugs) |
| 11 | +3. [Suggesting Enhancements](#suggesting-enhancements) |
| 12 | +4. [Pull Request Process](#pull-request-process) |
| 13 | +5. [Code Style & Guidelines](#code-style--guidelines) |
| 14 | +6. [Community Standards](#community-standards) |
| 15 | + |
| 16 | +--- |
| 17 | + |
| 18 | +## How to Contribute |
| 19 | + |
| 20 | +You can contribute in several ways: |
| 21 | +- Reporting bugs |
| 22 | +- Suggesting features/enhancements |
| 23 | +- Submitting fixes or improvements via Pull Requests (PRs) |
| 24 | +- Improving documentation |
| 25 | + |
| 26 | +We encourage all contributions, big or small! |
| 27 | + |
| 28 | +--- |
| 29 | + |
| 30 | +## Reporting Bugs |
| 31 | + |
| 32 | +If you find a bug, please open an [issue](https://github.com/mathLab/PINA/issues) and include: |
| 33 | +- A clear and descriptive title |
| 34 | +- Steps to reproduce the problem |
| 35 | +- What you expected to happen |
| 36 | +- What actually happened |
| 37 | +- Any relevant logs, screenshots, or error messages |
| 38 | +- Environment info (OS, Python version, dependencies, etc.) |
| 39 | + |
| 40 | +--- |
| 41 | + |
| 42 | +## Suggesting Enhancements |
| 43 | + |
| 44 | +We welcome new ideas! If you have an idea to improve PINA: |
| 45 | +1. Check the [issue tracker](https://github.com/mathLab/PINA/issues) or the [discussions](https://github.com/mathLab/PINA/discussions) to see if someone has already suggested it. |
| 46 | +2. If not, open a new issue describing: |
| 47 | + - The enhancement you'd like |
| 48 | + - Why it would be useful |
| 49 | + - Any ideas on how to implement it (optional but helpful) |
| 50 | +3. If you are not sure about (something of) the enhancement, we suggest to open a discussion to collaborate on it with the PINA community |
| 51 | + |
| 52 | +--- |
| 53 | + |
| 54 | +## Pull Request Process |
| 55 | + |
| 56 | +Before submitting a PR: |
| 57 | + |
| 58 | +1. Ensure there’s an open issue related to your contribution (or create one). |
| 59 | +2. [Fork](https://help.github.com/articles/fork-a-repo) the repository and create a new branch from `master`: |
| 60 | + ```bash |
| 61 | + git checkout -b feature/my-feature |
| 62 | + ``` |
| 63 | +3. Make your changes: |
| 64 | + - Write clear, concise, and well-documented code |
| 65 | + - Add or update tests where appropriate |
| 66 | + - Update documentation if necessary |
| 67 | +4. Verify your changes by running tests: |
| 68 | + ```bash |
| 69 | + pytest |
| 70 | + ``` |
| 71 | +5. Properly format your code. If you want save time, simply run: |
| 72 | + ```bash |
| 73 | + bash code_formatter.sh |
| 74 | + ``` |
| 75 | +7. Submit a [pull request](https://help.github.com/articles/creating-a-pull-request) with a clear explanation of your changes and reference the related issue if applicable. |
| 76 | + |
| 77 | +### Pull Request Checklist |
| 78 | + - [ ] Code follows the project’s style guidelines |
| 79 | + - [ ] Tests have been added or updated |
| 80 | + - [ ] Documentation has been updated if necessary |
| 81 | + - [ ] Pull request is linked to an open issue (if applicable) |
| 82 | + |
| 83 | +--- |
| 84 | + |
| 85 | +## Code Style & Guidelines |
| 86 | +- Follow PEP8 for Python code. |
| 87 | +- Use descriptive commit messages (e.g. `Fix parser crash on empty input`). |
| 88 | +- Write clear docstrings for public classes, methods, and functions. |
| 89 | +- Keep functions small and focused; do one thing and do it well. |
| 90 | + |
| 91 | +--- |
| 92 | + |
| 93 | +## Community Standards |
| 94 | +By participating in this project, you agree to abide by our Code of Conduct. We are committed to maintaining a welcoming and inclusive community. |
0 commit comments