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

[Ludovic Courtès]

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