[gentoo-dev] Re: QA Proposal v3

[Duncan]

Daniel Goller posted <444C5909.1010606@g.o>, 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@g.o mailing list