-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Duncan wrote: > 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.)
no, there should not be disagreement on the QA policy, seriously, only disagreement on the solution is logical and possible the exception is not covered by policy, the possibility for exceptions is however integrated into the policy, so the only disagreements could be in how the exception is implemented, maybe 3 QA devs find solution A best while 5 find B best, but all devs should agree that an exception is granted because the current tools do not allow adherence to usual QA standards > > 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. to me a policy is the writing as a whole with all the bullet points, not each individual point being a policy, and even if you would explain yes each point is a policy, then the points should not be argued within QA, see above for what would leave room for argument > > 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. i'm afraid i have to repeat that the policy is the sum of all points, the writing, so all QA devs should agree on this one policy, and only have discussions on solution to individual points, and not the actual points of the policy, if there was room for discussion of the points of the policy, then the policy is not ready for consumption by the developer community > > 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? > well, i do find your majority rules interesting, something that should be discussed and the best solution should be written down and made part of the policy the reason for my feedback was to have things laid out much clearer, less vague and thus avoid problems down the road by situations occuring in which things go like "well i thought i (a QA dev) had the right to ...." or "i (reg dev) didn't know they (QA) could do ..." be clear on both sides by laying this out so there are no misunderstandings or misinterpretations and seriously, i never have heard a single point of a policy be called a policy, thus my reply as it has been to the point and in this reply Thanks, Daniel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFETHtg/aM9DdBw91cRArQ1AKCzgD4q7Xmng+R4dGbOw629njM/mgCfdj+P qMmtY4iSgvG1LOPLACvi6zM= =D4eg -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list
