Discussion about codebase improvements happens in GitHub issues and pull requests.
The codebase and content is maintained using the "contributor workflow" where everyone without exception contributes patch proposals using "pull requests" (PRs). This facilitates social contribution, easy testing and peer review. To contribute a patch, the workflow is as follows:
- Fork repository (only for the first time)
- Create topic branch
- Commit patches
- The project coding conventions in the developer notes must be followed.
Most needed are code contributions. Even if you aren't a coder, your input is still valuable. Here are some of the ways you can contribute:
Anyone may create a new issue to address any improvement to the project. Peers may comment on the issue for clarification or discussion and if it is deemed worthy by the peers, someone may create a pull request that addresses the issue.
Anyone may participate in peer review which is expressed by comments in the pull request or issue. Typically reviewers will review the code for obvious errors, and discuss the merits of a particular issue and how it should be resolved.
Peer reviewers can simply comment with one of these to express the level of review they gave:
- Concept ACK - agree with the concept but haven't reviewed the changes
- utACK (Untested ACK) - agree with the changes and reviewed them but didn't test
- Tested ACK - agree with changes, reviewed and tested
- NACK - Disagree with changes, please provide reasoning
Project maintainers take into account the peer review when determining if there is consensus to merge a pull request.
Anyone may create a pull request that addresses an existing issue or a one off change that addresses an obvious error (like spelling, grammar, punctuation, etc.) Anyone may also make large structural changes to how the app is structured.
Changes will be peer reviewed before being merged.