I am not completely sure, but I think both ways accomplish the same thing,
if you always only use the >= criterium.
My way seems more flexible though, since you can use it with >= or >, or
2/3 majority over FD requirement, and still get sane results.
I also think my way is simpler, from a high-level point of view. By
removing the §A.6.3 from the middle, you get pure Condorcet. Adding the
FD-comparison to the end result of that is fairly easy to reason about,
assuming pure Condorcet in itself is sane. Keeping §A.6.3 in the middle
where it is now, and only changing > to >= as you suggest, I don't have a
model in my head to understand all the consequences.
Regards, Thue
2014-02-27 20:20 GMT+01:00 Ian Jackson <ijack...@chiark.greenend.org.uk>:
> Thue Janus Kristensen writes ("Debian's custom use of Condorcet and
> later-no-harm"):
> > There is what I consider an unnecessary problem with later-no-harm [1] in
> > Debian's use of the Condorcet voting method in the Debian Constitution
> > §A.6.3 [2].
>
> Yes. I disagree with your analysis, though: I think the root cause is
> the requirement that the winning option _strictly beat_ FD.
>
> If A.6.3 were changed to >= then this problem could not arise unless
> FD were tied with another option.
>
>
> Or to put it another way: if we had a straight vote:
> 4 voters: A > FD
> 4 voters: FD > A
> then I think it is entirely proper to allow the elector with the
> casting vote to choose between A and FD.
>
> If there is a tie but no elector with a casting vote, the results
> should be FD, obviously.
>
>
> Whether routine use of the casting vote in TC votes is a good idea is
> a different matter. This came up in today's IRC meeting. The obvious
> answers are (a) change the size of the committee (b) give the casting
> vote to the DPL instead.
>
> Ian.
>
