Committer Conventions
The committers of this project agreed upon the following conventions.
For all decisions related to the API and the PR's, we shall follow the same voting rules which are used for Committer Elections according to the Eclipse Project Handbook. These are basically the same as the rules described in the Apache Voting Process.
A vote is considered successful if there are at least three +1 votes and no -1 votes.
Note that only committer votes are counted.
(1) Minimum two full weeks is default.
(2) For non-API, non-spec, non-javadoc changes (e.g., pom, travis, checkstyle, etc), and any pure bug fix, a proposal to fast track the PR is requested at submission time. If a fast tracked PR receives 3 committer +1 votes (and no -1), it can be merged immediately provided at least 1 day has passed since its submission.
A committer may self-assign and merge / close PRs and Issues opened by himself.
Due to Github platform restrictions, a committer technically cannot review PRs opened by himself. Due to that, one implied +1 review vote is assumed for all PRs and Issues opened by committers.
PR reviews happen using the Github PR Review tool. The platform will technically enforce a minimum of +2, but a PR is assumed to be accepted only when having +3 or more committer votes. Contributor votes are not counted.
The assignees are the sole ones to further manage / implement / merge an issue. Always ask the assignees before acting. This prevents confusion and double work. If you want to be assignee but there already is one, you should ask the current assignee first but not directly add yourself. This is polite and prevents irritiation.
Occasionally there may be a need for the community to collaborate and develop changes for the purposes of prototyping etc. In those cases a “working branch” may be created that will be managed with exceptions to the conventions stated above.
- A working branch is a branch created for accelerated development and prototyping purposes
- A branch must receive 3 committer +1 votes (and no -1 votes) before being designated as a working branch.
- A working branch does not correspond directly to any documented release plan.
- Content in a working branch will need full approval via the Committer Conventions above before being added to the master/release/main branch or any branch corresponding to a documented release plan.
- Active working branches will be listed here.
- There will be no minimum wait time to merge / close PRs.
- PRs may be merged / closed following review and approval by at least one committer (other than the submitter themself).