From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A50F1138247 for ; Wed, 22 Jan 2014 10:58:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 59FF6E0F4A; Wed, 22 Jan 2014 10:58:48 +0000 (UTC) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 24E2EE0F3B for ; Wed, 22 Jan 2014 10:58:46 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id oy12so120390veb.23 for ; Wed, 22 Jan 2014 02:58:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dGC6/S8DRpuO2AYeDCoAJVB3yVNtZ2rMKQ3kdqce388=; b=V0L9WqNBZ1+DXhu5IgXzTcjb3GMfEthb3KVaW/sDyDpzZTz9B/Ta53HAn58y/7+mZH BcJ1TlkZ0u1huK+wUCxf4ILGF1M9i8gkDMvE1/pqus1ifWMdSEo0YehPAgTRmRGdnX0A dZRpg+WX8wWJBx7yhy7tdt9Kd24gysX9chYMMj03pOm/ggcp/0j1h+qocG2ALkelfNBk oAuQXX3xruO4esO3Jn+030f0fP+ECjavtcUSouV4xaXviFi5wYulbZgAjQuFUg/U01Qc nRZBokaN8uCjMd6oWZdHCVaWI3LjX7s3vo89n1AD0xLBMpCPnT2PMB6yIySvEAKapwdL pi1w== X-Gm-Message-State: ALoCoQnls3wJIvxUsFQQfXk5BmbyDJm6RjKvoCCO8LplKWCBrU8oT4NDXMob3Fln7cGJJX0UDwNk Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.58.49.161 with SMTP id v1mr425346ven.5.1390388326037; Wed, 22 Jan 2014 02:58:46 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.220.59.71 with HTTP; Wed, 22 Jan 2014 02:58:45 -0800 (PST) X-Originating-IP: [173.8.165.226] In-Reply-To: <52DF6C7E.8020908@gmail.com> References: <20140119050224.GA7898@laptop.home> <20140120035446.063a31be@TOMWIJ-GENTOO> <52DD2E2A.2020303@gmail.com> <20140121155616.6a8cdf9b@TOMWIJ-GENTOO> <52DF6C7E.8020908@gmail.com> Date: Wed, 22 Jan 2014 02:58:45 -0800 X-Google-Sender-Auth: 92xHc3cJgMLu_lvnF4F90lgy1to Message-ID: Subject: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights From: Alec Warner To: Gentoo Dev Content-Type: multipart/alternative; boundary=089e01229e1c46130e04f08d023e X-Archives-Salt: 3d35d564-95d0-43bd-842f-8a2b12ff356c X-Archives-Hash: 0806b4bb763f2f44a9b906104c494d74 --089e01229e1c46130e04f08d023e Content-Type: text/plain; charset=UTF-8 On Tue, Jan 21, 2014 at 11:00 PM, Alan McKinnon wrote: > I don't want to appear rude, but when reading this entire mail all I see > is someone who has probably never had to do it for real. > > People are not machines. Volunteers really do not like having their > freely given time nullified and access removed because one person > thought it was deserved. > Do you realise the message that is sent by denying someone access? You > are saying that person is not good enough to work on Gentoo. Do you > really want to send that message? > Of course it is. We want to send the message that if a person's contributions are not up to par, their access to commit to the project will be revoked, until they can prove that they can contribute at a level that is not detrimental to users or other developers. A large portion of the QA team's role in Gentoo is to define what 'par' means and at some level, get the community to agree with them. Developer mentorship, for example, generally requires that a prospective developer submits changes to their mentor and the mentor reviews them. Part of that process is to determine that prospective developers can contribute at the expected level and we have quizzes to try and verify that developers understand key facets of ebuild development. Certainly if a prospective developer routinely submits faulty ebuilds and doesn't show improvement, we are unlikely to grant them commit access. > > Vast wholescale breakage is very rare and not something you can base > policy on. > Rich's most recent reply is the most sane proposal I've seen so far. > Revoking access is a human problem and is solved with human solutions. > > Do beware the law of unintended side-effects. > > > > > On 01/21/14 16:56, Tom Wijsman wrote: > > On Mon, 20 Jan 2014 16:09:46 +0200 > > Alan McKinnon wrote: > > > >> Speaking as someone who had this power in his day job, for QA to be > >> able to suspend accounts is a very bad idea indeed. It always ends > >> badly. I suspended 20+ accounts in my current job over the years and > >> the number of cases where it was the right thing to do is precisely 0. > > > > The relation between "using power" and "having power is a bad idea" is > > non-existing; it is rather how that power is used that determines > > whether it is a good idea than whether one is able to use that power. > > > >> It was always a case of ill-advised action taken out of frustration, > >> or bypass the training step, or don't try hard enough to reach the > >> "infringer" and communicate like grown adults. Yup, I did all three. > > > > The prior experience demonstrated here shows how frustration or lack of > > proper communication are really good symptoms to investigate and learn > > from; however, these symptoms seem non-existing with our QA lead. > > > >> Suspending an account is a very serious thing to undertake, the > >> effects on the suspended person are vast and this power should never > >> lie with the person who is feeling the pain. > > > > This is the core symptom of the way you do QA, if you are the person > > that is feeling pain then you need to reconsider your QA position; the > > thing feeling the pain here is the Portage tree, and the QA team is > > just ensuring its quality and thus should not get emotional or > > personally affected by the developers' changes to some bits 'n bytes. > > > > Of course one could see QA as defending the Portage tree with our heart; > > but not that literally, at least not up to the point that one gets > > painfully hurt or even just frustrated... > > > >> Instead, there are well established channels to the body who can make > >> the decision. If QA has a problem with a dev for any reason > >> whatsoever, then QA should make a well-thought out case to that other > >> body for decision. > > > > Adding extra bodies adds more delay; furthermore, these bodies have > > less time, understanding and more about the technical QA issue at hand. > > > > If a developer does an unannounced mass action that breaks the tree > > severely or is heavily prohibited by policy, is unreachable while he > > continues to commit this; then it would be handy to "temporarily" be > > able to withdraw the commit access to bring it to that developer's > > attention. This is under the assumption that we have tried to contact > > the person multiple time and after a reasonable amount of time the > > person has not responded; if we still then need to wait for another > > team to notice, investigate and finally take action whereas we have > > already took the decision, ... > > > > This is rather to note that we need have a talk to coordinate that mass > > action and unbreak the tree, than it is to punish that developer by > > hitting with a ruler on his/her hand; in a sense of "let's fix the > > damage to the tree and proceed". > > > > There even can happen worse things; like misusing 'pkgmove', the > > @system set or similar that can cause some real havoc. It is in this > > occasion where a developer hasn't discussed or talked to anyone earlier > > before proceeding with a change he knows he shouldn't do, as well as > > ignoring us afterwards; that we simply temporarily cannot allow further > > commits, simply because the developer seems "technically unable to > > follow the policy and its enforcement". > > > > This is similar to how you have Gentoo support ops in #gentoo, Gentoo > > chat ops in #gentoo-chat and individual ops in individual IRC channels; > > if they had to rely on another body which would be the group contacts or > > FreeNode, you would have to wait a long for them to kick, ban or mute. > > > > If the non-technical ComRel lead has this power, then why doesn't the > > technical QA lead have this power? After all, the technical lead assures > > the quality of what the developer has access to; like I stated above, > > the technical lead has more time, understanding and knows the issue. > > > > You can see this as ComRel improving the QA of the community relations, > > whereas QA is improving the QA of the Portage tree and its commits; to > > some extent it even becomes questionable why ComRel can suspend access > > to the Portage tree, but I guess for revert wars between developers. > > > >> Anything else is madness and open invitation for it to all go south. > > > > This is a too broad generalization on the basis of one use case. > > > > See power as an useful temporary tool for when it is absolute necessary, > > don't see it as a permanent tool for whenever something goes wrong; the > > former usefulness leads to success, the latter madness leads to sadness. > > > > > -- > Alan McKinnon > alan.mckinnon@gmail.com > > > --089e01229e1c46130e04f08d023e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 21, 2014 at 11:00 PM, Alan McKinnon <alan.mckinnon@gmail.c= om> wrote:
I don't want to appear rude, but when re= ading this entire mail all I see
is someone who has probably never had to do it for real.

People are not machines. Volunteers really do not like having their
freely given time nullified and access removed because one person
thought it was deserved.

Do you realise the message that is sent by denying someone access? You
are saying that person is not good enough to work on Gentoo. Do you
really want to send that message?

Of co= urse it is. We want to send the message that if a person's contribution= s are not up to par, their access to commit to the project will be revoked,= until they can prove that they can contribute at a level that is not detri= mental to users or other developers. A large portion of the QA team's r= ole in Gentoo is to define what 'par' means and at some level, get = the community to agree with them.

Developer mentorship, for example, generally requires t= hat a prospective developer submits changes to their mentor and the mentor = reviews them. Part of that process is to determine that prospective develop= ers can contribute at the expected level and we have quizzes to try and ver= ify that developers understand key facets of ebuild development. Certainly = if a prospective developer routinely submits faulty ebuilds and doesn't= show improvement, we are unlikely to grant them commit access.
=C2=A0

Vast wholescale breakage is very rare and not something you can base
policy on.

Rich's most recent reply is the most sane proposal I've seen so far= .
Revoking access is a human problem and is solved with human solutions.

Do beware the law of unintended side-effects.




On 01/21/14 16:56, Tom Wijsman wrote:
> On Mon, 20 Jan 2014 16:09:46 +0200
> Alan McKinnon <alan.mcki= nnon@gmail.com> wrote:
>
>> Speaking as someone who had this power in his day job, for QA to b= e
>> able to suspend accounts is a very bad idea indeed. It always ends=
>> badly. I suspended 20+ accounts in my current job over the years a= nd
>> the number of cases where it was the right thing to do is precisel= y 0.
>
> The relation between "using power" and "having power is= a bad idea" is
> non-existing; it is rather how that power is used that determines
> whether it is a good idea than whether one is able to use that power.<= br> >
>> It was always a case of ill-advised action taken out of frustratio= n,
>> or bypass the training step, or don't try hard enough to reach= the
>> "infringer" and communicate like grown adults. Yup, I di= d all three.
>
> The prior experience demonstrated here shows how frustration or lack o= f
> proper communication are really good symptoms to investigate and learn=
> from; however, these symptoms seem non-existing with our QA lead.
>
>> Suspending an account is a very serious thing to undertake, the >> effects on the suspended person are vast and this power should nev= er
>> lie with the person who is feeling the pain.
>
> This is the core symptom of the way you do QA, if you are the person > that is feeling pain then you need to reconsider your QA position; the=
> thing feeling the pain here is the Portage tree, and the QA team is > just ensuring its quality and thus should not get emotional or
> personally affected by the developers' changes to some bits 'n= bytes.
>
> Of course one could see QA as defending the Portage tree with our hear= t;
> but not that literally, at least not up to the point that one gets
> painfully hurt or even just frustrated...
>
>> Instead, there are well established channels to the body who can m= ake
>> the decision. If QA has a problem with a dev for any reason
>> whatsoever, then QA should make a well-thought out case to that ot= her
>> body for decision.
>
> Adding extra bodies adds more delay; furthermore, these bodies have > less time, understanding and more about the technical QA issue at hand= .
>
> If a developer does an unannounced mass action that breaks the tree > severely or is heavily prohibited by policy, is unreachable while he > continues to commit this; then it would be handy to "temporarily&= quot; be
> able to withdraw the commit access to bring it to that developer's=
> attention. This is under the assumption that we have tried to contact<= br> > the person multiple time and after a reasonable amount of time the
> person has not responded; if we still then need to wait for another > team to notice, investigate and finally take action whereas we have > already took the decision, ...
>
> This is rather to note that we need have a talk to coordinate that mas= s
> action and unbreak the tree, than it is to punish that developer by > hitting with a ruler on his/her hand; in a sense of "let's fi= x the
> damage to the tree and proceed".
>
> There even can happen worse things; like misusing 'pkgmove', t= he
> @system set or similar that can cause some real havoc. It is in this > occasion where a developer hasn't discussed or talked to anyone ea= rlier
> before proceeding with a change he knows he shouldn't do, as well = as
> ignoring us afterwards; that we simply temporarily cannot allow furthe= r
> commits, simply because the developer seems "technically unable t= o
> follow the policy and its enforcement".
>
> This is similar to how you have Gentoo support ops in #gentoo, Gentoo<= br> > chat ops in #gentoo-chat and individual ops in individual IRC channels= ;
> if they had to rely on another body which would be the group contacts = or
> FreeNode, you would have to wait a long for them to kick, ban or mute.=
>
> If the non-technical ComRel lead has this power, then why doesn't = the
> technical QA lead have this power? After all, the technical lead assur= es
> the quality of what the developer has access to; like I stated above,<= br> > the technical lead has more time, understanding and knows the issue. >
> You can see this as ComRel improving the QA of the community relations= ,
> whereas QA is improving the QA of the Portage tree and its commits; to=
> some extent it even becomes questionable why ComRel can suspend access=
> to the Portage tree, but I guess for revert wars between developers. >
>> Anything else is madness and open invitation for it to all go sout= h.
>
> This is a too broad generalization on the basis of one use case.
>
> See power as an useful temporary tool for when it is absolute necessar= y,
> don't see it as a permanent tool for whenever something goes wrong= ; the
> former usefulness leads to success, the latter madness leads to sadnes= s.
>


--
Alan McKinnon alan.mckinnon@gmail.com



--089e01229e1c46130e04f08d023e--