aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMarcoFalke <falke.marco@gmail.com>2019-06-05 10:17:57 -0400
committerMarcoFalke <falke.marco@gmail.com>2019-06-13 10:08:25 -0400
commitfac5ddfc5796022601af2c17fd0b158b2c465cba (patch)
tree51b9afd7156f2077faf3c7731522f4e0e9e028d9
parent5d37c1bde01a7c43ed7ac1ab50cc41ff7d849ca9 (diff)
doc: Rework section on ACK
-rw-r--r--CONTRIBUTING.md31
1 files changed, 21 insertions, 10 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 5df99adba8..a2456f5b8c 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -237,24 +237,35 @@ request. Typically reviewers will review the code for obvious errors, as well as
test out the patch set and opine on the technical merits of the patch. Project
maintainers take into account the peer review when determining if there is
consensus to merge a pull request (remember that discussions may have been
-spread out over GitHub, mailing list and IRC discussions). The following
+spread out over GitHub, mailing list and IRC discussions).
+
+#### Conceptual Review
+
+A review can be a conceptual review, where the reviewer leaves a comment
+ * `Concept (N)ACK`, meaning "I do (not) agree in the general goal of this pull
+ request",
+ * `Approach (N)ACK`, meaning `Concept ACK`, but "I do (not) agree with the
+ approach of this change".
+
+A `NACK` needs to include a rationale why the change is not worthwhile.
+NACKs without accompanying reasoning may be disregarded.
+
+#### Code Review
+
+After conceptual agreement on the change, code review can be provided. It is
+starting with `ACK BRANCH_COMMIT`, where `BRANCH_COMMIT` is the top of the
+topic branch. The review is followed by a description of how the reviewer did
+the review. The following
language is used within pull-request comments:
- - (t)ACK means "I have tested the code and I agree it should be merged", involving
+ - "I have tested the code", involving
change-specific manual testing in addition to running the unit and functional
tests, and in case it is not obvious how the manual testing was done, it should
be described;
- - NACK means "I disagree this should be merged", and must be accompanied by
- sound technical justification (or in certain cases of copyright/patent/licensing
- issues, legal justification). NACKs without accompanying reasoning may be
- disregarded;
- - utACK means "I have not tested the code, but I have reviewed it and it looks
+ - "I have not tested the code, but I have reviewed it and it looks
OK, I agree it can be merged";
- - Concept ACK means "I agree in the general principle of this pull request";
- Nit refers to trivial, often non-blocking issues.
-Reviewers should include the commit hash which they reviewed in their comments.
-
Project maintainers reserve the right to weigh the opinions of peer reviewers
using common sense judgement and also may weight based on meritocracy: Those
that have demonstrated a deeper commitment and understanding towards the project