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. |
3 |
|
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. |
7 |
|
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? |
11 |
|
12 |
Vast wholescale breakage is very rare and not something you can base |
13 |
policy on. |
14 |
|
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. |
17 |
|
18 |
Do beware the law of unintended side-effects. |
19 |
|
20 |
|
21 |
|
22 |
|
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 |
> |
112 |
|
113 |
|
114 |
-- |
115 |
Alan McKinnon |
116 |
alan.mckinnon@×××××.com |