Skip to content

Commit c0132db

Browse files
committed
Add review policy
Signed-off-by: Benjamin Wang <[email protected]>
1 parent 6e2be32 commit c0132db

File tree

1 file changed

+30
-1
lines changed

1 file changed

+30
-1
lines changed

Documentation/contributor-guide/triage_prs.md

Lines changed: 30 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ Following are a few example searches on PR for convenience:
1414

1515
## Scope
1616

17-
These guidelines serve as a primary document for managing PRs in `etcd`. Everyone is welcome to help manage PRs but the work and responsibilities discussed in this document are created with `etcd` maintainers and active contributors in mind.
17+
These guidelines serve as a primary document for managing PRs and review policy in `etcd`. Everyone is welcome to help manage PRs but the work and responsibilities discussed in this document are created with `etcd` maintainers and active contributors in mind.
1818

1919
## Ensure tests are run
2020

@@ -30,3 +30,32 @@ Reviewers are responsive in a timely fashion, but considering everyone is busy,
3030
## Verify important labels are in place
3131

3232
Make sure that appropriate reviewers are added to the PR. Also, make sure that a milestone is identified. If any of these or other important labels are missing, add them. If a correct label cannot be decided, leave a comment for the maintainers to do so as needed.
33+
34+
## Review policy
35+
36+
To ensure code quality and shared ownership, this review policy applies to all pull requests (PRs).
37+
38+
### Default rule
39+
40+
PRs should get at least two approvals (/lgtm or GitHub review approval) before merging.
41+
42+
Notes:
43+
44+
* Approvals should come from a maintainer, reviewer, or submodule owner familiar with the relevant code or area.
45+
* If there’s disagreement, maintainers should discuss and agree before merging.
46+
47+
### Exceptions for Less Impactful PRs
48+
49+
For low-risk changes — such as:
50+
51+
* CI workflows
52+
* Documentation
53+
* Comments
54+
55+
The rule can be relaxed:
56+
57+
* One approval is generally enough.
58+
59+
However:
60+
61+
* If the author is a maintainer, they should still get approval from another maintainer, reviewer, or submodule owner, even for minor changes.

0 commit comments

Comments
 (0)