all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 48696@debbugs.gnu.org
Subject: [bug#48696] [PATCH 3/3] doc: Explain more reasons for commit revocation.
Date: Thu, 27 May 2021 21:07:57 +0100	[thread overview]
Message-ID: <87v974ey8y.fsf@cbaines.net> (raw)
In-Reply-To: <20210527123554.4267-3-ludo@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 3447 bytes --]


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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

  parent reply	other threads:[~2021-05-27 20:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27 12:32 [bug#48696] [PATCH 0/3] Documenting commit reverts and revocation Ludovic Courtès
2021-05-27 12:35 ` [bug#48696] [PATCH 1/3] doc: Structure the "Commit Access" section Ludovic Courtès
2021-05-27 12:35   ` [bug#48696] [PATCH 2/3] doc: Add "Addressing Mistakes" section Ludovic Courtès
2021-05-27 19:19     ` Christopher Baines
2021-05-29 10:22       ` Ludovic Courtès
2021-05-30 10:29         ` Christopher Baines
2021-06-02  9:22           ` [bug#48696] [PATCH 0/3] Documenting commit reverts and revocation Ludovic Courtès
2021-06-08 14:02             ` Christopher Baines
2021-06-11 14:05               ` Ludovic Courtès
2021-06-13 10:15                 ` [bug#48696] [PATCH v2 0/4] " Ludovic Courtès
2021-06-13 10:15                   ` [bug#48696] [PATCH v2 1/4] doc: Structure the "Commit Access" section Ludovic Courtès
2021-06-13 11:50                     ` Xinglu Chen
2021-06-13 11:56                       ` Xinglu Chen
2021-06-13 10:15                   ` [bug#48696] [PATCH v2 2/4] doc: Add "Addressing Issues" section Ludovic Courtès
2021-06-13 10:15                   ` [bug#48696] [PATCH v2 3/4] doc: Explain more reasons for commit revocation Ludovic Courtès
2021-06-13 10:15                   ` [bug#48696] [PATCH v2 4/4] doc: Clarify Git commit signing; fix typo Ludovic Courtès
2021-06-18 12:37                   ` bug#48696: [PATCH 0/3] Documenting commit reverts and revocation Ludovic Courtès
2021-05-27 12:35   ` [bug#48696] [PATCH 3/3] doc: Explain more reasons for commit revocation Ludovic Courtès
2021-05-27 19:13     ` Maxime Devos
2021-05-27 20:07     ` Christopher Baines [this message]
2021-05-29  9:58       ` Ludovic Courtès
2021-05-29 11:28         ` Christopher Baines
2021-05-29 20:36           ` Ludovic Courtès
2021-05-27 13:55   ` [bug#48696] [PATCH 1/3] doc: Structure the "Commit Access" section Julien Lepiller
2021-05-29  9:30     ` Ludovic Courtès
2021-05-27 19:10   ` Maxime Devos
2021-05-27 14:16 ` [bug#48696] [PATCH 0/3] Documenting commit reverts and revocation Leo Famulari
2021-05-30 12:49 ` Tobias Geerinckx-Rice via Guix-patches via

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v974ey8y.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=48696@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.