Daniel Goller posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 23 Apr 2006 23:50:17 -0500:
>> * In the case of disagreement on policy among QA members, the majority >> of established QA members must agree with the action. > > you shouldn't disagree about this policy, or you might as well not have > this document, write disagree on the solution maybe? Don't take this wrong but you did mention you weren't a native English speaker, and I think this the interpretation demonstrates that. (That isn't to say it couldn't be made clearer, just that your interpretation isn't likely to occur to a native English speaker, thus the discussion.) To me (as a native English speaker), it's strange to consider that a reference to /this/ policy. Rather, the reference is to QA policy and decision making in general -- how a disagreement on QA policy between members of the QA team is to be handled. That this is the case would be particularly obvious in context, coming after (as it does) the previous point, dealing with exceptions due to imperfect tools and mentioning that there /are/ such exceptions. The point in question above doesn't /only/ deal with that, thus it's its own bullet point, but the thought is clearly to provide some guidance in dynamic situations, where for whatever reason there's a difference of opinion within QA on how to proceed (as an imperfect tool exception could legitimately provoke, again, the handy example, not the only case, thus it's not a sub-point but its own bullet point). The other alternative would be unanimous agreement or the decision of the maintainer in question rules, altho there is of course the middle possibilities of say 3/5 or 2/3 or 3/4 super-majority required in ordered to overrule the maintainer. As I said, your interpretation, that it applied to /this/ policy, wouldn't be likely to occur to a native English speaker, and does in fact seem a bit odd. However, that's not to say the point isn't valid, as it's certainly best that the document be clear to all, including non-native English speakers to whom the point as now written obviously isn't entirely clear. Actually, the point about a 2/3 (or whatever) super-majority, vs. simple majority of the QA team needed to overrule a maintainer, is a good one to debate as well. Perhaps developers would be less worried about abuse if the majority required was stronger, thus improving the safety margin. Assuming that's the case, the policy as a whole could probably have more teeth in the case of a super-majority required, than would be possible if it's only a simple majority. If some sort of a super-majority was required, it should be easier to accept certain decisions, when they seriously impact a developer or Gentoo in general. I know if I had a disagreement and out of a five member team, two sided with me and three against, making it a majority-of-one, I'd be less comfortable with the outcome than if it had required a 2/3 majority, and thus 4 members of the team voting against me. Another way to approach it would be to state that for purposes of packages (s)he maintains, a developer gets one vote on the QA as well. Thus, in ordered to overrule h(im|er), the QA team would need 50%+2, since 50%+1 would be deadlock with the developer siding on the keep things as they are side. The idea in either case is to minimize the possibility of something occurring without enough of a majority opinion to make the decision look arbitrary or subject to immediate reversal upon the whims of a single QA team member, without making it impotent in certain cases due to a requirement for a unanimous decision. Reason in the middle ground? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
