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