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

[Ludovic Courtès]

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