Community Guidelines:

Blueprints:

What is a blueprint?

  1. Any new feature requires a blueprint[1].
  2. A new feature is anything that changes API / structure of current code and requires a change that spans for more than one file.

Where should one submit blueprints?

  1. Any new blueprint requires a discussion in the ML / weekly sync. (we encourage everyone who is involved with the project to join)
  2. A code sample / review of a blueprint should use the git-review -D for publishing a draft on gerrit.
  3. Since the review process is being done as a draft, it is possible to submit the draft prior to an actual ML e-mail.

Reviews:

  1. https://review.gerrithub.io/Documentation/config-labels.html#label_Code-Review
  2. A “-1”/”-2” from a core requires special attention and a patch should not be merged prior to having the same core remove the “-1”/”-2”.
  3. In case of a disagreement between two cores, the matter will be brought into discussion on the weekly sync / ML where each core will present his / her thoughts.
  4. Self reviews are not allowed. You are required to have at least one more person +1 your code.
  5. No review should be merged prior to all gates pass.
  6. Bit Rot. To keep the review queue clean an auto-abandoning of dead or old reviews is implemented. A dead review is defined by there are no comments, votes, activity for some agreed upon length of time. Warning will be posted on the review for two weeks of no activity, after the third week the review will be abandoned.

Gates:

  1. If a gate has failed, we should first fix that gate and rerun the job to get it passing.
  2. When a gate fails due to an infrastructure problem (example: server timeout, failed cleanup, etc), two cores approval is required in order to remove a gate “-1” vote

Commits:

  1. Each commit should be dedicated to a specific subject and not include several patches that are not related.
  2. Each commit should have a detailed commit message that describes the “high level” of what this commit does and have reference to other commits in case there is a relationship.

Cores:

  1. Need to have quality reviews.
  2. Reviews are well formed, descriptive and constructive.
  3. Reviews are well thought and do not result in a followed revert. (often)
  4. Should be involved in the project on a daily basis.