This is the process we suggest for contributions. This process is designed to reduce the burden on project
reviews, impact on other contributors, and to keep the amount of rework from the contributor to a minimum.
Sign the contributor license agreement.
Start a discussion by creating a Github issue, or asking on
Slack (unless the change is trivial).
- This step will help you identify possible collaborators and reviewers.
- Does the change align with technical vision and project values?
- Will the change conflict with another change in progress? If so, work with others to minimize impact.
- Is this change large? If so, work with others to break into smaller steps.
Implement the change
- If the change is large, post a preview Github pull request
with the title prefixed with
[WIP], and share with collaborators.
- Include tests and documentation as necessary.
Create a Github pull request (PR).
- Make sure the pull request passes the tests in Travis CI.
- If known, request a review from an expert in the area changed. If unknown, ask for help on Slack.
Review will be performed by one or more reviewers.
- This normally happens within a few days, but may take longer if the change is large, complex, or if a
critical reviewer is unavailable. (feel free to ping the pull request).
Address concerns and update the pull request.
- Comments will be attached to each individual commit in the pull, and changes should be addressed in a
Fixup! commit placed after each commit. This is to make it easier for the reviewer to see the
what was updated.
- After pushing the changes, add a comment to the pull-request, mentioning the reviewers by name, stating
the change have been addressed. This is the only way that a reviewer is notified that you are ready
for the code to be reviewed again.
- Go to step 5.
Committer will merge the pull request after final changes are accepted.
Add release notes to the issue for the upcoming release.