1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Duncan wrote: |
5 |
> Daniel Goller posted <444C5909.1010606@g.o>, excerpted below, on |
6 |
> Sun, 23 Apr 2006 23:50:17 -0500: |
7 |
> |
8 |
>>> * In the case of disagreement on policy among QA members, the majority |
9 |
>>> of established QA members must agree with the action. |
10 |
>> you shouldn't disagree about this policy, or you might as well not have |
11 |
>> this document, write disagree on the solution maybe? |
12 |
> |
13 |
> Don't take this wrong but you did mention you weren't a native English |
14 |
> speaker, and I think this the interpretation demonstrates that. |
15 |
> (That isn't to say it couldn't be made clearer, just that your |
16 |
> interpretation isn't likely to occur to a native English speaker, thus the |
17 |
> discussion.) |
18 |
|
19 |
no, there should not be disagreement on the QA policy, seriously, only |
20 |
disagreement on the solution is logical and possible |
21 |
the exception is not covered by policy, the possibility for exceptions |
22 |
is however integrated into the policy, so the only disagreements could |
23 |
be in how the exception is implemented, maybe 3 QA devs find solution A |
24 |
best while 5 find B best, but all devs should agree that an exception is |
25 |
granted because the current tools do not allow adherence to usual QA |
26 |
standards |
27 |
|
28 |
> |
29 |
> To me (as a native English speaker), it's strange to consider that a |
30 |
> reference to /this/ policy. Rather, the reference is to QA policy and |
31 |
> decision making in general -- how a disagreement on QA policy between |
32 |
> members of the QA team is to be handled. |
33 |
|
34 |
to me a policy is the writing as a whole with all the bullet points, not |
35 |
each individual point being a policy, and even if you would explain yes |
36 |
each point is a policy, then the points should not be argued within QA, |
37 |
see above for what would leave room for argument |
38 |
|
39 |
> |
40 |
> That this is the case would be particularly obvious in context, coming |
41 |
> after (as it does) the previous point, dealing with exceptions due to |
42 |
> imperfect tools and mentioning that there /are/ such exceptions. The |
43 |
> point in question above doesn't /only/ deal with that, thus it's its own |
44 |
> bullet point, but the thought is clearly to provide some guidance in |
45 |
> dynamic situations, where for whatever reason there's a difference of |
46 |
> opinion within QA on how to proceed (as an imperfect tool exception could |
47 |
> legitimately provoke, again, the handy example, not the only case, thus |
48 |
> it's not a sub-point but its own bullet point). |
49 |
> |
50 |
> The other alternative would be unanimous agreement or the decision of the |
51 |
> maintainer in question rules, altho there is of course the middle |
52 |
> possibilities of say 3/5 or 2/3 or 3/4 super-majority required in ordered |
53 |
> to overrule the maintainer. |
54 |
> |
55 |
> As I said, your interpretation, that it applied to /this/ policy, wouldn't |
56 |
> be likely to occur to a native English speaker, and does in fact seem a |
57 |
> bit odd. However, that's not to say the point isn't valid, as it's |
58 |
> certainly best that the document be clear to all, including non-native |
59 |
> English speakers to whom the point as now written obviously isn't entirely |
60 |
> clear. |
61 |
|
62 |
i'm afraid i have to repeat that the policy is the sum of all points, |
63 |
the writing, so all QA devs should agree on this one policy, and only |
64 |
have discussions on solution to individual points, and not the actual |
65 |
points of the policy, if there was room for discussion of the points of |
66 |
the policy, then the policy is not ready for consumption by the |
67 |
developer community |
68 |
|
69 |
> |
70 |
> Actually, the point about a 2/3 (or whatever) super-majority, vs. simple |
71 |
> majority of the QA team needed to overrule a maintainer, is a good one to |
72 |
> debate as well. Perhaps developers would be less worried about abuse if |
73 |
> the majority required was stronger, thus improving the safety margin. |
74 |
> Assuming that's the case, the policy as a whole could probably have more |
75 |
> teeth in the case of a super-majority required, than would be possible if |
76 |
> it's only a simple majority. If some sort of a super-majority was |
77 |
> required, it should be easier to accept certain decisions, when they |
78 |
> seriously impact a developer or Gentoo in general. I know if I had a |
79 |
> disagreement and out of a five member team, two sided with me and three |
80 |
> against, making it a majority-of-one, I'd be less comfortable with the |
81 |
> outcome than if it had required a 2/3 majority, and thus 4 members of the |
82 |
> team voting against me. |
83 |
> |
84 |
> Another way to approach it would be to state that for purposes of packages |
85 |
> (s)he maintains, a developer gets one vote on the QA as well. Thus, in |
86 |
> ordered to overrule h(im|er), the QA team would need 50%+2, since 50%+1 |
87 |
> would be deadlock with the developer siding on the keep things as they are |
88 |
> side. |
89 |
> |
90 |
> The idea in either case is to minimize the possibility of something |
91 |
> occurring without enough of a majority opinion to make the decision look |
92 |
> arbitrary or subject to immediate reversal upon the whims of a single QA |
93 |
> team member, without making it impotent in certain cases due to a |
94 |
> requirement for a unanimous decision. Reason in the middle ground? |
95 |
> |
96 |
|
97 |
well, i do find your majority rules interesting, something that should |
98 |
be discussed and the best solution should be written down and made part |
99 |
of the policy |
100 |
|
101 |
|
102 |
the reason for my feedback was to have things laid out much clearer, |
103 |
less vague and thus avoid problems down the road by situations occuring |
104 |
in which things go like "well i thought i (a QA dev) had the right to |
105 |
...." or "i (reg dev) didn't know they (QA) could do ..." |
106 |
be clear on both sides by laying this out so there are no |
107 |
misunderstandings or misinterpretations |
108 |
|
109 |
|
110 |
and seriously, i never have heard a single point of a policy be called a |
111 |
policy, thus my reply as it has been to the point and in this reply |
112 |
|
113 |
Thanks, |
114 |
|
115 |
Daniel |
116 |
-----BEGIN PGP SIGNATURE----- |
117 |
Version: GnuPG v1.4.2.1 (GNU/Linux) |
118 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
119 |
|
120 |
iD8DBQFETHtg/aM9DdBw91cRArQ1AKCzgD4q7Xmng+R4dGbOw629njM/mgCfdj+P |
121 |
qMmtY4iSgvG1LOPLACvi6zM= |
122 |
=D4eg |
123 |
-----END PGP SIGNATURE----- |
124 |
-- |
125 |
gentoo-dev@g.o mailing list |