1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On 01/29/2011 08:07 AM, Fabian Groffen wrote: |
5 |
> On 28-01-2011 22:11:30 +0100, Tomáš Chvátal wrote: |
6 |
>> So draft we would like to have implemented as Glep update is this diff: |
7 |
>> http://dev.gentoo.org/~scarabeus/glep-0048.diff |
8 |
>> |
9 |
>> Please comment and help us improve the "english" of the whole document |
10 |
>> so it gets accepted :) |
11 |
> |
12 |
> (:Nread http://dev.gentoo.org/~scarabeus/glep-0048.diff) |
13 |
>> --- glep-0048.txt 2006-09-05 22:45:04.000000000 +0200 |
14 |
>> +++ glep-0048.new.txt 2011-01-25 13:49:38.525343000 +0100 |
15 |
>> @@ -34,6 +34,20 @@ |
16 |
>> * The QA team's purpose is to provide cross-team assistance in keeping the |
17 |
>> tree in a good state. This is done primarily by finding and pointing out |
18 |
>> issues to maintainers and, where necessary, taking direct action. |
19 |
>> +* The QA team is directed by a lead, chosen yearly by private or |
20 |
>> + public election among the members of the team. The QA team lead can |
21 |
>> + choose one member as a deputy. The deputy has all of his powers directly |
22 |
>> + delegated from the QA team lead and thus his actions and decisions should |
23 |
>> + be considered equal to those of the QA team lead. The deputy is directly |
24 |
>> + responsible only to the QA team lead. |
25 |
> |
26 |
> Since QA is getting lots of powers these days, I strongly object to |
27 |
> this, see also my comment on becoming a QA member. I suggest the |
28 |
> following: |
29 |
> |
30 |
> The QA lead is yearly elected by the whole dev-community (active |
31 |
> developers), same procedure as being used for a council voting. The |
32 |
> nomination is also done by developers, but they can only chose from the |
33 |
> current QA-members. |
34 |
> |
35 |
>> +* The QA team lead must approve developers who would like to join the project. The |
36 |
>> + applicant must demonstrate a thorough understanding of the duties he would like |
37 |
>> + to perform. By accepting the applicant the QA team lead will accept |
38 |
>> + the responsibility to direct them as part of the team and will be held |
39 |
>> + responsible for any action the team member takes on behalf of the QA team. |
40 |
> |
41 |
> Again, I strongly object to this plan. Instead: |
42 |
> |
43 |
> To become a QA member, one must be a current developer, for at least 6 |
44 |
> months, and one must go through a quiz. The quiz is then evaluated by |
45 |
> the QA lead or a replacing member from the QA team, in the same way as |
46 |
> recruiters evaluate new developers. The outcome of the evaluation is |
47 |
> signed by the QA lead. In case of decline of a new member after the |
48 |
> evalation, the QA lead must be able to provide a written argumentation |
49 |
> of this decline, which can be requested by said member or by devrel. If |
50 |
> providing such argumentation is impossible within a week after |
51 |
> evaluation, QA must accept said member to the QA team. |
52 |
> |
53 |
|
54 |
I whole-heartedly disagree with this. First off, the "line in the sand" |
55 |
concept is completely unnecessary in this case. It barely makes sense |
56 |
when it's used on a massive scale (can't drink until 21 in the US), and |
57 |
it only makes sense there because people could not feasibly be evaluated |
58 |
on an individual basis. In this case, quite clearly they can. Either |
59 |
they have the skills and the motivation, or they don't. Some x month |
60 |
line in the sand makes no difference at all and merely slows people down |
61 |
who would like to help and contribute. We have enough hurdles around |
62 |
here. Why add more? |
63 |
|
64 |
The same can be said for the quiz. If the current QA lead would like to |
65 |
decide that way, it should be up to him. But on the whole it should be |
66 |
the QA leads decision. Personally I think the idea is kind of crazy, and |
67 |
seems like a waste of time. Evaluation can be done quite easily on a |
68 |
case by case basis. Why bother with quizzes? |
69 |
|
70 |
>> +* Any QA team lead decision can be revoked by a major opposing vote from |
71 |
>> + all current QA members. Given the nature of this action new elections |
72 |
>> + should be held within 1 month to elect a new QA team lead. |
73 |
>> * In case of emergency, or if package maintainers refuse to cooperate, |
74 |
>> the QA team may take action themselves to fix the problem. The QA team |
75 |
>> does not want to override the maintainer's wishes by default, but only |
76 |
>> @@ -50,7 +64,7 @@ |
77 |
>> an interim solution and it is expected that a bug will be opened with the |
78 |
>> appropriate team to work towards a correct solution. |
79 |
>> * In the case of disagreement among QA members the majority of established |
80 |
>> - QA members must agree with the action. Some examples of disagreements are: |
81 |
>> + QA members must agree with the action. Some examples of disagreements are: |
82 |
> |
83 |
> sentences are separated by double spaces, nevertheless, this doesn't |
84 |
> belong in this patch |
85 |
> |
86 |
>> whether the percieved problem violates the policy or whether the solution |
87 |
>> makes the situation worse. |
88 |
>> * In the event that a developer still insists that a package does not break |
89 |
>> @@ -59,17 +73,23 @@ |
90 |
>> made by the council. |
91 |
>> * Just because a particular QA violation has yet to cause an issue does not |
92 |
>> change the fact that it is still a QA violation. |
93 |
>> -* If a particular developer persistently causes breakage, the QA team |
94 |
>> - may request that devrel re-evaluates that developer's commit rights. |
95 |
>> - Evidence of past breakages will be presented with this request to devrel. |
96 |
>> +* In case a particular developer persistently causes breakage, the QA |
97 |
>> + lead may request commit rights of given developer to be suspended by |
98 |
>> + the Infra team. Devrel should then proceed to evaluate the situation, by |
99 |
>> + finding a compromise or permanently revoking those rights. |
100 |
>> +* Should a situation arise where a developer causes breakage to the point |
101 |
>> + that it cannot be ascribed to bona-fide mistake, either the QA lead or two |
102 |
>> + members of the QA team can require the Infra team to temporarily suspend |
103 |
>> + access to said developer, pending analysis of the causes and resolution |
104 |
>> + to be provided by the QA team within 14 days of said suspension. |
105 |
>> + Resolution for this kind of issue is completely in hands of the QA team |
106 |
>> + and only the Gentoo Council can revisit the case. |
107 |
> |
108 |
> It seems I feel the same as Rich here. I object against this policy, |
109 |
> instead: |
110 |
> |
111 |
> After QA suspension, resolution must go through devrel with QA lead as the |
112 |
> party that sets up the argumentation/evidence for said actions, and |
113 |
> suggested resolution. However, devrel will evaluate and perform the |
114 |
> final statement/actions here. |
115 |
> |
116 |
>> * The QA team will maintain a list of current "QA Standards" with explanations |
117 |
>> as to why they are problems, and how to fix the problem. The list is not |
118 |
>> meant by any means to be a comprehensive document, but rather a dynamic |
119 |
>> document that will be updated as new problems are discovered. The QA team |
120 |
>> will also do their best to ensure all developer tools are in line with the |
121 |
>> current QA standards. |
122 |
>> -* In order to join the QA team, you must be a developer for at least 4 months |
123 |
>> - and must ask the current lead for approval. |
124 |
>> * The QA team will work with Recruiters to keep related documentation and |
125 |
>> quizzes up to date, so that up and coming developers will have access to all |
126 |
>> of the necessary information to avoid past problems. |
127 |
> |
128 |
> |
129 |
|
130 |
I also 100% agree with Paweł. This diff should probably be separated |
131 |
into 2 different diffs. One with the general structure, one with the |
132 |
very controversial bit. |
133 |
|
134 |
Personally, I think the debate on the teams day to day magic is more or |
135 |
less unnecessary. Every team gets to make decisions on its day to day |
136 |
management without having to jump through hoops (provided they are still |
137 |
in line with the teams mission/purpose). I do not feel it is necessary |
138 |
to add more bureaucracy than is 100% necessary into any teams day to day |
139 |
activities. As long as a team is in line with its mission and isn't |
140 |
causing any problems, they should be left alone. If they begin to cause |
141 |
issues, then it is time for discussion. |
142 |
|
143 |
|
144 |
Regards, |
145 |
- -- |
146 |
Dane Smith (c1pher) |
147 |
Gentoo Linux Developer -- Crypto / Sunrise / x86 |
148 |
RSA Key: http://pgp.mit.edu:11371/pks/lookup?search=0x0C2E1531&op=index |
149 |
-----BEGIN PGP SIGNATURE----- |
150 |
Version: GnuPG v2.0.16 (GNU/Linux) |
151 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
152 |
|
153 |
iQIcBAEBAgAGBQJNRhe4AAoJEEsurZwMLhUxhEEQAL/DoHNnGkouR1NAd/FQndcs |
154 |
/DlPGnyZIoD/62qCw7C/3+eDIaqwjgGNGB3lArSLiOheUINu5Jm2P7zlX6cdiPr5 |
155 |
M6M8wGsLJDhyvnN4EL+b+REqSUYbhW61e5uEt3IPRcaibtp4YwbBb2PdDKkl9fDH |
156 |
/j2GgqkXUWdVGjOZp/vgpkiyFg9HJm1XrEy/rkRAaPdJlV5rJuqZH9h1TNmY8oeh |
157 |
eiC7oaNiFBY/ibuGNYD9lklyP72ooN2gCESXiQuq/+1e13b+DwqOl1nZmABKIIWH |
158 |
tSptWdP5ikhlITLqjsaHJyqeL37EH/R4Jsf/sms2qhGWOh2hi7xUznlOcXFetN9B |
159 |
CJF8E/FWtmDmJkwBnkGsE++ASokbxB9w0m0krmjhXKuHZRzO2VrnjYpr4LiJOFd2 |
160 |
j+vCygpqnMrktC7sDAabKkuuJzZuinQ5dRZnQ6NLnTQ3UB4rMbqeC1djwC0hkSJV |
161 |
uh4+idnZywj1D71OW4r6kw2gRUBS04C/KfNJgKx65dTEF5oYsQaJihh7Vad7YBQE |
162 |
EPvugUaLui5qtX1+tvbIMIJUN+018uaa9idakAfjLxAJb1tqjvRMPTGoS1D/NLDM |
163 |
S7kaXzJTIKhDA6OI/ugtyTHSs/IizTjdIWn58RlZbiMvSZki7x2xbRUDB0Fegwk9 |
164 |
Z2q3xp2RmGLxI8iel+r0 |
165 |
=8SID |
166 |
-----END PGP SIGNATURE----- |