From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 71EF0138334 for ; Fri, 12 Apr 2019 15:30:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 46116E08BF; Fri, 12 Apr 2019 15:30:42 +0000 (UTC) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9BC8DE08AA for ; Fri, 12 Apr 2019 15:30:41 +0000 (UTC) Received: by mail-lj1-x244.google.com with SMTP id k8so9240185lja.8 for ; Fri, 12 Apr 2019 08:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gentoo-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PRd9KTfOEIUs50xK8X5eM0uqmSrxzSLGK566xhuYgyk=; b=wpo3DW0L8p2GXMHxP5bMB+NR5VDrtfcVrTEGtbNllGzF6yi/4GRnMjk4mHC1ZRCEVA 7rYX5rJyy6GJtnZQc+3VCgTw2F8LoJISE24z6Ud4aWcIvWf75j9tC30kV2R0BKjdhU1M LF+oIR+vqHuRgd80ZPSfZBDVFX+7zF3pMDC6rmg3eQUGatVwwLI3wpa6e28fJEq0uZed 6E5xICPBm51p+em8ZPQJWggmuOeaLkPP5hFh4OTzQlfxYaWFjypXn91zkcaKgC+Nr6jp NlJv9eR+Jz9uGmUEsiJKsFR3X16oE94Ibn99kHXnPMeMJM5rGzwh6YuIOkKXxX4X4Bn5 WxzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PRd9KTfOEIUs50xK8X5eM0uqmSrxzSLGK566xhuYgyk=; b=AvzrH0MJjlpTADG8dD59lldvQPW492pHdrTwdPltgZWnau1tudsZ23JshEC3IEuSbh xYjvCMPClhKsCK5tk1QWFL2OSraQC2ZdKmVB2B6A6meYPB/XOkMSL+Z6jXGOTLJOhcEd lJUoffukVu8byRVQaHjc4ro1pUq4kSDoFC3/Vy1BYAUS4B+UIWcWYlBUl3tUEGclOAvb ebHRDfCmivvG16gUzLI/GOmeYNeLdOAN4k6TdQ/U8pM/TEgHrcCoCRWrmYcz1vvaOT53 tv5NPqQlvgWdSalt2hDnwGcUZZahljDnVay+sxKox5hpnOgXylPnCcmofOIpVUtS3hvU HeIw== X-Gm-Message-State: APjAAAXsGSmQxK3IGOpXsLemMqWQ+Bb7CN6/CxTF7IGbEf+eGN2SJVoG eZbLpkkfiJoAVPf8oaYLPIDlNr7zd8+bRMpofSmpAq2r8nQ= X-Google-Smtp-Source: APXvYqzKAJyly+edu1zeQjGnt/2k2owGC66S+twPcTKxUAJtyJ4O+j+ODPdK68L5RVNK1SzY8+7AUFiCpkvJFmMcX+A= X-Received: by 2002:a2e:5dd2:: with SMTP id v79mr30168622lje.22.1555083039166; Fri, 12 Apr 2019 08:30:39 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <20190412144043.5010-1-mgorny@gentoo.org> In-Reply-To: <20190412144043.5010-1-mgorny@gentoo.org> From: Alec Warner Date: Fri, 12 Apr 2019 11:30:28 -0400 Message-ID: Subject: Re: [gentoo-project] [PATCH] glep-0048: Provide clear rules for disciplinary actions To: gentoo-project Cc: qa , =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Content-Type: multipart/alternative; boundary="000000000000257191058656fc76" X-Archives-Salt: 0579dc44-d203-40bc-9df4-274e3dbd63ec X-Archives-Hash: f46717e671819541b1e26f9b39233fec --000000000000257191058656fc76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just as a frame, I'm not on QA. On Fri, Apr 12, 2019 at 10:40 AM Micha=C5=82 G=C3=B3rny = wrote: > Update the wording of GLEP 48 to provide clear information on what kind > of disciplinary actions QA can issue, and in what circumstances they can > be exercised. Remove the unclear reference to ComRel that is either > meaningless or violation of scope. > Is there a particular driver for this change? E.g. have you been dissatisfied with the current procedure, or perhaps Comrel is not acting on your referrals? In general I perceive the QA organization as an educational / enabling organization (it trains people and writes tools) and not as a punishment-based organization (where it shames people for their mistakes and removes commit access from people who make too many.) This isn't to say there isn't room for removing access for committers who routinely make mistakes, I just think it ends up supporting this underlying narrative about the project that (and I'm framing this here) "Gentoo should be smaller and only composed of elite committers who understand all the complex stuff required to not break things." This type of change was previously discussed on the project list. If the goal is to move the project in that direction I'd rather see a vision document or similar ratified by the council to support that direction than this slow boiling of a frog. > > According to the old wording, QA could request 're-evaluating commit > rights' from ComRel. This is very unclear, and has been a source of > confusion more than once. Firstly, it is unclear whether ComRel merely > serves as a body executing the QA team's decision, or whether it is > supposed to make independent judgment (which would be outside its > scope). Secondly, it suggests that the only disciplinary action > possible would be 're-evaluating commits rights' which sounds like > an euphemism for removing commit access permanently. > > The new wording aims to make things clear, and make QA disciplinary > actions independent of ComRel. Explanation for the individual points > follow. > > Firstly, it aims to clearly define the domain of QA actions, and set > a better distinction between QA and ComRel. In this context, QA > is concerned whenever the developer's action technically affects Gentoo, > which includes breaking user systems, Infrastructure tooling, other > packages, etc. ComRel on the other hand is concerned in actions having > social consequences rather than technical. > Previous QA teams would often take unilateral action against individual developers, often for problems that were poorly or under-documented[0]. The infrastructure teams in the past had similar issues (e.g. removing commit access of individual developers on a whim) and part of the reason that Comrel is slower to act is to prevent this type of activity. Hence my question above: Is Comrel not doing the right thing here? Why do we need to delegate this ability directly with the QA team? [0] This is again my thrust that QA is a enabling team, not a punishment team. Tools to prevent commits that are bad. Tools to find bad commits post-commit. Tools to roll-back or revert bad commits. More stuff like "two branches of ::gentoo "master" and "ci" and maybe rsync / users should consume the CI'd branch. I don't expect that all developers understand everything. > > Secondly, it clearly defines the possible disciplinary actions as either > temporary commit access ban, or (in case of repeated offenses) permanent > removal of commit access. > This part seems fine, I think we should have a clearer idea of punishments. > > Thirdly, it removes the unnecessary involvement of ComRel, QA violations > being outside of their scope of interest. Each case of QA violations > is analyzed by QA team individually, and QA team exercises disciplinary > actions independently. At the same time, appeal path via Council is > defined. > I see the QA organization as having one primary mission "making sure that Gentoo users can install and use Gentoo packages". I see the team supporting that in four key areas: - Education: this is content like the devmanual. - Prevention: Tools like repoman (to prevent bad commits from being committed) or a CI branch (to prevent users from seeing bad commits.) - Mitigation: The CI branch again here, helps us quickly find bad commits, and mitigates any bad commit because only the passing CI branch is made available to users, so bad commits are lower impact. - Punishment: If people don't use the tools, or consistently don't take feedback, we should probably not trust them to commit. I find punishment the least effective thing QA can do; the QA organization is an *enabling* organization that enables people to be effective. Removing commit access is not really enabling anyone and unlike focusing on the other three areas (whose impact is multiplied by the number of contributors) removing commit access only affects 1 person at a time. > --- > glep-0048.rst | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/glep-0048.rst b/glep-0048.rst > index f9773c0..55a27a2 100644 > --- a/glep-0048.rst > +++ b/glep-0048.rst > @@ -76,9 +76,14 @@ tree policies are respected. > made by the council. > * Just because a particular QA violation has yet to cause an issue does > not > change the fact that it is still a QA violation. > -* If a particular developer persistently causes breakage, the QA team > - may request that Comrel re-evaluates that developer's commit rights. > - Evidence of past breakages will be presented with this request to > Comrel. > +* If a particular developer persistently causes QA violations (actions > that > + negatively impact the behavior of Gentoo systems, work of other > developers > + or infrastructure facilities), the QA team may issue a temporary > revocation > + of developer's commit access (ban). In case of repeated offenses, the > QA > + team may issue a permanent removal of the commit access (retirement). > All > + the evidence of the violation, as well as ban lenght will be evaluated > + by the QA team for each case individually. The disciplinary decisions > made > + by the QA team are subject to appeal via the council. > * The QA team will maintain a list of current "QA Standards" with > explanations > as to why they are problems, and how to fix the problem. The list is > not > meant by any means to be a comprehensive document, but rather a dynami= c > -- > 2.21.0 > > > --000000000000257191058656fc76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just as a frame, I'm not on QA.

On Fri, Apr 12, 20= 19 at 10:40 AM Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org> wrote:
Update the wording of GLEP 48 to provide clear informa= tion on what kind
of disciplinary actions QA can issue, and in what circumstances they can be exercised.=C2=A0 Remove the unclear reference to ComRel that is either meaningless or violation of scope.

Is t= here a particular driver for this change? E.g. have you been dissatisfied w= ith the current procedure, or perhaps Comrel is not acting on your referral= s?

In general I perceive the QA organization as an= educational / enabling organization (it trains people and writes tools) an= d not as a punishment-based organization (where it shames people for their = mistakes and removes commit access from people who make too many.) This isn= 't to say there isn't room for removing access for committers who r= outinely make mistakes, I just think it ends up supporting this underlying = narrative about the project that (and I'm framing this here) "Gent= oo should be smaller and only composed of elite committers who understand a= ll the complex stuff required to not break things." This type of chang= e was previously discussed on the project list.

If= the goal is to move the project in that direction I'd rather see a vis= ion document or similar ratified by the council to support that direction t= han this slow boiling of a frog.
=C2=A0

According to the old wording, QA could request 're-evaluating commit rights' from ComRel.=C2=A0 This is very unclear, and has been a source = of
confusion more than once.=C2=A0 Firstly, it is unclear whether ComRel merel= y
serves as a body executing the QA team's decision, or whether it is
supposed to make independent judgment (which would be outside its
scope).=C2=A0 Secondly, it suggests that the only disciplinary action
possible would be 're-evaluating commits rights' which sounds like<= br> an euphemism for removing commit access permanently.

The new wording aims to make things clear, and make QA disciplinary
actions independent of ComRel.=C2=A0 Explanation for the individual points<= br> follow.

Firstly, it aims to clearly define the domain of QA actions, and set
a better distinction between QA and ComRel.=C2=A0 In this context, QA
is concerned whenever the developer's action technically affects Gentoo= ,
which includes breaking user systems, Infrastructure tooling, other
packages, etc.=C2=A0 ComRel on the other hand is concerned in actions havin= g
social consequences rather than technical.

<= div>Previous QA teams would often take unilateral action against individual= developers, often for problems that were poorly or under-documented[0]. Th= e infrastructure teams in the past had similar issues (e.g. removing commit= access of individual developers on a whim) and part of the reason that Com= rel is slower to act is to prevent this type of activity. Hence my question= above: Is Comrel not doing the right thing here? Why do we need to delegat= e this ability directly with the QA team?

[0] This= is again my thrust that QA is a enabling team, not a punishment team. Tool= s to prevent commits that are bad. Tools to find bad commits post-commit. T= ools to roll-back or revert bad commits. More stuff like "two branches= of ::gentoo "master" and "ci" and maybe rsync / users = should consume the CI'd branch. I don't expect that all developers = understand everything.
=C2=A0

Secondly, it clearly defines the possible disciplinary actions as either temporary commit access ban, or (in case of repeated offenses) permanent removal of commit access.

This part see= ms fine, I think we should have a clearer idea of punishments.
= =C2=A0

Thirdly, it removes the unnecessary involvement of ComRel, QA violations being outside of their scope of interest.=C2=A0 Each case of QA violations<= br> is analyzed by QA team individually, and QA team exercises disciplinary
actions independently.=C2=A0 At the same time, appeal path via Council is defined.

I see the QA organization as h= aving one primary mission "making sure that Gentoo users can install a= nd use Gentoo packages". I see the team supporting that in four key ar= eas:
=C2=A0- Education: this is content like the devmanual.
=
=C2=A0- Prevention: Tools like repoman (to prevent bad commits from be= ing committed) or a CI branch (to prevent users from seeing bad commits.)
=C2=A0- Mitigation: The CI branch again here, helps us quickly fin= d bad commits, and mitigates any bad commit because only the passing CI bra= nch is made available to users, so bad commits are lower impact.
= =C2=A0- Punishment: If people don't use the tools, or consistently don&= #39;t take feedback, we should probably not trust them to commit.

I find punishment the least effective thing QA can do; the = QA organization is an *enabling* organization that enables people to be eff= ective. Removing commit access is not really enabling anyone and unlike foc= using on the other three areas (whose impact is multiplied by the number of= contributors) removing commit access only affects 1 person at a time.


=C2=A0
---
=C2=A0glep-0048.rst | 11 ++++++++---
=C2=A01 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/glep-0048.rst b/glep-0048.rst
index f9773c0..55a27a2 100644
--- a/glep-0048.rst
+++ b/glep-0048.rst
@@ -76,9 +76,14 @@ tree policies are respected.
=C2=A0 =C2=A0made by the council.
=C2=A0* Just because a particular QA violation has yet to cause an issue do= es not
=C2=A0 =C2=A0change the fact that it is still a QA violation.
-* If a particular developer persistently causes breakage, the QA team
-=C2=A0 may request that Comrel re-evaluates that developer's commit ri= ghts.
-=C2=A0 Evidence of past breakages will be presented with this request to C= omrel.
+* If a particular developer persistently causes QA violations (actions tha= t
+=C2=A0 negatively impact the behavior of Gentoo systems, work of other dev= elopers
+=C2=A0 or infrastructure facilities), the QA team may issue a temporary re= vocation
+=C2=A0 of developer's commit access (ban).=C2=A0 In case of repeated o= ffenses, the QA
+=C2=A0 team may issue a permanent removal of the commit access (retirement= ).=C2=A0 All
+=C2=A0 the evidence of the violation, as well as ban lenght will be evalua= ted
+=C2=A0 by the QA team for each case individually.=C2=A0 The disciplinary d= ecisions made
+=C2=A0 by the QA team are subject to appeal via the council.
=C2=A0* The QA team will maintain a list of current "QA Standards"= ; with explanations
=C2=A0 =C2=A0as to why they are problems, and how to fix the problem.=C2=A0= The list is not
=C2=A0 =C2=A0meant by any means to be a comprehensive document, but rather = a dynamic
--
2.21.0


--000000000000257191058656fc76--