From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-project+bounces-8685-garchives=archives.gentoo.org@lists.gentoo.org>
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 B5075138334
for <garchives@archives.gentoo.org>; Tue, 23 Apr 2019 21:35:30 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 49E02E0928;
Tue, 23 Apr 2019 21:35:29 +0000 (UTC)
Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142])
(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 CD329E0923
for <gentoo-project@lists.gentoo.org>; Tue, 23 Apr 2019 21:35:28 +0000 (UTC)
Received: by mail-lf1-x142.google.com with SMTP id t11so12870985lfl.12
for <gentoo-project@lists.gentoo.org>; Tue, 23 Apr 2019 14:35:28 -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;
bh=5+FtqvIvpQEDwutk6XXx9JbqEbp+BvpJsMUPvalAcro=;
b=RC2Ro4p3tAQTtMBxAp3E9gacaMXojV7l/Lm1l9+mxrsE8au9Mw7oqylGvq3NOtneA6
Dz5a6FuEJW9Uvn31o0FENyewp0jUMZjUu+sUAC74Q5O/WinpFGDDXpPCFZi2EF77M810
MPZ+S+Doo2iDSBiL892YJ3DmZF2Wv6cqYHKXU2kI0MniK5yKQ0TflBdGZcn9U3PbWjq7
mqsrs44UqCI4SNy1+eeTckFEtHOHOJEdAZnxS7DhYYh6TECMc1mF2Tr8Mc4oI1LUtJl+
6rzVfNmKHTJTzZkzC9ddwgwxtNra4kYKHPkKjN4D6TRpT6B+iPRoeWChR88VcVKqPz6b
2ezw==
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;
bh=5+FtqvIvpQEDwutk6XXx9JbqEbp+BvpJsMUPvalAcro=;
b=bSYB5rXeScxXxiGPEPLNY57jxnI+xVzczltjSRteh738LQLy/Axk838ACMq5RZucZv
+S1ZJjCNRJi9w46n8HfqSR+cM2IyJQKoYiMtZoOeIhCLxv4v8AYFKBpdVgfkik1GlmKG
eJfDGfDoVbm2jKn0NcIXktaIM3iL5ydMcSebfOeMPBB7qVQojjtFnNdVwtp0sCLgrab5
IO8H5nexP7V1Uz/drC/iGpCg8l14hWmxf0f0Oz/+ovHJI3YNoCTDWBywBYGYcty6WHsL
NZyCL3fgTYguNq1IMw4XvFh+KETrCjTQTMa1L0rCcQIz8bm18bjOASIdi0ZiWc/oZIwn
uIxQ==
X-Gm-Message-State: APjAAAXiBAIjLB8bK4biTtdjfdRN7pkv5EDrDXAHaZKENRqtqW4af2GN
BrwC9/IBInjDUGLw0doY8OMdy7BtQNavnEgCW1JLnld808I=
X-Google-Smtp-Source: APXvYqxkZ+uOEsuG7A8ZQhq4YmElXCdV7DSDczjisy7L0/mHHTdYmP0Xa6i7UT6OMFFefS1eCTDfX3LY1cFfRomj7DI=
X-Received: by 2002:ac2:598b:: with SMTP id w11mr15804050lfn.62.1556055326114;
Tue, 23 Apr 2019 14:35:26 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
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> <20190412161039.GA14134@whubbs1.dev.av1.gaikai.org>
<20190412161946.GB14134@whubbs1.dev.av1.gaikai.org> <86439695-e7fa-fa11-31f8-71440c8e73ea@gentoo.org>
In-Reply-To: <86439695-e7fa-fa11-31f8-71440c8e73ea@gentoo.org>
From: Alec Warner <antarus@gentoo.org>
Date: Tue, 23 Apr 2019 17:35:18 -0400
Message-ID: <CAAr7Pr96CA3OV_mU8faWzqBtdLsx++ofgovm3eU_73Y4OTAp0g@mail.gmail.com>
Subject: Re: [gentoo-project] [PATCH] glep-0048: Provide clear rules for
disciplinary actions
To: gentoo-project <gentoo-project@lists.gentoo.org>
Content-Type: multipart/alternative; boundary="000000000000f6e1620587395cdf"
X-Archives-Salt: 1725adbf-36dd-4119-877a-6db4387d3353
X-Archives-Hash: e40db557956495feec63c92bb51fd9bd
--000000000000f6e1620587395cdf
Content-Type: text/plain; charset="UTF-8"
On Tue, Apr 23, 2019 at 2:13 PM Thomas Deutschmann <whissi@gentoo.org>
wrote:
> Hi,
>
>
This is my third draft, I'm trying to keep things concise.
> according to the answer to antarus' question, I understand that in the
> past there were Gentoo developers violating Gentoo QA standards.
>
> There must be a clear process how to deal with such a situation:
>
I agree there needs to be a process. I also tend to agree the current
process is not working (based on mgorny's comments above.)
My guidance is mostly around guardrails; I care less about the specifics
and more about getting the project to be run in reasonable way.
>
> - Which kind of QA violation can cause a ban? At no time should a single
> QA violation allow whoever is current QA lead or QA team to issue a ban.
> I am not saying that current QA team wants to do something like that but
> we need clear rules everyone can understand.
>
> - It must be clear that a ban is the last resort. I.e. the process must
> define something like a warn system so that the developer violating
> Gentoo QA standards knows that he/she has been warned and if he/she
> won't change his/her behavior, a ban (commit bit will flip) will follow.
>
I'm not convinced bans do anything, but I'll elaborate below.
>
> - However, disciplinary actions must happen in time. I.e. you cannot
> silently watch and just complain on IRC for x months and suddenly decide
> to issue a ban because QA team just lost patience. That said, an issued
> warning will time out. If the developer in question stops violating QA
> rules for $time, he/she is back at level 0 so that a new issue won't
> trigger an action (keep in mind: We assume that we all share the same
> goals; if there's a hostile developer causing problems all the time this
> is a Gentoo problem, not a QA problem).
>
I agree that its important not to hide problems. We should have some kind
of data collection that tracks defects, and be able to identity patterns.
If we want to depreciate items (so e.g. mistakes 90d ago mean less) that
also seems relevant. Remember that behind this is the idea that everyone
will make mistakes; so some background level of defects is expected.
>
> - It must be clear that QA can take actions as last resort. Let's say
> developer X received first strike, don't change behavior, maybe will
> receive second strike and still keep violating QA standards, QA has the
> power to remove commit bit.
>
> BUT:
>
> QA actions must be limited in time. After 1 or 2 weeks, commit bit must
> be restored. If the developer in question will keep behavior causing the
> disciplinary action, we can assume that he/she is a hostile developer
> for Gentoo and this will become topic of ComRel.
>
I think this is all about intent right.
- All developers will make mistakes.
- Some mistakes are caught by tools, and some are not.
- Developers who make more mistakes than expected (because again, everyone
makes some) should have more review.
- Developers under review who violate policies *deliberately* should not
remain committers.
I'm not sure bans really help with any of this. The challenge is "which
developers deliberately violate policy" and which ones violate it because
"there are a lot of ways to screw up and everyone screws up sometimes."
This is why I think discussion and transparency help.
- If a committer is committing without repoman for example, its a pretty
deliberate step.
- If a committer has made some mistake often, and we provided guidance to
them (improve documentation, mentorship, etc) and they don't show
improvement, we might count that as deliberate.
I don't think committers who violate policy will be changed by a ban.
Certainly not a ban that is time-delimited (it means I get a 2 week gentoo
vacation!) I'd consider alternatives like:
- A period where the commits need review.
- A ban followed by retraining on specific topics.
- A period where the developer is required to build / patch a CI tool to
catch the bug before getting to commit without review again.
These are all things that enable. Time passing is not an enabler, IMHO.
-A
> Based on this, I cannot vote for
>
> https://archives.gentoo.org/gentoo-project/message/548d9c439a73ae38756c0b92a28137ea
> :
>
> The changed text grants too much power to QA project. As said, QA
> project is responsible for QA in Gentoo (technical things in
> ebuilds/eclass in most cases). QA should never have the privileges to
> decide to forcefully retire a developer or should take actions for
> others (like infra, work of others).
>
> --
> Regards,
> Thomas Deutschmann / Gentoo Linux Developer
> C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
>
>
--000000000000f6e1620587395cdf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Apr 23, 2019 at 2:13 PM Thomas De=
utschmann <<a href=3D"mailto:whissi@gentoo.org" target=3D"_blank">whissi=
@gentoo.org</a>> wrote:<br></div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">Hi,<br>
<br></blockquote><div><br></div><div>This is my third draft, I'm trying=
to keep things concise.<br></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">
according to the answer to antarus' question, I understand that in the<=
br>
past there were Gentoo developers violating Gentoo QA standards.<br>
<br>
There must be a clear process how to deal with such a situation:<br></block=
quote><div><br></div><div>I agree there needs to be a process. I also tend =
to agree the current process is not working (based on mgorny's comments=
above.)</div><div>My guidance is mostly around guardrails; I care less abo=
ut the specifics and more about getting the project to be run in reasonable=
way.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><br>
- Which kind of QA violation can cause a ban? At no time should a single<br=
>
QA violation allow whoever is current QA lead or QA team to issue a ban.<br=
>
I am not saying that current QA team wants to do something like that but<br=
>
we need clear rules everyone can understand.<br></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex"><br>
- It must be clear that a ban is the last resort. I.e. the process must<br>
define something like a warn system so that the developer violating<br>
Gentoo QA standards knows that he/she has been warned and if he/she<br>
won't change his/her behavior, a ban (commit bit will flip) will follow=
.<br></blockquote><div><br></div><div>I'm not convinced bans do anythin=
g, but I'll elaborate below.</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
<br>
- However, disciplinary actions must happen in time. I.e. you cannot<br>
silently watch and just complain on IRC for x months and suddenly decide<br=
>
to issue a ban because QA team just lost patience. That said, an issued<br>
warning will time out. If the developer in question stops violating QA<br>
rules for $time, he/she is back at level 0 so that a new issue won't<br=
>
trigger an action (keep in mind: We assume that we all share the same<br>
goals; if there's a hostile developer causing problems all the time thi=
s<br>
is a Gentoo problem, not a QA problem).<br></blockquote><div><br></div><div=
>I agree that its important not to hide problems. We should have some kind =
of data collection that tracks defects, and be able to identity patterns.</=
div><div>If we want to depreciate items (so e.g. mistakes 90d ago mean less=
) that also seems relevant. Remember that behind this is the idea that ever=
yone</div><div>will make mistakes; so some background level of defects is e=
xpected.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><br>
- It must be clear that QA can take actions as last resort. Let's say<b=
r>
developer X received first strike, don't change behavior, maybe will<br=
>
receive second strike and still keep violating QA standards, QA has the<br>
power to remove commit bit.<br>
<br>
BUT:<br>
<br>
QA actions must be limited in time. After 1 or 2 weeks, commit bit must<br>
be restored. If the developer in question will keep behavior causing the<br=
>
disciplinary action, we can assume that he/she is a hostile developer<br>
for Gentoo and this will become topic of ComRel.<br></blockquote><div><br><=
/div><div>I think this is all about intent right.</div><div><br></div><div>=
- All developers will make mistakes.</div><div>- Some mistakes are caught b=
y tools, and some are not.</div><div>- Developers who make more mistakes th=
an expected (because again, everyone makes some) should have more review.</=
div><div>=C2=A0- Developers under review who violate policies *deliberately=
* should not remain committers.</div><div><br></div><div>I'm not sure b=
ans really help with any of this. The challenge is "which developers d=
eliberately violate policy" and which ones violate it because "th=
ere are a lot of ways to screw up and everyone screws up sometimes." T=
his is why I think discussion and transparency help.</div><div><br></div><d=
iv>=C2=A0- If a committer is committing without repoman for example, its a =
pretty deliberate step.</div><div>=C2=A0- If a committer has made some mist=
ake often, and we provided guidance to them (improve documentation, mentors=
hip, etc) and they don't show improvement, we might count that as delib=
erate.</div><div><br></div><div>I don't think committers who violate po=
licy will be changed by a ban. Certainly not a ban that is time-delimited (=
it means I get a 2 week gentoo vacation!) I'd consider alternatives lik=
e:</div><div>=C2=A0- A period where the commits need review.</div><div>=C2=
=A0- A ban followed by retraining on specific topics.</div><div>=C2=A0- A p=
eriod where the developer is required to build / patch a CI tool to catch t=
he bug before getting to commit without review again.</div><div>=C2=A0</div=
><div>These are all things that enable. Time passing is not an enabler, IMH=
O.</div><div><br></div><div>-A</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><br>
Based on this, I cannot vote for<br>
<a href=3D"https://archives.gentoo.org/gentoo-project/message/548d9c439a73a=
e38756c0b92a28137ea" rel=3D"noreferrer" target=3D"_blank">https://archives.=
gentoo.org/gentoo-project/message/548d9c439a73ae38756c0b92a28137ea</a>:<br>
<br>
The changed text grants too much power to QA project. As said, QA<br>
project is responsible for QA in Gentoo (technical things in<br>
ebuilds/eclass in most cases). QA should never have the privileges to<br>
decide to forcefully retire a developer or should take actions for<br>
others (like infra, work of others).</blockquote><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
<br>
<br>
-- <br>
Regards,<br>
Thomas Deutschmann / Gentoo Linux Developer<br>
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5<br>
<br>
</blockquote></div></div>
--000000000000f6e1620587395cdf--