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