On 8 February 2014 18:26, Adrian Bunk <b...@stusta.de> wrote:
> On Sat, Feb 08, 2014 at 04:40:22AM +0000, Anthony Towns wrote:
>> I'd consider that tactical voting. Basically, I think the value in the
>> FD option is to be able to say "this option has not been fully baked,
>> and more discussion would be helpful to ensure it is properly understood
>> and the consequences are clear".
> The Constitution disagrees with you on that:
> Options which the voters rank above the default option are options
> they find acceptable. Options ranked below the default options are
> options they find unacceptable.
Well, the constituition was drafted by humans, who do occasionally get
things wrong. Probably whoever came up with that wording was an idiot,
and no one should pay attention to anything he says... [0]
It seems to me, the point of having a vote is one of two things:
- to come up with a decision, despite different options being
available and no easy consensus between them
- to have the group commit formally to a decision so the entire group
is accountable for it
At the point at which someone calls for a vote between various
options, there's a few possible outcomes:
- a decision is made to adopt one of the options
- no decision is made
- the vote gets put on hold and re-held with different/additional options
It seems to me that "no decision is made" is not actually a *useful*
possible outcome of the voting system; but it's effectively what FD
describes, and by giving it extra powers, the voting mechanism
encourages its use.
I'd actually go further, and say that calling options "acceptable" and
"unacceptable" is a bad idea, and is opposed to the
"consensus-building" approach that's really the ideal. It's not that
any of these things aren't "acceptable"; it's all just software, it's
not a big deal to work around even the craziest ideas out there. I
mean, talk about crazy, but how many people are there out there
running operating systems they don't even have the source for? There's
just different ideas, some of which are better than others, and we
occasionally have to pick between them.
> A less disputed example makes it more clear where that does make sense:
> 3 of the 6 TC votes (Steve, Colin, Russ) voted all sysvinit options
> below FD since they do not consider sysvinit acceptable as default
> init system for jessie.
>
> I doubt anyone thinks that further discussion is needed for sysvinit,
> but some TC members do sincerely not consider it an acceptable option.
Yes, that's exactly the inconsistency I'm attacking here. If further
discussion isn't needed, it shouldn't be being voted for.
Voting sysvinit below FD isn't needed in the above case, because
either 5 or 6 of 6 TC votes rank it below the other options. If that
weren't the case, and sysvinit were a contender, and further
discussion wasn't useful, the only thing voting FD above sysvinit
would achieve is avoiding a decision getting made, when that is
exactly the *purpose* of voting.
>> That's a long way different to saying "if my preferred option does not
>> win, we should delay making a decision and keep holding votes until it
>> does win".
> No TC member ranked FD on second place, and all 6 votes stated that
> both D and U are acceptable.
Three TC members voted the L options for systemd and upstart above FD,
and FD above all the T options. (I really hope that won't be the case
on the next vote)
>> independent of Keith and Bdale's ballots.
> Under the assumption that both Keith and Bdale rank DT above FD.
Yes, I essentially specified DT as Bdale and Keith's first choice. The
only other systemd option to rank first was DL, and if that had been
either's first choice, then the result would have been a casting vote
between DL and UL:
DL > DT 5:3
DL > UT {8,7}:{0,1}
DL = UL 4:4
DL > FD {8,7}:{0,1}
(Same result if both voted DL first)
> I'd actually call it a bug in the voting system that the casting vote
> might decide between an option that 3 TC members do not find acceptable,
> and an option that is unanimously considered acceptable. [1]
Sure, that's the power of the word "unacceptable". But it's not like
there's an objective measurement of what's "acceptable" -- it's
(literally) just whether an individual is willing to tolerate
something that's not perfect. If you want to put it in its most
negative light, it's empowering the intolerant, which probably isn't a
terribly healthy thing to do.
The reason that FD works the way it does is to allow a minority of
developers to object to changes they don't like -- like social
contract changes to drop non-free, or constitutional changes to elect
a benevolent dictator for life. That sort of obstructionism is
probably a useful thing to enable to some degree, but it's not
something that should be used tactically in the way that "should I
vote X above or below FD" usually is. Ultimately, you shouldn't have
to think "hmm, I really dislike Y, but I really, really, really
dislike Z; do I put FD just before Z or before Y too?". You should
just have to figure "I like X, dislike Y, hate Z, okay [1] X, [2] Y,
[3] Z, done." and remember to explain to everyone else why you think Z
is horrible and Y is bad.
If it ends up everyone disagrees with you -- or just an equal number
of people and someone lucky enough to have a tie-breaking vote -- and
thinks Y is okay or even Z is, well, that's the way things go.
Sometimes you just don't get what you want. Sometimes, everyone else
actually knows better than you, too.
>> Having Further Discussion be a "yes" or "no" option, rather than being
>> ranked against other options would probably have been a better plan --
>> the result then would presumably be 8:0 FD>*, or 8:0 *>FD.
> That would enforce extreme tactical voting in TC votes for everyone
> wanting to express something like "sysvinit is not acceptable":
No, it wouldn't. It would require anyone in the TC who thinks sysvinit
isn't acceptable to propose a better alternative, and to convince a
majority of committee that that option is in fact better than
sysvinit.
At that point, a majority of votes would rank that option above
sysvinit, and sysvinit would lose the vote. [1], and a better outcome
would be selected.
If you couldn't convince an outright majority of the technical ctte to
vote your option above sysvinit, then claiming one is "acceptable" and
the other isn't is probably not really a technical decision on your
behalf.
> A TC member would have to initially vote "yes" to FD, and only switch
> it to "no" when the remaining votes make it clear that the option he
> considers unacceptable cannot win.
Honestly, anyone who couldn't "accept" *whatever* any five, or four,
or even three [2] of the eight committee members decided, probably
shouldn't be on the committee. The membership of the ctte is carefully
selected so that they'll come up with at least vaguely sensible
decisions. At least on technical matters...
The result of an initial "FD" vote like that, with a plan to change it
once the result became clear, would be either a small inconvenience to
the voter (having to vote twice), or the vote getting cancelled with
the result being "further discussion" -- if there wasn't anything
further to discuss beyond "hey, you people who are voting for sysvinit
are crazy for reasons I've already said", that doesn't seem like a
huge win for the voter, unless they really do prefer an outcome of "no
decision". If a 50% "minority" of the ctte are willing to avoid making
a decision for a reason like that, I guess that's a reasonable
outcome, but I certainly hope it's unlikely.
(So far, "further discussion" has been a plausible result, because
there actually has been further discussion. But that's only been as a
result of the issues raised that have caused people to vote FD first,
not for reasons relating to why FD was initially voted above some
subset of options)
For the sysvinit case, none of the committee are advocating it, either
on its merits, or as a potential compromise, so there's no good reason
for it to be on the ballot at all; obviously if it's not on the
ballot, it wouldn't be the winner. (Ian's re-proposed VL and OL, both
of which were ranked below UL and DL by all six committee members who
voted, eg)
Cheers,
aj
[0] https://lists.debian.org/debian-vote/2002/11/msg00231.html
[1] Unless there was a third option, that lost to sysvinit, but beat
the option that beat sysvinit; in which case things get complicated;
essentially because you have to reconsider whether that option
/really/ beat sysvinit in the first place.
[2] Most of the time I'd accept a pair or a single tech ctte member as
well, but the odds of getting something that's at least a bit whacky
is probably not entirely negligible at that point...
--
Anthony Towns <a...@erisian.com.au>
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cajs_lcxnesxqnpg-npcvp9japxp3mbdgzvmwe6ctva8fyyp...@mail.gmail.com
