On Wed, May 26, 2021 at 12:29:01PM +0200, Ævar Arnfjörð Bjarmason wrote:
> 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.
(Of course this requires judgement; some commit messages really are
just hard to follow, and I think you made that distinction with the
phrase "make sure understand what's being said").
- temper small corrections with positive feedback. Especially for new
contributors, being told explicitly "yes, what you're trying to do
here overall is welcome, and it all looks good except for this..."
is much more encouraging than "this part is wrong". In the latter,
they're left to guess if anybody even values the rest of the work at
all.
- likewise, I think it helps to give feedback on expectations for the
process. Saying explicitly "this looks good; I think with this style
change, it would be ready to get picked up" helps them understand
that the fix will get them across the finish line (as opposed to
just getting another round of fix requests).
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).
I'm not really targeting anybody in particular in this thread (and
Lénaïc seems to have taken it all in stride in this case). It's more
just a reminder that it's easy to forget to do these kinds of things,
and keep this kind of perspective. I know I have not always done it
perfectly at times.
-Peff
