From ac584aecaaa586e9620269c6815c15f5974ec61f Mon Sep 17 00:00:00 2001 From: Andreas Jaeger Date: Sat, 7 Mar 2020 16:50:48 +0100 Subject: [PATCH] Fix Peer Review section formatting https://docs.openstack.org/infra/manual/developers.html#peer-review is wrongly formatted, remove the extra indent that makes it preformatted instead of a list. Change-Id: I842814aa916bc8116c8889638d2a907214441da9 --- doc/source/developers.rst | 44 +++++++++++++++++++-------------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/doc/source/developers.rst b/doc/source/developers.rst index 4e8771a..24ba315 100644 --- a/doc/source/developers.rst +++ b/doc/source/developers.rst @@ -885,31 +885,31 @@ processes. General review flow: - 1. Review is a conversation that works best when it flows back and - forth. Submitters need to be responsive to questions asked in - comments, even if the score is `+0` from the reviewer. Likewise, - reviewers should not use a negative score to elicit a response if - they are not sure the patch should be changed before merging. +1. Review is a conversation that works best when it flows back and + forth. Submitters need to be responsive to questions asked in + comments, even if the score is `+0` from the reviewer. Likewise, + reviewers should not use a negative score to elicit a response if + they are not sure the patch should be changed before merging. - For example, if there is a patch submitted which a reviewer cannot - fully understand because there are changes that aren't documented - in the commit message or code documentation, this is a good time - to issue a negative score. Patches need to be clear in their commit - message and documentation. + For example, if there is a patch submitted which a reviewer cannot + fully understand because there are changes that aren't documented + in the commit message or code documentation, this is a good time + to issue a negative score. Patches need to be clear in their commit + message and documentation. - As a counter-example, a patch which is making use of a new library, - which the reviewer has never used before, should not elicit a - negative score from the reviewer with a question like "Is this - library using standard python sockets for communication?" That is - a question the reviewer can answer themselves, and which should - not hold up the review process while the submitter explains - things. Either the author or a reviewer should try to add a review - comment answering such questions, unless they indicate a need to - better extend the commit message, code comments, docstrings or - accompanying documentation files. + As a counter-example, a patch which is making use of a new library, + which the reviewer has never used before, should not elicit a + negative score from the reviewer with a question like "Is this + library using standard python sockets for communication?" That is + a question the reviewer can answer themselves, and which should + not hold up the review process while the submitter explains + things. Either the author or a reviewer should try to add a review + comment answering such questions, unless they indicate a need to + better extend the commit message, code comments, docstrings or + accompanying documentation files. - 2. In almost all cases, a negative review should be accompanied by - clear instructions for the submitter how they might fix the patch. +2. In almost all cases, a negative review should be accompanied by + clear instructions for the submitter how they might fix the patch. There may be more specific items to be aware of inside the projects' documentation for contributors.