On Mon, Dec 4, 2023 at 8:16 AM Jan Beulich <jbeul...@suse.com> wrote:
> > I am in favor on moving faster and nitpicking less. Also, Andy put the
> > effort to produce the patch so he should have the default choice in the
> > wording. If the choice is taking the patch as is or rejecting it, I
> > would take it as is.
>
> I'm afraid there's also disagreement about where nitpicking starts. To me
> "broken" in the context here is technically incorrect. Hence asking for
> the wording to be changed wouldn't count as nitpicking to me. When badly
> worded comments of mine are commented upon, I also don't count this as
> nitpicking (there's always a grey area, of course).
Whether something is nitpicking or not is a value judgement; different
people come to different conclusions. I'm afraid even the argument
about whether "broken" is appropriate to use in this context is a
matter of judgement: there are arguments both ways, and different
people have come to different conclusions. The problem here is that
some people definitely think "broken" is the wrong word; and others
definitely think "broken" is the right word (some +2 and some -2).
Given that we're always going to have differences of judgement, we
need ways to move forward in spite of that. Ideally the maintainers
should be implementing things according to the value of the community
as a whole: we should not be quibbling over things that the community
as a whole doesn't want quibbled over.
The basic mechanisms we have, voting (with the ability to appeal to
the committers) is meant to be a quick way to approximate that. The
assumption is that with 6 active people in the leadership team ("the
committers" at the moment), from different companies and backgrounds,
the chance of a vote of the committers being out of sync with the
community is fairly small.
But of course, small is not impossible. The list of committers hasn't
changed significantly in a while; it's entirely possible in this sort
of case for the values of committers and the values of the community
as a whole to drift. How do we determine whether that's the case or
not? Hence the community-wide survey.
The problem with "nitpicking" goes a bit deeper. By its nature,
nitpicking doesn't really rise to the level of "something obviously
wrong"; it's more "too much time spent asking for changes to code
which is not obviously wrong". How much is "too much"? Again, it's a
value judgment. If someone is nitpicking your patch, it's not really
that obvious what to do about it -- to ask for a formal vote of the
committers about a tiny change request is just as "nitpicky" or
"petty" as the tiny change request itself; it's not this or that
change which causes the problem with nitpicks, but the cumulative
effect. How can this be "calibrated", so that we can ensure that
maintainers are just the right level if picky -- neither letting
sloppy / ugly code get checked in, nor wasting people's time and
emotional effort asking for changes which aren't worth the effort?
And how do we give people practical options to respond to a maintainer
who they think is being "picky", such that they can either be
convinced that he code changes are worth asking, or that the
maintainer can stop asking for minor changes that aren't worth the
benefits?
The last one I don't really have an answer for.
-George
