-
Notifications
You must be signed in to change notification settings - Fork 212
Microserver project governance
The project can be only use git revision control system. The project must have issue tracker system. The project must have clearly documented guidelines for code style.
A patch SHALL NOT include non-trivial code from other projects unless the Contributor is the original author of that code. A patch MUST compile cleanly and pass project self-tests on at least the principle target platform. A patch commit message MUST consist of a single short (less than 80 characters) line stating the problem ("Problem: ...") being solved, followed by a blank line and then the proposed solution ("Solution: ..."). A "Correct Patch" is one that satisfies the above requirements.
To request changes, a user must log an issue on the project Platform issue tracker. To submit a patch, a Contributor must create a Platform pull request back to the project. A Contributor must not commit changes directly to the project. Maintainers must merge correct patches from other Contributors rapidly. The user who created an issue must close the issue after checking the patch is successful. Maintainers must close user issues that are left open without action for an uncomfortable period of time.
The project must have one branch ("master") that always holds the latest in-progress version and should always build. To make a stable release a Maintainer shall tag the repository. Stable releases must always be released from the repository master.
All Public Contracts (APIs or protocols) must be documented. All Public Contracts must have space for extensibility and experimentation. A patch that modifies a stable Public Contract must not break existing applications unless there is overriding consensus on the value of doing this. A patch that introduces new features must do so using new names (a new contract). New contracts must be marked as "draft" until they are stable and used by real users Old contracts should be deprecated in a systematic fashion by marking them as "deprecated" and replacing them with new contracts as needed. When sufficient time has passed, old deprecated contracts should be removed. Old names must not be reused by new contracts.
The project founders must act as Administrators to manage the set of project Maintainers. The Administrators must ensure their own succession over time by promoting the most effective Maintainers. A new Contributor who makes correct patches, who clearly understands the project goals, and the process should be invited to become a Maintainer. Administrators should remove Maintainers who are inactive for an extended period of time, or who repeatedly fail to apply this process accurately. Administrators should block or ban "bad actors" who cause stress and pain to others in the project. This should be done after public discussion, with a chance for all parties to speak. A bad actor is someone who repeatedly ignores the rules and culture of the project, who is needlessly argumentative or hostile, or who is offensive, and who is unable to self-correct their behavior when asked to do so by others.