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

[Christopher Baines]

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

> 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 guess part of what I'm getting at here is using language and the
perspective to try and delay that inference about individual
accountability, until the discussion around a problem has reached a
clear conclusion about what happened.

In doing so, opportunity is left open to actually consider the full
situation, rather than immediately narrowing it down to what a
particular individual or group did or didn't do.

> 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.)

What I would like to see is more like this:

  Problems happen, while minimising there occurrence is important, it's
  also important to respond to problems in a useful way. There are two
  priorities, mitigating the impact and understanding what happened in
  order to reduce the chance of similar incidents in the future. The
  responsibility for both these things primarily lies with those
  involved, but like everything this is a group effort.

  When working to mitigate the impact of a problem, obviously the
  response is very much dependent on the situation. If it's possible to
  fix things that are broken, that's preferable. If that's infeasible,
  then promptly reverting changes to return to a working state is
  justified (as with any commit, note why the change is being made in
  the commit message).

  Once the problem has been dealt with to some extent, then it's the
  responsibility of those involved to make sure the situation is
  understood. If you are working to understand what happened, focus on
  gathering information and avoid assigning any blame. Do ask those
  involved to describe what has happened, don't ask them to explain the
  situation, even if you think they have something to explain, as this
  implicitly blames them, which is unhelpful. Accountability comes from
  a consensus about the problem, learning from it and improving
  processes so that it's less likely to reoccur.

I'm not sure how much needs saying about reverts, but I did include
something.

For committer accountability, that's where I'm talking about the
"responsibilities of those involved". I guess that's a little vague, but
what I'm trying to do there is trying to capture the group of relevant
people, for example, the person who proposed the breaking change, the
committer who pushed it, and the other person that reverted it.

In terms of trying to focus on addressing issues and not blaming
individuals, I think just avoiding language that implicitly blames
people would be a big step forward. Whether that's enough, I'm unsure.

>> 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?

Yeah, although I think something to this effect might be worth
including.

signature.asc
Description: PGP signature