[bug#48696] [PATCH 2/3] doc: Add "Addressing Mistakes" section.

["Ludovic Courtès" <ludo@gnu.org>]

Hi Chris,

Christopher Baines <mail@cbaines.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> +The Guix project values friendly cooperation and a constant effort to
>> +focus on the way forward when issues arise.  Committers should lead by
>> +example, notably as a way to encourage contributors and contributors to
>> +be.  Blame as well as defensiveness do not have their place in Guix when
>> +addressing genuine mistakes.
>
> I too would like to see less blame, but one factor is how things are
> framed and the language used.

Point taken!

> On the language here, "mistake" is a word I would generally avoid if the
> aim is avoid blaming someone, since mistakes are made by a person or set
> of people. I'd prefer a term like "problem", since I don't perceieve
> that as directly linked to a person or set of people.
>
> On the bit about the "person who pushed the faulty commits" (so, person
> to blame...) I'd much prefer an emphisis on group responsibility to
> mitigate the impact of problems quickly, and understand the factors that
> led to that problems in the first place. That avoids assigning blame,
> rather than the process pushing responsibility to the person to blame
> ("person who pushed the faulty commit(s)").

I get what you say and very much like the idea of focusing on group
responsibility.

There’s blame, and there’s accountability.  I see group responsibility
in setting up processes and carrying out proper peer review to avoid
problems.  I see accountability when it comes to commits actually
pushed—in the end, it’s one person running ‘git push’.  In my view,
“mistake” can be a way to name a “problem” that someone created and is
accountable for (Jelle wrote a nice message on this topic a while back).
This is getting a bit philosophical though, and I’m not sure my
understanding of English is good enough to go any further.  :-)

I think you have a point though.  Could you propose different wording
for this section?

(My goal for this section was to (1) spell out circumstances that may
lead to reverts, (2) explain the implications of committer
accountability, and (3) define our community standards in terms of
focusing on addressing issues and not on blaming individuals.)

> On this same thread, I'd like to see less blaming in the form of asking
> people to "explain". When there's a problem, and you ask someone to
> explain, I would interpret that as "I'm blaming you for this, please
> give your account of how the mistake was made", to which the person can
> either answer explaining the details as to why they are to blame, or can
> disagree with the implicit assertion that they are to blame. To avoid
> assigning blame, one can just ask someone to "describe" what happened,
> which I wouldn't interpret as being loaded with the same implicit
> assertion.

I agree with what you write in general, though my understanding is that
you’re not referring to the text in this patch, right?

Thanks for your feedback,
Ludo’.