[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#48696] [PATCH 3/3] doc: Explain more reasons for commit revocation.
From: |
Christopher Baines |
Subject: |
[bug#48696] [PATCH 3/3] doc: Explain more reasons for commit revocation. |
Date: |
Sat, 29 May 2021 12:28:49 +0100 |
User-agent: |
mu4e 1.4.15; emacs 27.2 |
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).
signature.asc
Description: PGP signature
[bug#48696] [PATCH 1/3] doc: Structure the "Commit Access" section., Julien Lepiller, 2021/05/27
[bug#48696] [PATCH 1/3] doc: Structure the "Commit Access" section., Maxime Devos, 2021/05/27
[bug#48696] [PATCH 0/3] Documenting commit reverts and revocation, Leo Famulari, 2021/05/27
[bug#48696] [PATCH 0/3] Documenting commit reverts and revocation, Tobias Geerinckx-Rice, 2021/05/30