all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Simon Tournier <zimon.toutoune@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>,
	"Maxim Cournoyer" <maxim.cournoyer@gmail.com>
Cc: 66436@debbugs.gnu.org
Subject: [bug#66436] [PATCH v2] doc: Add some guidelines for reviewing.
Date: Wed, 25 Oct 2023 15:53:04 +0200	[thread overview]
Message-ID: <87o7gmhkqn.fsf@gmail.com> (raw)
In-Reply-To: <87a5s86mos.fsf@gnu.org>

Hi

On Tue, 24 Oct 2023 at 17:54, Ludovic Courtès <ludo@gnu.org> wrote:

>> +@item
>> +@emph{Remain focused: do not change the scope of the work being
>> +reviewed.}  For example, if the contribution touches code that follows a
>> +pattern deemed unwieldy, it would be unfair to ask the submitter to fix
>> +all occurrences of that pattern in the code; to put it simply, if a
>> +problem unrelated to the patch at hand was already there, do not ask the
>> +submitter to fix it.

For me this item is clear…

> Another item came to mind, that could be phrased like this:

…while this new is unclear…

>   Spend time proportional to the stakes.  Ensure the discussion focuses
>   on important aspects of the changes; do not let it be derailed by
>   objectively unimportant issues@footnote{This situation is often
>   referred to as ``bikeshedding'', where much time is spent discussing
>   each one's preference for the color of the shed at the expense
>   progress made on the project to keep bikes dry.}.  In particular,
>   issues such as code formatting and other conventions can be dealt with
>   through automation---e.g., @command{guix lint} and @command{guix
>   style}---or through documentation (@pxref{Packaging Guidelines}, as an
>   example).

…especially in the light of these other items:

        +@item
        +@emph{Review is a discussion.}  The submitter's and reviewer's views on
        +how to achieve a particular change may not always be aligned.  As a
        +reviewer, try hard to explain the rationale for suggestions you make,
        +and to understand and take into account the submitter's motivation for
        +doing things in a certain way.

        +@item
        +@emph{Aim for finalization.}  Reviewing code is time-consuming.  Your
        +goal as a reviewer is to put the process on a clear path towards
        +integration, possibly with agreed-upon changes, or rejection, with a
        +clear and mutually-understood reasoning.  Avoid leaving the review
        +process in a lingering state with no clear way out.


Well, I do not like: « discussion focuses on important aspects of the
changes; do not let it be derailed by objectively unimportant issues »
because it is not clear for me what means “important aspects” or
“objectively unimportant issues”.  How do I gauge?

Sometimes, what does not appear to me “important” at first has then, at
the end, an impact that cannot be neglected.  This new item appears to
me as: it is not a open discussion and you should refrain from
commenting if you are not sure your point is *absolutely* important.

Instead of this new item – where my understanding is: avoid bikeshed :-)
and I agree – I propose to amend the item @emph{Review is a discussion.}
by explicitly refer to the 3 other items; which are, IMHO, the guards
against bikeshedding.  Something along:

--8<---------------cut here---------------start------------->8---
@item
@emph{Review is a discussion.}  The submitter's and reviewer's views on
how to achieve a particular change may not always be aligned.  The
discussion is lead by remain focused, ensure progress and aim for
finalization; spend time proportional to the stakes@footnote{This
situation is often referred to as ``bikeshedding'', where much time is
spent discussing each one's preference for the color of the shed at the
expense progress made on the project to keep bikes dry.}.  As a
reviewer, try hard to explain the rationale for suggestions you make,
and to understand and take into account the submitter's motivation for
doing things in a certain way.
--8<---------------cut here---------------end--------------->8---

WDYT?  Does it capture the idea?

If yes, I would pick this order for the enumeration:

 1. Be clear and explicit about changes you are suggesting 
 2. Remain focused
 3. Ensure progress
 4. Aim for finalization
 5. Review is a discussion


Cheers,
simon




  reply	other threads:[~2023-10-25 13:57 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10 12:54 [bug#66436] [PATCH] doc: Add some guidelines for reviewing Maxim Cournoyer
2023-10-10 13:29 ` Ludovic Courtès
2023-10-11  0:24 ` [bug#66436] [PATCH v2] " Maxim Cournoyer
2023-10-15  9:55   ` Josselin Poiret via Guix-patches via
2023-10-16 14:02     ` Maxim Cournoyer
2023-10-29 14:52       ` Josselin Poiret via Guix-patches via
2023-10-20  8:12   ` Clément Lassieur
2023-10-20 23:01     ` Maxim Cournoyer
2023-10-22 20:03       ` Clément Lassieur
2023-10-23  1:55         ` Maxim Cournoyer
2023-10-24  8:49       ` Simon Tournier
2023-10-24  8:59         ` Simon Tournier
2023-10-31 18:53           ` Maxim Cournoyer
2023-10-31 19:03             ` Simon Tournier
2023-10-24 15:54   ` Ludovic Courtès
2023-10-25 13:53     ` Simon Tournier [this message]
2023-10-12  2:48 ` [bug#66436] [PATCH 0/2] Add support for Git Large File Storage (LFS) Maxim Cournoyer
2023-10-12  2:51   ` Maxim Cournoyer
2023-10-31 20:25   ` [bug#66475] [PATCH v2 1/4] git-download: " Maxim Cournoyer
2023-10-31 20:25     ` [bug#66475] [PATCH v2 2/4] gnu: mdds: Update to 2.1.1 Maxim Cournoyer
2023-10-31 20:25     ` [bug#66475] [PATCH v2 3/4] gnu: ixion: Update to 0.19.0 Maxim Cournoyer
2023-10-31 20:25     ` [bug#66475] [PATCH v2 4/4] gnu: orcus: " Maxim Cournoyer
2023-11-05 14:49     ` [bug#66475] [PATCH v2 1/4] git-download: Add support for Git Large File Storage (LFS) Ludovic Courtès
2023-11-07 16:17       ` bug#66475: " Maxim Cournoyer
2023-11-01 19:23 ` [bug#66436] [PATCH v3] doc: Add some guidelines for reviewing Maxim Cournoyer
2023-11-05 14:51   ` Ludovic Courtès
2023-11-07 16:14     ` bug#66436: " Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7gmhkqn.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=66436@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.