Slashdot Mirror
Martin Michlmayr Wins DPL
Strike writes "The votes for the new Debian Project Leader are in and the tallying is over, results here. Martin Michlmayr comes out on top, winning 4-0 going head to head against the other three candidates (with the fourth win being over "no candidate"). Last year's DPL Bdale Garbee came in 2nd, with Branden Robinson and Moshe Zadka coming in 3rd and 4th. Michlmayr's platform can be seen here."
This guy has an interesting and in depth platform. I wish our real world politicians would go at it with this kind of vigor and detail. He is well educated and has been working actively within Debian for the past few years and has real purpose and usefuleness. I wish i could say the same about bureaucrats.
Comment removed based on user account deletion
I'm reading this guy's platform, and honestly having trouble figuring out why he won. He seems to go on and on about his experience, but everything he says about his actual plans seems kind of vague and disjointed, about the only concrete proposal he makes is to get rid of orphaned packages and inactive maintainers.
So it seems like the main reason he won would have to be disillusionment with the other candidates. With Bdale being the incumbent and responsible for whatever has seemingly gone wrong over the past year, Branden being widely seen as too argumentative and controversial, and Moshe being clearly a "protest' candidate stating in his platform that he does not believe he will win, I guess it makes sense that a good number of people would not put any of them as their first choice. If that is what the high-level debate in the community comes down to, I don't think it bodes well for the future of the debian project, though.
It saddens me to no end to see how Martin won the election. If you just ignore Moshe and remove the "None of the above option", which was beaten by all candidates, the results are:
2 beats 3: 238 221 = 17
4 beats 2: 228 224 = 4
4 beats 3: 237 226 = 11
which translated to English means that Bdale won over Branden by 17 votes and Martin won over Bdale by 4 votes and over Branden by 11. That's *fscking* close for this kind of voting system.
Bar Moshe, Martin is probably the worst DPL candidate we've had in a long time: no clear ideas about the direction the project should go, no real technical skills, high visibility in the HR department but irrelevant elsewhere, failure to comunicate effectively at the technical level. The conspiration theorist in me is screaming that he won thanks to recently added developers (there was a surge of new people in the last 6 weeks or so, but it has stopped otherwise). New people have had contact with him and his name is probably still fresh in their minds while Bdale and Branden are more in the background at the moment.
Looking at the tally, I also see there's a lost of people who haven't understood how the voting system works. Next time, if you don't want someone to come out as leader, RANK "NONE OF THE ABOVE" OVER THE UNWANTED CANTIDADES, DAMMIT!
The problem is that, to my knowledge, no one in the Debian project is really qualified (a law degree, or significant experience in the field) to make these kinds of legalistic judgements when it comes down to some of the really weird cases.
I like very much that Debian is about free software, but I am at best ambivalent about all our "legal experts".
http://www.welton.it/davidw/
Now, that is a needless mistake you opened your code up to. You could have easily avoided it by taking the (admittedly rather weak) help the compiler can offer you. Simply add a "sentry" value to the enumeration, that holds the number of distinct values. This is simple and "natural" when you start indexing at zero, not at one like you did. Code:
:)
enum DPL { Martin_Michlmayr = 0, Branden_Robinson, Moshe_Zadka, DPL_CANDIDATES };
DPL result = rand(time(NULL)) % DPL_CANDIDATES;
Note how I do not explicitly assign a "proper" value to the DPL_CANDIDATES sentry value, that is the point since now the compiler automatically assigns the correct value. The initial =0 assignment is optional, but nice for extreme clarity IMO. As you can see, this also removes the need to add 1 to the result, since the modulo operator will now work as intended. Um. Apologies of course if you already knew all this, I just felt like geeking out a bit.
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
I'm pretty sure you're being facetious, but I'll bite, For Educational Purposes. :)
France had an interesting problem, before a popular political reform. They had 7+ candidates in one presidential election, most likeable, with a few unpleasant and one racist downright-unlikable person. France, at this time, used the same voting system we do, called plurality voting. I bet you can guess who won. Of all the voting systems known, plurality is the most likely to give a false representation of voter preference. France no longer uses plurality voting in presidential elections, though they don't use Condorcet's Method either.
Debian uses Condorcet's Method. In this method, voters rank all candidates in their order of preference, and candidates can even tie for nth place on the ballot. The system considers which candidate is prefered over whom, and not their actual "rank" on the ballot. That is, if you tied four candidates for first place, and a fifth candidate for second place, you are only voicing that you prefer any of those four over the fifth candidate.
The election is resolved by running every candidate against every other candidate. That means, given n candidates, (n^2)-n "pair-wise" elections are held. Given 5 candidates, 20 elections. Given 8 candidates, 56 elections. Think of it this way: Given Bush or Gore, who would you pick? Given Bush or Perot, who would you pick? Given Bush or Sharpton, who would you pick? There can be multiple ways to chose the winner of the election. The candidate with the most victories is considered the winner. The candidate with the fewest losses is considered the least disliked. Most of the time, there is not a tie, and these two are the same candidate.
Tallying the votes is a little more obtuse. The easiest way to manually tally the votes uses a grid. From top the bottom and left to right, list the candidates. The rows will be the runners, and the columns will be the opponents. Going left to right, top to bottom, mark each box where the runner was prefered to the opponent. If they were tied, do not mark the box. Do this for each ballot. You will then add the grids resulting from each ballot. Consider each mark a '1', and each unmarked box a '0'. The result is the "Sum Grid".
From the "Sum Grid", you can draw a number of conclusions. Each grid shows the number of voters that prefer the runner to the opponent. Compare the runner's votes to the opponent's votes. The runner with the most victories can be considered the most popular. When there's a tie for first place, the candidate with the least losses could be considered a good choice--the least disliked. You could also add the numbers from each row for an indescriminate popularity vote. The popularity choice doesn't draw any useful conclusions, and can be any candidate except the one with the most losses. There are other possibilities. Condorcet's largest problem is resolving ties for first place.
"None" could be an option.
I'm as mimsy as the next borogove but your mome raths are completely outgrabe.
In standard Condorcet, the only clear winner is one who wins every single pairwise election, not just the one with the most victories. That is, he is preferred to every other candidate, so there is no way you could argue that another candidate would be better suited for the job.
While having the most victories is a possible gauge, one major problem (among others) is that it doesn't weigh victories by importance. For example, if Bush is preferred to 12 minor candidates, and Gore is preferred only to Bush and Buchanan, Bush wins, because he has 12 victories versus 2, which is clearly not good.
Another possible tie breaker is to first find a victory cycle; that is, a set of candidates who are all preferred to every candidate outside the set, but among whom there is no single candidate preferred to all others. Then among this cycle, the tie is broken by some method; a common one (and what Debian seems to be using) is to prefer the candidate with the smallest loss margin. The rationale here is that we'll have to make at least one "wrong" choice (whoever we pick will lose a head-to-head matchup with at least one other candidate), but we should pick the candidate who makes this choice the least wrong. For example, if one candidate loses one head-to-head matchup 90-10, and another loses two matchups, each 55-45, we should prefer the 55-45, because he comes closest to winning all the matchups.
The end result of all this is someone who is either preferred to all other candidates or at least the closest to that that's possible.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10