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.