Gentoo Archives: gentoo-dev

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
Date: Wed, 22 Jan 2014 07:00:25
In Reply to: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights by Tom Wijsman
1 I don't want to appear rude, but when reading this entire mail all I see
2 is someone who has probably never had to do it for real.
4 People are not machines. Volunteers really do not like having their
5 freely given time nullified and access removed because one person
6 thought it was deserved.
8 Do you realise the message that is sent by denying someone access? You
9 are saying that person is not good enough to work on Gentoo. Do you
10 really want to send that message?
12 Vast wholescale breakage is very rare and not something you can base
13 policy on.
15 Rich's most recent reply is the most sane proposal I've seen so far.
16 Revoking access is a human problem and is solved with human solutions.
18 Do beware the law of unintended side-effects.
23 On 01/21/14 16:56, Tom Wijsman wrote:
24 > On Mon, 20 Jan 2014 16:09:46 +0200
25 > Alan McKinnon <alan.mckinnon@×××××.com> wrote:
26 >
27 >> Speaking as someone who had this power in his day job, for QA to be
28 >> able to suspend accounts is a very bad idea indeed. It always ends
29 >> badly. I suspended 20+ accounts in my current job over the years and
30 >> the number of cases where it was the right thing to do is precisely 0.
31 >
32 > The relation between "using power" and "having power is a bad idea" is
33 > non-existing; it is rather how that power is used that determines
34 > whether it is a good idea than whether one is able to use that power.
35 >
36 >> It was always a case of ill-advised action taken out of frustration,
37 >> or bypass the training step, or don't try hard enough to reach the
38 >> "infringer" and communicate like grown adults. Yup, I did all three.
39 >
40 > The prior experience demonstrated here shows how frustration or lack of
41 > proper communication are really good symptoms to investigate and learn
42 > from; however, these symptoms seem non-existing with our QA lead.
43 >
44 >> Suspending an account is a very serious thing to undertake, the
45 >> effects on the suspended person are vast and this power should never
46 >> lie with the person who is feeling the pain.
47 >
48 > This is the core symptom of the way you do QA, if you are the person
49 > that is feeling pain then you need to reconsider your QA position; the
50 > thing feeling the pain here is the Portage tree, and the QA team is
51 > just ensuring its quality and thus should not get emotional or
52 > personally affected by the developers' changes to some bits 'n bytes.
53 >
54 > Of course one could see QA as defending the Portage tree with our heart;
55 > but not that literally, at least not up to the point that one gets
56 > painfully hurt or even just frustrated...
57 >
58 >> Instead, there are well established channels to the body who can make
59 >> the decision. If QA has a problem with a dev for any reason
60 >> whatsoever, then QA should make a well-thought out case to that other
61 >> body for decision.
62 >
63 > Adding extra bodies adds more delay; furthermore, these bodies have
64 > less time, understanding and more about the technical QA issue at hand.
65 >
66 > If a developer does an unannounced mass action that breaks the tree
67 > severely or is heavily prohibited by policy, is unreachable while he
68 > continues to commit this; then it would be handy to "temporarily" be
69 > able to withdraw the commit access to bring it to that developer's
70 > attention. This is under the assumption that we have tried to contact
71 > the person multiple time and after a reasonable amount of time the
72 > person has not responded; if we still then need to wait for another
73 > team to notice, investigate and finally take action whereas we have
74 > already took the decision, ...
75 >
76 > This is rather to note that we need have a talk to coordinate that mass
77 > action and unbreak the tree, than it is to punish that developer by
78 > hitting with a ruler on his/her hand; in a sense of "let's fix the
79 > damage to the tree and proceed".
80 >
81 > There even can happen worse things; like misusing 'pkgmove', the
82 > @system set or similar that can cause some real havoc. It is in this
83 > occasion where a developer hasn't discussed or talked to anyone earlier
84 > before proceeding with a change he knows he shouldn't do, as well as
85 > ignoring us afterwards; that we simply temporarily cannot allow further
86 > commits, simply because the developer seems "technically unable to
87 > follow the policy and its enforcement".
88 >
89 > This is similar to how you have Gentoo support ops in #gentoo, Gentoo
90 > chat ops in #gentoo-chat and individual ops in individual IRC channels;
91 > if they had to rely on another body which would be the group contacts or
92 > FreeNode, you would have to wait a long for them to kick, ban or mute.
93 >
94 > If the non-technical ComRel lead has this power, then why doesn't the
95 > technical QA lead have this power? After all, the technical lead assures
96 > the quality of what the developer has access to; like I stated above,
97 > the technical lead has more time, understanding and knows the issue.
98 >
99 > You can see this as ComRel improving the QA of the community relations,
100 > whereas QA is improving the QA of the Portage tree and its commits; to
101 > some extent it even becomes questionable why ComRel can suspend access
102 > to the Portage tree, but I guess for revert wars between developers.
103 >
104 >> Anything else is madness and open invitation for it to all go south.
105 >
106 > This is a too broad generalization on the basis of one use case.
107 >
108 > See power as an useful temporary tool for when it is absolute necessary,
109 > don't see it as a permanent tool for whenever something goes wrong; the
110 > former usefulness leads to success, the latter madness leads to sadness.
111 >
114 --
115 Alan McKinnon
116 alan.mckinnon@×××××.com