Skip to content

Committer Conventions

Jim Krueger edited this page Feb 20, 2024 · 9 revisions

Committer Conventions

The committers of this project agreed upon the following conventions.

Voting Rules

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.

Minimum Length of review period before merge / close of PRs and closing of Issues

(1) Minimum two full weeks is default.

(2) For non-API, non-spec, non-javadoc changes (e.g., pom, travis, checkstyle, etc), 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.

Self-Assigned PRs and Issues

A committer may self-assign and merge / close PRs and Issues opened by himself.

Self-Reviewed PRs and Issues

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.

Enforcing Github reviews

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.

Assignees

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.

Exceptions to Committer Conventions for Working Branches

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.

What is a Working Branch?

  • A working branch is a branch created for accelerated development and prototyping purposes
  • A branch must receives 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.

Working Branch Exceptions

  • 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).
Clone this wiki locally