Governance - struct-by-lightning/wpi-suite GitHub Wiki
Our mission is to create an extensible, maintainable, well-documented project management system for use as an educational tool that both teaches and facilitates software engineering best practices. This document will outline the governance model for the WPI Suite TNG project that will ensure we can meet our goal.
We will operate as a meritocracy: those with considerable experience will have more sway in the decision-making process, and community members can gain experience by contributing to the project. In the absence of interested community members, Gary Pollice will likely drive future contribution and make necessary decisions.
License
All code is licensed under the Eclipse Public License v1.0, and future contributions will be under this license. Any outside libraries or code included in any contributions must be compatible with the EPL.
Decision-making
Decisions will be made publicly in GitHub issues or pull requests. If you want to change something in WPI Suite TNG, you can open an issue or submit a pull request about the change. If there are no objections to a change after a reasonable amount of time, feel free to go forward with it if you have to power to do so. If there are serious disagreements, the issue should be debated in the comments until a consensus is reached among the interested contributors (or at least those worth listening to based on their merit).
Push access
Some contributors will have permission to push directly to the repository of record (we'll refer to these as "maintainers"). Maintainers obviously have more power than other contributors, and this comes with additional responsibilities and weight in the decision-making process. In order to enable growth, we need a process for outside contributors to become maintainers.
Gaining access
In order to gain push access to the repository of record, a community member will need two existing maintainers to vouch for them. Aspiring maintainers should show a record of good behavior, involvement in the community, trustworthiness, and previous patches that have been accepted into the repository of record. A community member can open an issue and nominate themselves for push access, or an existing maintainer can do so and look for support from one more maintainer. After two maintainers voice their support, the admin will give the new member push access to the repository of record.
Losing access
If a maintainer violates the trust they have been given, their push access can be removed if the rest of the community makes such a decision, as described above. Under emergency circumstances, the admin can immediately revoke push access.
Accepting changes
As described on the Repository Guidelines page, commits that end up on the dev branch will eventually make it into the "released" product on the master branch. As such, these changes should be handled with care.
For contributors without push access, all desired changes must go through a pull request. Any maintainer can accept a pull request and merge it into the dev branch, but they should use their best judgement to determine if they are the best person to handle it considering their familiarity with the affected code, and defer to other maintainers if necessary.
Code review
Changes to the dev branch should undergo a code review before being accepted. This review should make sure that the change:
- does what it says it does
- doesn't introduce regressions
- follows good code style and is programmed sanely
- passes existing unit tests
- contains its own unit tests if necessary
If the pull request doesn't meet these standards, the reviewer may leave comments on the request or on the particular commits stating what's wrong. The requester should then fix problems until the request passes review.
Caveats
Maintainers have the power to change whatever they want, but they should go through the pull request process as well and have another maintainer review their changes. Pull requests can be done for branches within the same repository. For small fixes, typos, etc. the maintainer may choose to skip this process - again, they should use their best judgement here and err on the side of caution.
Adding a default module to WPI Suite TNG or large architectural changes should be reviewed by two maintainers, and probably have the approval of the community at large.
Branches other than dev may choose to adopt some or all of this process. For example, we might start a branch for adding a brand new module that we want to keep clean to avoid reviewing the entire module before merging into dev.