summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorSandro Knauß <hefee@debian.org>2019-04-02 22:28:19 +0200
committerSandro Knauß <hefee@debian.org>2019-04-02 22:28:19 +0200
commit83974621f35fd6cfddc9e3344d6741f0a8db4a92 (patch)
tree5383780bf0f4a59e0568b422eaefca559eaf51e1
parent1301efeab0fe20cb866d0c64ac9c8316896a0522 (diff)
Allow trival changes from the reivewer to save roundtrips.
-rw-r--r--wiki/src/contribute/merge_policy/review.mdwn3
-rw-r--r--wiki/src/contribute/merge_policy/submit.mdwn13
2 files changed, 11 insertions, 5 deletions
diff --git a/wiki/src/contribute/merge_policy/review.mdwn b/wiki/src/contribute/merge_policy/review.mdwn
index 3b74023..f6d7243 100644
--- a/wiki/src/contribute/merge_policy/review.mdwn
+++ b/wiki/src/contribute/merge_policy/review.mdwn
@@ -24,6 +24,9 @@
maintenance includes: polishing the proposed changes to make them fit
for release; writing and updating the design and end-user
documentations; fixing bugs.
+- As reviewer, you are allowed to to trival checks e.g. {typos in,phrasing of}
+ comments and string on top of the proposed patch to avoid rountrips.
+ You need to report back those changes.
- Remember that it's hard to receive negative feedback. Don't forget
to note the good parts, be constructive and precise in your
comments, and never use reviews to make personal attacks. You can
diff --git a/wiki/src/contribute/merge_policy/submit.mdwn b/wiki/src/contribute/merge_policy/submit.mdwn
index cb66880..4a613c7 100644
--- a/wiki/src/contribute/merge_policy/submit.mdwn
+++ b/wiki/src/contribute/merge_policy/submit.mdwn
@@ -5,7 +5,7 @@ be named `feature/XXX`. For a bugfix about YYY, it should be named
`bugfix/YYY`. Ideally, include the relevant ticket number in the topic
branch name, e.g. `bugfix/7173-upgrade-syslinux`.
-When the developer thinks it is good enough and has tested it, she must:
+When you think it is good enough and has tested it, you have to:
- Set the ticket's *Status* field to *In Progress* (if you do not see
this field when editing the ticket, ask the [[sysadmin team|contribute/working_together/roles/sysadmins]]
@@ -17,10 +17,10 @@ When the developer thinks it is good enough and has tested it, she must:
this means, you do not) please make sure that your branch has not
broken any tests! Or, if you only want a first review of your code,
without bothering with the build & test status on Jenkins, that's fine:
- make it clear to the reviewer that it's what you expect and that
- your branch is not ready to merge.
+ make it clear to the reviewer what you expect and
+ that your branch is not ready to merge.
- Set the ticket's *QA Check* field to *Ready for QA*.
-- Assign this ticket to nobody (aka. unassign it from yourself) by
+- Assign the ticket to nobody (aka. unassign it from yourself) by
default. Unless it's clear to you that nobody on the
[[Foundations Team|working_together/roles/foundations_team]] will be
able or willing to do this specific review; in that case, _you_ shall try
@@ -36,4 +36,7 @@ merging, they should set the ticket's *QA Check* field back to *Needs
more dev* or *Needs more info* state, and
from now on it's the responsibility of the branch/ticket "holder" to
change it back to *Ready for QA* once they consider the issues raised by
-the reviewer are fixed.
+the reviewer are fixed. The reviewer is allowed to add trivial changes,
+e.g. {typos in,phrasing of} comments and string on top of the proposed patch
+to avoid roundtrips. But the reviewer needs to communicate those changes to
+the branch/ticket "holder".