good first issue.
General rule: try to keep PRs as small as possible because smaller PRs get merged faster.
A PR should contain a single, standalone, and complete change to the code base, unless in exceptional cases where the PR is part of a bigger change.
Single means a PR should not try to fix more than one fix, unless there are multiple things that must be done together or not at all.
Refrain from do minor improvements to the code e.g., fix typoshousekeeping in the neighboring code unless the line in concern is already touched by the PR (i.e., the housekeeping does not increase the line count of the PR.
Rationale: Imagine we decide to revert the PR for some reason. If a PR contains, unrelated changes or multiple independent changes, we will not be able to revert the offending change without losing the other changes as well.
If you notice a need for housekeeping in the neighboring code as you do your PR, create an issue for it in the issue tracker.
Standalone means the PR should contain a meaningful change that moves the code base from one working state to another.
Complete means the PR should contain everything related to the change, including the following:
"This PR is just the code fix. I'll update tests and documentation in a separate PR" is not acceptable!
However, it is fine to push the functional code first to get early feedback, as long as the rest is added to the same PR later.
When submitting PRs, follow the forking workflow. A summary of the steps is given below.
Step 0 Do these steps if you haven't done them already:
0.1 Fork the upstream repo.
0.2 Clone the fork to your computer.
0.3 Set up the dev environment as described in the project docs. Confirm the set up is correct.
Step 1 Create a branch from the
master branch, following the naming convention given.
Step 2 Add your code to the branch while ensuring you follow these:
Step 3 Sync your branch with the upstream master, if the
master branch advances while you work on your code (i.e., pull upstream
master, merge to your branch).
Step 4 Create a PR when the code is ready, as follows:
ready for reviewcomment for good measure.
Step 5 Revise as per reviews until the PR is merged.
If you are new to GitHub PRs, see GitHub help on how to review PRs.
Follow the best practices in the panel below:
Follow the convention for Git branch merging, as given in the panel below.