|
| 1 | +(contributing_pygem_target)= |
| 2 | +# PyGEM Contribution Guide |
| 3 | + |
| 4 | +Before contributing to PyGEM, it is recommended that you either clone [PyGEM's GitHub repository](https://github.com/PyGEM-Community/PyGEM) directly, or initiate your own fork (as described [here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)) to then clone. |
| 5 | + |
| 6 | +If PyGEM was already installed in your conda environment (as outlined [here](install_pygem_target)), it is recommended that you first uninstall: |
| 7 | +``` |
| 8 | +pip uninstall pygem |
| 9 | +``` |
| 10 | + |
| 11 | +Next, clone PyGEM. This will place the code at your current directory, so you may wish to navigate to a desired location in your terminal before cloning: |
| 12 | +``` |
| 13 | +git clone https://github.com/PyGEM-Community/PyGEM.git |
| 14 | +``` |
| 15 | +If you opted to create your own fork, clone using appropriate repo URL: `git clone https://github.com/YOUR-USERNAME/PyGEM.git` |
| 16 | + |
| 17 | +Navigate to root project directory: |
| 18 | +``` |
| 19 | +cd PyGEM |
| 20 | +``` |
| 21 | + |
| 22 | +Install PyGEM in 'editable' mode: |
| 23 | +``` |
| 24 | +pip install -e . |
| 25 | +``` |
| 26 | + |
| 27 | +Installing a package in editable mode creates a symbolic link to your source code directory (*/path/to/your/PyGEM/clone*), rather than copying the package files into the site-packages directory. This allows you to modify the package code without reinstalling it.<br> |
| 28 | + |
| 29 | +## General |
| 30 | +- The `dev` branch is the repository's working branch and should almost always be the base branch for Pull Requests (PRs). Exceptions include hotfixes that need to be pushed to the `master` branch immediately, or updates to the `README`. |
| 31 | +- Do not push to other people's branches. Instead create a new branch and open a PR that merges your new branch into the branch you want to modify. |
| 32 | + |
| 33 | +## Issues |
| 34 | +- Check whether an issue describing your problem already exists [here](https://github.com/PyGEM-Community/PyGEM/issues). |
| 35 | +- Keep issues simple: try to describe only one problem per issue. Open multiple issues or sub-issues when appropriate. |
| 36 | +- Label the issue with the appropriate label (e.g., bug, documentation, etc.). |
| 37 | +- If you start working on an issue, assign it to yourself. There is no need to ask for permission unless someone is already assigned to it. |
| 38 | + |
| 39 | +## Pull requests (PRs) |
| 40 | +- PRs should be submitted [here](https://github.com/PyGEM-Community/PyGEM/pulls). |
| 41 | +- PRs should be linked to issues they address (unless it's a minor fix that doesn't warrant a new issue). Think of Issues like a ticketing system. |
| 42 | +- PRs should generally address only one issue. This helps PRs stay shorter, which in turn makes the review process easier. |
| 43 | +- Concisely describe what your PR does. Avoid repeating what was already said in the issue. |
| 44 | +- Assign the PR to yourself. |
| 45 | +- First, open a Draft PR. Then consider: |
| 46 | + - Have you finished making changes? |
| 47 | + - Have you added tests for all new functionalities you introduced? |
| 48 | + - Have all tests passed in the CI? (Check the progress in the Checks tab of the PR.) |
| 49 | + |
| 50 | + If the answer to all of the above is "yes", mark the PR as "Ready for review" and request a review from an appropriate reviewer. If in doubt of which reviewer to assign, assign [drounce](https://github.com/drounce). |
| 51 | +- You will not be able to merge into `master` and `dev` branches without a reviewer's approval. |
| 52 | + |
| 53 | +### Reviewing PRs and responding to a review |
| 54 | +- Reviewers should leave comments on appropriate lines. Then: |
| 55 | + - The original author of the PR should address all comments, specifying what was done and in which commit. For example, a short response like "Fixed in [link to commit]." is often sufficient. |
| 56 | + - After responding to a reviewer's comment, do not mark it as resolved. |
| 57 | + - Once all comments are addressed, request a new review from the same reviewer. The reviewer should then resolve the comments they are satisfied with. |
| 58 | +- After approving someone else's PR, do not merge it. Let the original author of the PR merge it when they are ready, as they might notice necessary last-minute changes. |
0 commit comments