Re: Better quorum change proposal, with justification
Raul Miller said:
>Which makes at least some sense: only 19 people actively approved of A,
>while 20 actively approved of B. Granted, this mechanism only kicks in
>for votes with very low turnout or where significant numbers of people
>don't actively approve of options, but I'm not convinced that this
>example shows that the mechanism is flawed.
Yep. But of the 20 who actively approved of B, 19 prefered A.
Meanwhile, nobody actively opposed A, but 19 people actively opposed B.
Choosing B is a good way to start flame wars. Choosing A is a good way
not to. Choosing D is a good way to come up with a better option.
Which is chosen?
<sarcasm>Ah, I see: Debian's policy is to encourage flame wars!</sarcasm>
--
Seriously, Manoj's system *isn't* a quorum system.
"Quorum" is to make sure enough people are present for the discussion.
(Perhaps the correct way to count quorum is "number of developers
sending email about the topic during the discussion period"... heh.
That might actually work.)
I have trouble thinking of a single correct justification for Manoj's
system.
None have been offered on this list; all the justifications I've heard
for Manoj's system are actually justifications for one of the following
two things:
* The proper scheme for making sure that an appropriate number of people
approve of something is called "getting seconds" (and you've already
got that).
* The proper scheme for deferring to the default option unless there's a
strong enough preference is margin-of-victory-over-default.
I will now try to justify Manoj's "quorum" system.
"No proposal can be implemented by fewer than R people, where R is the
quorum. Therefore there's no point in approving any proposal with fewer
than R people actively approving of it."
This would represent the effect of Manoj's "quorum" scheme effectively.
It sounds completely bogus to me, of course, given the curious method of
determining quorum.
--Nathanael
Reply to: