linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Allison Collins <allison.henderson@oracle.com>,
	Dave Chinner <david@fromorbit.com>
Cc: Amir Goldstein <amir73il@gmail.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	lsf-pc@lists.linux-foundation.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	xfs <linux-xfs@vger.kernel.org>, Eryu Guan <guaneryu@gmail.com>,
	Eric Sandeen <sandeen@redhat.com>
Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] FS Maintainers Don't Scale
Date: Wed, 12 Feb 2020 11:21:06 +1100	[thread overview]
Message-ID: <87sgjg7j0t.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <fc430471-54d2-bb44-d084-a37e7ff9ef50@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 4339 bytes --]

On Sun, Feb 09 2020, Allison Collins wrote:

> Well, I can see the response is meant to be encouraging, and you are 
> right that everyone needs to give to receive :-)
>
> I have thought a lot about this, and I do have some opinions about it 
> how the process is described to work vs how it ends up working though. 
> There has quite been a few times I get conflicting reviews from multiple 
> reviewers. I suspect either because reviewers are not seeing each others 
> reviews, or because it is difficult for people to recall or even find 
> discussions on prior revisions.  And so at times, I find myself puzzling 
> a bit trying to extrapolate what the community as a whole really wants.

The "community as a whole" is not a person and does not have a coherent
opinion.  You will never please everyone and as you've suggested below,
it can be hard to tell how strongly people really hold the opinions they
reveal.

You need to give up trying to please "the community", but instead develop
your own sense of taste that aligns with the concrete practice of the
community, and then please yourself.

Then when someone criticizes your code, you need to decide for yourself
whether it is a useful criticism or not.  This might involve hunting
through the existing body of code to see what patterns are most common.
The end result is that either you defend your code, or you change your
opinion (both can be quite appropriate).  If you change your opinion,
then you probably change your code too.

Your goal isn't to ensure everyone is happy, only to ensure that no-one
is justifiably angry.

NeilBrown

>
> For example: a reviewer may propose a minor change, perhaps a style 
> change, and as long as it's not terrible I assume this is just how 
> people are used to seeing things implemented.  So I amend it, and in the 
> next revision someone expresses that they dislike it and makes a 
> different proposition.  Generally I'll mention that this change was 
> requested, but if anyone feels particularly strongly about it, to please 
> chime in.  Most of the time I don't hear anything, I suspect because 
> either the first reviewer isn't around, or they don't have time to 
> revisit it?  Maybe they weren't strongly opinionated about it to begin 
> with?  It could have been they were feeling pressure to generate 
> reviews, or maybe an employer is measuring their engagement?  In any 
> case, if it goes around a third time, I'll usually start including links 
> to prior reviews to try and get people on the same page, but most of the 
> time I've found the result is that it just falls silent.
>
> At this point though it feels unclear to me if everyone is happy?  Did 
> we have a constructive review?  Maybe it's not a very big deal and I 
> should just move on.  And in many scenarios like the one above, the 
> exact outcome appears to be of little concern to people in the greater 
> scheme of things.  But this pattern does not always scale well in all 
> cases.  Complex issues that persist over time generally do so because no 
> one yet has a clear idea of what a correct solution even looks like, or 
> perhaps cannot agree on one.  In my experience, getting people to come 
> together on a common goal requires a sort of exploratory coding effort. 
> Like a prototype that people can look at, learn from, share ideas, and 
> then adapt the model from there.  But for that to work, they need to 
> have been engaged with the history of it.  They need the common 
> experience of seeing what has worked and what hasn't.  It helps people 
> to let go of theories that have not performed well in practice, and 
> shift to alternate approaches that have.  In a way, reviewers that have 
> been historically more involved with a particular effort start to become 
> a little integral to it as its reviewers.  Which I *think* is what 
> Darrick may be eluding to in his initial proposition.  People request 
> for certain reviewers, or perhaps the reviewers can volunteer to be sort 
> of assigned to it in an effort to provide more constructive reviews.  In 
> this way, reviewers allocate their efforts where they are most 
> effective, and in doing so better distribute the work load as well.  Did 
> I get that about right?  Thoughts?
>
> Allison

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2020-02-12  0:21 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31  5:25 [LSF/MM/BPF TOPIC] FS Maintainers Don't Scale Darrick J. Wong
2020-01-31  7:30 ` [Lsf-pc] " Amir Goldstein
2020-02-01  3:20   ` Allison Collins
2020-02-02 21:46     ` Dave Chinner
2020-02-09 17:12       ` Allison Collins
2020-02-12  0:21         ` NeilBrown [this message]
2020-02-12  6:58           ` Darrick J. Wong
2020-02-12 22:06         ` Darrick J. Wong
2020-02-12 22:19           ` Dan Williams
2020-02-12 22:36             ` Darrick J. Wong
2020-02-13 15:11           ` Brian Foster
2020-02-13 15:46             ` Matthew Wilcox
2020-02-16 21:55               ` Dave Chinner
2020-02-19  0:29                 ` Darrick J. Wong
2020-02-19  1:17                   ` Theodore Y. Ts'o
2020-02-12 23:39         ` Dave Chinner
2020-02-13 15:19           ` Brian Foster
2020-02-17  0:11             ` Dave Chinner
2020-02-17 15:01               ` Brian Foster
2020-02-12 21:36       ` Darrick J. Wong
2020-02-12 22:42   ` Darrick J. Wong
2020-02-13 10:21     ` Amir Goldstein
2020-02-07 22:03 ` Matthew Wilcox
2020-02-12  3:51   ` Theodore Y. Ts'o
2020-02-12 22:29     ` Darrick J. Wong
2020-02-12 22:21   ` Darrick J. Wong
2020-02-13  1:23     ` Dave Chinner

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=87sgjg7j0t.fsf@notabene.neil.brown.name \
    --to=neilb@suse.de \
    --cc=allison.henderson@oracle.com \
    --cc=amir73il@gmail.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=guaneryu@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=sandeen@redhat.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).