1 |
On Fri, 2019-04-12 at 11:30 -0400, Alec Warner wrote: |
2 |
> On Fri, Apr 12, 2019 at 10:40 AM Michał Górny <mgorny@g.o> wrote: |
3 |
> |
4 |
> > Update the wording of GLEP 48 to provide clear information on what kind |
5 |
> > of disciplinary actions QA can issue, and in what circumstances they can |
6 |
> > be exercised. Remove the unclear reference to ComRel that is either |
7 |
> > meaningless or violation of scope. |
8 |
> > |
9 |
> |
10 |
> Is there a particular driver for this change? E.g. have you been |
11 |
> dissatisfied with the current procedure, or perhaps Comrel is not acting on |
12 |
> your referrals? |
13 |
> |
14 |
|
15 |
Ok, you wanted a driver, so here's some data for the most recent QA ban. |
16 |
|
17 |
QA finished voting within one day (~8 hours, to be precise), and |
18 |
requested ComRel to implement the ban in the European evening |
19 |
of the same day. ComRel needed whole 4 days to vote for implementing |
20 |
this. In the end, according to the data presented to us two ComRel |
21 |
members have voted against implementing this, and three wanted the ban |
22 |
length changed. |
23 |
|
24 |
This proves the existence of two problems. |
25 |
|
26 |
Firstly, the presence of ComRel in the pipeline has delayed the ban four |
27 |
days. You might consider this insignificant if you presume that |
28 |
the purpose of the ban is to satisfy somebody's petty vengeance, as it |
29 |
is frequent for ComRel cases. However, I believe that the ban makes |
30 |
only sense if it aims to discipline the developer in question, |
31 |
and disciplining makes sense only if you act reasonably promptly. |
32 |
|
33 |
The later the ban is established, the more likely it will have adverse |
34 |
effect of 'I understood my mistakes, I apologized, I improved my |
35 |
behavior and you're banning me *now*'. If there were no ComRel |
36 |
in the pipeline, the ban would be set ~4 days earlier, and finished ~4 |
37 |
days earlier instead of putting the developer in silly position |
38 |
of knowing that he's been banned but waiting for another body to confirm |
39 |
it. |
40 |
|
41 |
Secondly and more importantly, ComRel has failed to vote unanimously. |
42 |
This clearly indicates that at least some of the ComRel developers |
43 |
do not respect QA's jurisdiction over technical issues, and believe that |
44 |
they have better authority to judge the technical actions of developers. |
45 |
If that is the case, I'm wondering why those developers haven't |
46 |
volunteered to join QA and express their opinion in the initial vote, |
47 |
and instead chose to try to override QA's decision. |
48 |
|
49 |
In my opinion, the developers who voted 'no' should simply give up their |
50 |
ComRel hats because they have clearly abused their ComRel position, |
51 |
in order to make judgment outside their jurisdiction, and therefore |
52 |
ridiculed the role given to them by GLEP 48. |
53 |
|
54 |
Of course, unless they believe that QA has abused its powers in making |
55 |
the vote. But then, I would have to ask why those ComRel members |
56 |
decided to address this by silently voting 'no' rather than bringing |
57 |
this problem to light. |
58 |
|
59 |
To summarize, I believe the arbitrary and artificial presence of ComRel |
60 |
in GLEP 48 is simply harmful. Furthermore, if ComRel was indeed added |
61 |
because of potential for unprofessional behavior of QA team, |
62 |
the evidence proves that such additional verification should be added |
63 |
for ComRel instead. |
64 |
|
65 |
-- |
66 |
Best regards, |
67 |
Michał Górny |