Re: CoC, inclusivity etc. (was "Re: [...] systemd timers on Linux")

Jeff King wrote:

On Wed, May 26, 2021 at 12:29:01PM +0200, Ævar Arnfjörð Bjarmason wrote:

quoted

The reason I chimed in on this thread was that I thought concern over
one such topic had started to negatively impact another. We've got a lot
of people trying to contribute who aren't comfortable contributing in
English, or whose proficiency doesn't extend to the latest linguistic
trends.

I'm suggesting that it's more helpful to leave certain things be than to
pounce on contributors about things that are ultimately not integral to
their work, and which can be readily understood.

Yes, I want to express my support of this point, and not just for this
particular issue.

If you're a new contributor (or even an old one), it can be frustrating
to spend a lot of time working on and polishing up an improvement to the
software, to be met with feedback that mostly consists of "there's a
typo in your commit message". Whether that's true or not, or whether it
improves the commit message or not, it can feel like reviewers are
missing the point of the patch, which will discourage contributors.

As reviewers, I think we can do a few things to encourage people,
especially new contributors:

  - let little errors slide if they're not important. I think sometimes
    we get into a mentality that the commit message is baked into
    history, and thus needs to be revised and perfected. But commit
    messages are also just a conversation that's happening and being
    recorded. There will be hiccups, and polishing them forever has
    diminishing returns.

Yes, polishing forever has diminishing returns, but that's not really
the hard problem here; the problem is when two people (or more) can't
agree on what "polishing" means. That's a more eternal forever.

Fortunately we do have a dictator, and he can make determinations to end
the eternal debate.

He can simply fix the commit message--or any other minor
details--himself.

Sure, that doesn't scale, and ideally we would want the patch
contributors to do these tasks themselves, and not burden the
maintainer. But if the task of herding the cats is taken forever, why
keep insisting? Just fix the commit message and move on.

I would even extend some of those into the code itself. Obviously we
don't want to lower the bar and take incorrect code, or even typos in
error messages. But I think we could stand to relax sometimes on issues
of style or "I would do it like this" (and at the very least, the
"temper small corrections" advice may apply).

Plus code can be fixed later. If as a reviewer you really dislike one
aspect of a patch, you don't necessarily need to convince the author to
change it. You can propose a separate patch later on.


Sometimes good is good enough. Don't let perfect be the enemy of good.

Cheers.

-- 
Felipe Contreras