|
|
@@ -124,8 +124,90 @@ the relevant operators.
|
|
|
|
|
|
* If the change affects the governance, philosophy, goals or principles of the project,
|
|
|
it must be approved by BDFL.
|
|
|
+
|
|
|
+* A pull request can be in 1 of 5 distinct states, for each of which there is a corresponding label
|
|
|
+that needs to be applied. `Rules.review.states` contains the list of states with possible targets
|
|
|
+for each.
|
|
|
"""
|
|
|
|
|
|
+ # Triage
|
|
|
+ [Rules.review.states.nolabel]
|
|
|
+
|
|
|
+ # Maintainers are expected to triage new incoming pull requests by adding
|
|
|
+ # the correct labels (e.g. `1-design-review`) potentially skipping some steps
|
|
|
+ # depending on the kind of pull request. Use common sense for judging.
|
|
|
+ #
|
|
|
+ # Checking for DCO should be done at this stage.
|
|
|
+ #
|
|
|
+ # If an owner, responsible for closing or merging, can be assigned to the PR,
|
|
|
+ # the better.
|
|
|
+
|
|
|
+ close = "unresponsive contributor without DCO"
|
|
|
+ 3-docs-review = "Non-proposal documentation-only change"
|
|
|
+ 2-code-review = "trivial bugfix"
|
|
|
+ 1-design-review = "general case"
|
|
|
+
|
|
|
+ # Design review
|
|
|
+ [Rules.review.states.1-design-review]
|
|
|
+
|
|
|
+ # Maintainers are expected to comment on the design of the pull request.
|
|
|
+ # Review of documentation is expected only in the context of design validation,
|
|
|
+ # not for stylistic changes.
|
|
|
+ #
|
|
|
+ # Ideally, documentation should reflect the expected behavior of the code.
|
|
|
+ # No code review should take place in this step.
|
|
|
+ #
|
|
|
+ # Once design is approved, this label should be removed and the next label
|
|
|
+ # added.
|
|
|
+
|
|
|
+ close = "design rejected"
|
|
|
+ 3-docs-review = "proposals with only documentation changes"
|
|
|
+ 2-code-review = "general case"
|
|
|
+
|
|
|
+ # Code review
|
|
|
+ [Rules.review.states.2-code-review]
|
|
|
+
|
|
|
+ # Maintainers are expected to review the code and ensure that it is good
|
|
|
+ # quality and in accordance with the documentation.
|
|
|
+ #
|
|
|
+ # If documentation is absent but expected, maintainers should ask for documentation.
|
|
|
+ #
|
|
|
+ # All tests should pass.
|
|
|
+ #
|
|
|
+ # Once code is approved according to the rules of the subsystem, this label
|
|
|
+ # should be removed and the next label added.
|
|
|
+
|
|
|
+ close = ""
|
|
|
+ 1-design-review = "raises design concerns"
|
|
|
+ 4-merge = "trivial change not impacting documentation"
|
|
|
+ 3-docs-review = "general case"
|
|
|
+
|
|
|
+ # Docs review
|
|
|
+ [Rules.review.states.3-docs-review]
|
|
|
+
|
|
|
+ # Maintainers are expected to review the documentation in its bigger context,
|
|
|
+ # ensuring consistency throughout the entire documentation. They should ask
|
|
|
+ # for any editorial change that makes the documentation more consistent and
|
|
|
+ # easier to understand.
|
|
|
+ #
|
|
|
+ # Once documentation is approved, this label should be removed and the next
|
|
|
+ # label added.
|
|
|
+
|
|
|
+ close = ""
|
|
|
+ 2-code-review = "requires more code changes"
|
|
|
+ 1-design-review = "raises design concerns"
|
|
|
+ 4-merge = "general case"
|
|
|
+
|
|
|
+ # Merge
|
|
|
+ [Rules.review.states.4-merge]
|
|
|
+
|
|
|
+ # Maintainers are expected to merge this pull request as soon as possible.
|
|
|
+ # They can ask for a rebase, or carry the pull request themselves.
|
|
|
+ # These should be the easy PRs to merge.
|
|
|
+
|
|
|
+ close = "carry PR"
|
|
|
+ merge = ""
|
|
|
+
|
|
|
[Rules.DCO]
|
|
|
|
|
|
title = "Helping contributors with the DCO"
|
Tibor Vass