[bug#48696,3/3] doc: Explain more reasons for commit revocation.

* doc/contributing.texi (Commit Revocation): Expound.
---
 doc/contributing.texi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

PATCH 2/3 and PATCH 3/3 also seem good to me.

Greetings,
Maxime.

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

> * doc/contributing.texi (Commit Revocation): Expound.
> ---
>  doc/contributing.texi | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>
> diff --git a/doc/contributing.texi b/doc/contributing.texi
> index 8308551261..ec649c8e13 100644
> --- a/doc/contributing.texi
> +++ b/doc/contributing.texi
> @@ -1444,6 +1444,27 @@ key removed from @file{.guix-authorizations} after 12 months of
>  inactivity; they can ask to regain commit access by emailing the
>  maintainers, without going through the vouching process.
>
> +Maintainers@footnote{See @uref{https://guix.gnu.org/en/about} for the
> +current list of maintainers.  You can email them privately at
> +@email{guix-maintainers@@gnu.org}.} may also revoke an individual's
> +commit rights, as a last resort, if cooperation with the rest of the
> +community has caused too much friction---even within the bounds of the
> +project's code of conduct (@pxref{Contributing}).  They would only do so
> +after public or private discussion with the individual and a clear
> +notice.  Examples of behavior that hinders cooperation and could lead to
> +such a decision include:
> +
> +@itemize
> +@item repeated violation of the commit policy stated above;
> +@item repeated failure to take peer criticism into account;
> +@item breaching trust through a series of grave incidents.
> +@end itemize
> +
> +When maintainers resort to such a decision, they notify developers on
> +@email{guix-devel@@gnu.org}; inquiries may be sent to
> +@email{guix-maintainers@@gnu.org}.  Depending on the situation, the
> +individual may still be welcome to contribute.
> +
>  @subsection Helping Out
>
>  One last thing: the project keeps moving forward because committers not

Since the project code of conduct sets out behavioural standards,
including mandating "Gracefully accepting constructive criticism" and
"Showing empathy towards other community members", I think that combined
with "following the relevant processes" already covers what you're
setting out here?

I was shocked by [1], which from memory is the first time a technical
measure has been used to push a contributor away from the project (at
least that's my interpretation of the effect/intent). I think the future
use of revoking individuals commit access would be good to discuss.

1: https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00489.html

In abstract, in my opinion, I can only think of three scenarios for
removing someones commit access when they're actively using it:

- Clear violation of the code of conduct

    I don't think it's helpful to set out stuff about conduct in other
    places, particularly bits about unacceptable conduct. If the code of
    conduct is wrong or not sufficient, it should be revised.

- Suspected malicious intent

    Like they didn't just introduce some reference to some dodgy release
    tarball for a package, but it seems like this could have been done
    intentionally.

- Process problem for giving out commit access

    There's a process and people involved, so it's fair to say that
    problems can occur. Obviously it's not ideal, but if the process
    wasn't followed correctly, or if it's been updated and in hindsight
    different decisions would have been made, I think that's reason
    enough to apologise, and remove someones commit access.

Christopher Baines <mail@cbaines.net> skribis:

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

[...]

>> +Maintainers@footnote{See @uref{https://guix.gnu.org/en/about} for the
>> +current list of maintainers.  You can email them privately at
>> +@email{guix-maintainers@@gnu.org}.} may also revoke an individual's
>> +commit rights, as a last resort, if cooperation with the rest of the
>> +community has caused too much friction---even within the bounds of the
>> +project's code of conduct (@pxref{Contributing}).  They would only do so
>> +after public or private discussion with the individual and a clear
>> +notice.  Examples of behavior that hinders cooperation and could lead to
>> +such a decision include:
>> +
>> +@itemize
>> +@item repeated violation of the commit policy stated above;
>> +@item repeated failure to take peer criticism into account;
>> +@item breaching trust through a series of grave incidents.
>> +@end itemize

[...]

> Since the project code of conduct sets out behavioural standards,
> including mandating "Gracefully accepting constructive criticism" and
> "Showing empathy towards other community members", I think that combined
> with "following the relevant processes" already covers what you're
> setting out here?

Note that the code of conduct does not “mandate” gracefully accepting
constructive criticism; it merely gives it as an example of expected
behavior.

> I was shocked by [1], which from memory is the first time a technical
> measure has been used to push a contributor away from the project (at
> least that's my interpretation of the effect/intent). I think the future
> use of revoking individuals commit access would be good to discuss.
>
> 1: https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00489.html

Yes, it was the first time; it was a tough decision for us
co-maintainers because it was a last resort we were not prepared for.
Part of the reason for this patch is to document this possibility so we
all know what to expect.

> In abstract, in my opinion, I can only think of three scenarios for
> removing someones commit access when they're actively using it:
>
> - Clear violation of the code of conduct

Yes, that’s already covered by the code of conduct.

The section above is explicitly about cases where the individual did not
violate the code of conduct (hence “even within the bounds of the
project's code of conduct” in the text above), but instead broke
community expectations.

> - Suspected malicious intent

Put this way, the question becomes who is suspecting that.  Instead I
wrote “breaching trust” in the bullet list above; the intent is to
describe a situation where the individual and other committers no longer
trust each other, there’s no judgment involved.

> - Process problem for giving out commit access

The process for giving commit access is already documented (info "(guix)
Commit Access"); my intent here was not to change it.

Thanks,
Ludo’.

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

> Christopher Baines <mail@cbaines.net> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> +Maintainers@footnote{See @uref{https://guix.gnu.org/en/about} for the
>>> +current list of maintainers.  You can email them privately at
>>> +@email{guix-maintainers@@gnu.org}.} may also revoke an individual's
>>> +commit rights, as a last resort, if cooperation with the rest of the
>>> +community has caused too much friction---even within the bounds of the
>>> +project's code of conduct (@pxref{Contributing}).  They would only do so
>>> +after public or private discussion with the individual and a clear
>>> +notice.  Examples of behavior that hinders cooperation and could lead to
>>> +such a decision include:
>>> +
>>> +@itemize
>>> +@item repeated violation of the commit policy stated above;
>>> +@item repeated failure to take peer criticism into account;
>>> +@item breaching trust through a series of grave incidents.
>>> +@end itemize
>
> [...]
>
>> Since the project code of conduct sets out behavioural standards,
>> including mandating "Gracefully accepting constructive criticism" and
>> "Showing empathy towards other community members", I think that combined
>> with "following the relevant processes" already covers what you're
>> setting out here?
>
> Note that the code of conduct does not “mandate” gracefully accepting
> constructive criticism; it merely gives it as an example of expected
> behavior.

Yeah, maybe you're right. While there's a pledge regarding harassment,
and the example behaviours are given in a section titled "Standards",
the example behaviours are called that, examples.

>> In abstract, in my opinion, I can only think of three scenarios for
>> removing someones commit access when they're actively using it:
>>
>> - Clear violation of the code of conduct
>
> Yes, that’s already covered by the code of conduct.
>
> The section above is explicitly about cases where the individual did not
> violate the code of conduct (hence “even within the bounds of the
> project's code of conduct” in the text above), but instead broke
> community expectations.

I'd like to say that the code of conduct should encapsulate community
expectations, but it does seem just to set out a strong position on
harassment, and I would like to think that the community expectations
are more than just making sure people feel that they're not being
harassed.

Is your intent here for "community expectations" to be/remain abstract,
or for them to be explicitly set out somewhere?

>> - Suspected malicious intent
>
> Put this way, the question becomes who is suspecting that.  Instead I
> wrote “breaching trust” in the bullet list above; the intent is to
> describe a situation where the individual and other committers no longer
> trust each other, there’s no judgment involved.

I think the "who" here would be the people looking at removing someones
commit access.

I like this framing because it's more specific than "breaching trust
through a series of grave incidents". Do you have other things in mind
that this third point as you put it would cover?

>> - Process problem for giving out commit access
>
> The process for giving commit access is already documented (info "(guix)
> Commit Access"); my intent here was not to change it.

My point here is just that I think it's reasonable to remove someones
commit access if it was effectively given out in error (because the
process wasn't followed properly, or has been since revised).

Hello!

Christopher Baines <mail@cbaines.net> skribis:

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

[...]

>> The section above is explicitly about cases where the individual did not
>> violate the code of conduct (hence “even within the bounds of the
>> project's code of conduct” in the text above), but instead broke
>> community expectations.
>
> I'd like to say that the code of conduct should encapsulate community
> expectations, but it does seem just to set out a strong position on
> harassment, and I would like to think that the community expectations
> are more than just making sure people feel that they're not being
> harassed.

Yes, that’s what the code of conduct is about, mostly.  It does not say
how a development community should cooperate, how it can maximize
benefits for everyone involved.  I found this article by a Rust
developer inspiring:
<https://aturon.github.io/tech/2018/06/02/listening-part-2/>.

> Is your intent here for "community expectations" to be/remain abstract,
> or for them to be explicitly set out somewhere?

My intent with this patch is to spell out expectations for committers,
with a concrete implementation.  It’s one particular aspect of
“community expectations”, but one that I think ought to be written down,
because committers (and maintainers) have a higher responsibility.

>>> - Suspected malicious intent
>>
>> Put this way, the question becomes who is suspecting that.  Instead I
>> wrote “breaching trust” in the bullet list above; the intent is to
>> describe a situation where the individual and other committers no longer
>> trust each other, there’s no judgment involved.
>
> I think the "who" here would be the people looking at removing someones
> commit access.

Removing someone’s commit access can never be a goal.  However,
maintainers, like everyone else, can witness a breach of trust at some
point.

> I like this framing because it's more specific than "breaching trust
> through a series of grave incidents". Do you have other things in mind
> that this third point as you put it would cover?

If repeated incidents happen, some may presume malice, while others may
still see “mere mistakes”—we have different thresholds.  Breach of trust
concerns the group as a whole: once there’s mutual suspicion among some
in the group, we can say that cooperation “doesn’t work” anymore, that
there’s too much friction.

>>> - Process problem for giving out commit access
>>
>> The process for giving commit access is already documented (info "(guix)
>> Commit Access"); my intent here was not to change it.
>
> My point here is just that I think it's reasonable to remove someones
> commit access if it was effectively given out in error (because the
> process wasn't followed properly, or has been since revised).

Oh, got it.  To me it’s implicit that commit access can only be obtained
by following the documented process (that’s indeed be the case since
it’s in place); do you think we should be more explicit?

Thanks,
Ludo’.