 Okay, this is Manoj, the... Shrivastava. Yeah, you can do your surname. I won't even attempt it. He is the Devian Project Secretary and he's going to tell us about multi-winner voting in Devian. Hi, guys. I appreciate you being here, especially knowing that lunch has already started downstairs. I'll try to keep this short because I tried to do this real multi-winner voting strategy talk and then I looked at the amount of math I would have to present and I was able to narrow it down to about 120 pages of equations and I didn't think I would fit it in and I don't think I would have much of an audience left, so I decided I'll convert it into kind of bits from the secretary and where I think what the secretary needs to do should evolve. Status is what's happening thanks to the rest of you guys. The secretary hasn't had much to do this year. We are no longer shooting for maximum GRs in 2008 like we were a couple of years ago. There has been some progress. We have a new victim who has decided to step up and become a kind of backup secretary, in case I get hit by a truck or something. So Malkin has agreed to join in and learn all about the ins and outs of what the secretary does, which thankfully isn't much. All we do is we run votes, we memorize the constitution and have nightmares about it. So, this was a darn short talk. Where should... Okay, devotee. This is the software we use to run our votes. It's not been packaged yet because I could never figure out how to make it a useful package because currently it is very tied into Debian. I mean, it's very useful if you have a GPG key ring, an MPGP key ring, and people in the key ring also are in an LDAP database where they belong to a developer group. If you don't want to run a vote where you have these test criteria, devotee is not very useful for you yet. Whichever I never could figure out how I could package it with a straight face and tell people this is something you might want to install. However, watching synchronized diving on TV in Spanish, a language that I don't understand, I had epiphany. And I now have an idea of how I can modify... Well, actually rewrite devotee to be not just modular, which it already is, but also flexible so that people can create their own votes with different workflows. They can plug in verification methods. They can plug in vote collection methods. So, for example, if SPI uses a web front-end, there are a lot of people who have wanted to run votes using a web front-end as opposed to email signed ballots. I don't understand why. I mean, sending emails so much easier than firing up Firefox. But similarly, there have been people who wanted not to use the file system as a database. They wanted an honest to goodness real database for, again, reasons that I failed to fathom, but it seems to be something that people really like. So, I would like to take devotee the way it is, convert it into... You can plug in your input methods. You plug in your own checks. Decide which checks you want to actually run, which are just non-mandatory. They will be advisory. You didn't sign your ballot, but I'm going to count it anyway if that's the policy of your vote. It would also be nice to plug in various ways of tallying votes. I really like the way we do our voting. It's a variant of a single transferable vote with all kinds of neat criteria. But there are other ways of tallying up the vote, and it might be nice, and I think people have been doing this for DPL elections for the last couple of years. They take the raw data and they figure out who would have been the winner under various forms of tallying up the votes. So, now that I've taught Malkin all that he needs to know about the current way of running votes, I'm going to go ahead and change it all out from under him. Actually, there was a proposal that I received from a couple of people whom I shall not name who said that when I took on the mantle of the secretary, our previous secretary had gone missing for two years at that point, along with a large chunk of money that was never deposited. So, he didn't take the money away. He just held on to the checks until they became invalid, which is why SPI was created. But anyway, that's the end of the story. But then, devotee, the way we know it, was written under fire in the sense that when the DPL election of 2002 started, the only part of devotee that had been written was the part that accepted mail. The part that actually did something with the ballot was written a couple of days later, and the part that actually tallied the vote was done, I think, two days before the vote ended. So, people have been suggesting that I just kind of yank out the current devotee, pull it out of all the public repositories, and then hand over the job to Malkin and let him start from scratch. You know, proper training to be a secretary. He declined, unfortunately, because I think it would have been great training, write your own vote-taking mechanism, and everybody knows you can do the job. We're still only eight minutes in. I really don't have that much more, apart from the original topic of the talk, which is selecting M members of a committee out of a set of candidates and doing so while maintaining the characteristics of a voting mechanism that we already have in the Constitution. The voting process that we have has some nice... it meets some nice criteria. For example, and this might be getting too much into being a vote geek, anonymity. You want a voting system where it doesn't matter who you are, all voters are treated equally. So, nobody is more equal than others. So, no animal farm. Neutrality, that means that no candidate is more important than any other candidate. They're all treated the same by the voting system. We kind of violate this because our further discussion or none of the above option is slightly special in the sense that it cannot be eliminated. Homogeneity, that means the results depend on a proportion of votes. We don't say that you need to have X number of votes and then you are in. You need to beat the other options. Again, we kind of violate this by having the quorum and supermajority restrictions, but barring that, barring... if we have met quorum, we do meet this criteria. Then there are other little things like majority. If a majority of the voters prefer some option over other options, the other option should not win. If there is a set of these things, if voters prefer options in a subset over every other option, not in the subset, then the winner should probably come from the subset that is ranked higher. Well, there are other things like majority winners, majority losers, condorset candidates, condorset losers, smithset. All of these basically come from the criteria, as I told you, that most people prefer a subset over things not in the subset. The winner ought to come from the preferred subset. There are various ways of stating this. The other thing is all the ability. If you've got a small number of voters, it might so happen that you'll get two people with two candidates with equal votes, and you can't decide between them. But your vote mechanism should be such that as the number of voters increases tends to infinity, the probability that more than one winner would emerge should go down to zero. Pareto means that if there is no voter who prefers candidate B over candidate A, but there is at least one person that prefers candidate A to candidate B, candidate B should not win. I kind of like that. There is monotonicity. So that means if you take a bunch of votes and then you allow people to change the votes, and the only change they make is they rank candidate A higher. They do not change the ranking of the other guys. So they just take candidate A and move them up the ballot. The probability of candidate A winning should not decrease. And believe me, there are voting methods where that does happen. So we don't like that. Say suppose you take a bunch of ballots where people have voted for candidate A. Now you increase the total number of candidates, and you call them A1, A2, A3, A4. On every ballot, the ranking that was given to A is the same as the ranking given to all these clones, A1 through An. Then this shouldn't affect anybody else. So if candidate B was winning before, candidate B should still win. If some candidate C was losing before, they should still lose. The presence of clones should not affect the Jedi order. So if we go to multi-winner voting, all these properties ought to be preserved. The additional criteria I put on whatever method we should choose is that if the number of candidates M degenerates to M is equal to 1, that means we want a single winner, the resulting method should be identical to what we currently use. There are also some additional criteria we should meet when we are selecting more than one person. Say suppose you want to select four people out of ten, and there is one super popular candidate you know is going to win. So if you vote for him as being one of the four that you want, you're basically throwing away a vote because he's going to win anyway. So this is called free-riding. You know that your candidate of choice is going to win. You get a free ride by taking your vote that you normally have given to that guy and giving it to somebody else you want in who may or may not win. So you get one candidate elected for free based on your perception that he's going to win anyway. So there are other ways of free-riding by not voting for the guy you want because they are going to win anyway, that apply to different ways of tallying up the votes. And we want a voting mechanism that is resistant to this kind of voting. You can't ever eliminate it totally, but you make it expensive in the sense that if you don't vote for the guy you want, he might not actually win. The other way that people attack various voting systems is if you give preference to the number one vote that people cast. And there is a party, let us say that, let me pick a proper evil subset. Say the US subset of Debian developers decide that they want four US Debian developers to get into the social committee and the vote tallying method is such that it pays special attention to the way you rank the candidates. Then what you do is you tell those Debian developers, you want these four guys in, one fourth of us should rank guy number one first, one quarter of us should put guy number two first, and then so on so that one quarter of our evil American, North American or clique votes one of our guys first so that we evenly distribute our votes so that increase the chances of those four guys getting into the committee. We want a vote system that is called vote management. This is the simplest of the vote management techniques. There are other ways to do vote management. We want to have a voting mechanism that resists managing the vote by a subset of the people. There is also something called the droop criteria. So there is a droop ratio, which is basically you take the total number of votes divided by the number of candidates plus one, you get a ratio. An important criteria is that one such, say if the ratio is X number of people. So if we want to select M members, if at least X number of people put a subset of M as the preferred candidates in their ballots, for every X number of voters, one of their candidates should be selected. So in other words, this is more important in real politics when you have political parties. This is proportionality. That means if you've got two or three or four parties, then even a small party which has only say 10% of the members should be able to get at one tenth of their candidates in the final selection. So in other words, even a small group of people as long as they are above the droop ratio should be able to have a say in the final result. So it doesn't mean that the largest party gets all the votes all the time. Minority views are also represented in the committee, which I think is one of the first candidates for this kind of voting method might be the social committee. I'm not exactly sure where that proposal stands, but I thought we were going to go ahead with it at some point. And there this was brought up whether we will be suffering from the tyranny of the majority or not. And if we manage to write the voting mechanisms as the droop criterion is met, we will not have that problem. So I do have papers that allow us to select a voting mechanism that meets all these criteria. I wanted to print out the paper and bring it over, but it's 288 pages and about 60% of that is pages after pages of mathematical formulae. I think I have managed to wrap my head around it. I have not yet managed to wrap my head around it well enough to actually implement it in court. I hope to be able to do so before we manage to pass the GR that authorizes the social committee. I'll be happy to post links to all these papers. There are three of them out there. Somewhere once I get back to a working computer again. Okay, 20 minutes. I think I've kind of met the minimal criteria for how long a talk needs to be to justify it being here. So if you guys have any questions at all about what the secretary does or what the secretary should be doing, whether there's something that I could be doing better or if you've got opinions on voting systems or you want to delve into details of how we are going to do the STV Condorcet multi-winner voting, I'll be happy to indulge you. I've got several pages of math here for anybody who wants to go deeper in details. One quick question. I think I brought it up during the last TPL vote on the list but I think I'll just try to ask again. Some people were posting their votes publicly and some others were replying saying, hey, what are you doing is stupid and signing that reply quoting the vote in full. If somebody would forward this mail saying, hey, you're doing something stupid to devotee, that would override the replyer's vote, would it? No, it won't because this is essentially a replay attack and devotee is resistant to replay attacks. A replay attack would be sending the same signed vote back to the devotee but what he's saying is that one person sends a signed vote to Debbie Nevelle and another person replies to that vote with, you're stupid, and signs it with his GPG key. So that's a different signature but the same vote for that person. So it's not a replay attack. It's actually a different vote as far as devotee is concerned. I think you're right. If somebody manages to grab, if the original signature has been stripped off, we do check to see if it is double signed. Yeah, okay, but usually if you reply, then the original signature is stripped off because in any way you would quote it and mangle it so that it's a different message. Right, so yes, you're right. My answer to that is don't do it then. I don't know how to prevent that. I don't know how to build in this kind of intelligence and devotee. Maybe a possible solution would be to share the set of verified signatures from Listmaster with devotee or something because we do keep track of, or we can keep track of all the signatures that are validated to all Debbie and List. Obviously it doesn't stop anybody from doing the same idiocy to a non-Deviant List but typically they tend to send them to Debbie and Nevelle because that's where all replies to announce go if you're stupid. I don't think I follow. Somebody has sent in a vote. I quote it and I sign the quote. Right. And then the same thing is sent to the vote. Right, the question is because it would have already gone to a Debbie and Nevelle list, we could give you, oh, we have seen these signatures. Oh, so a replay attack which is... This particular one would be solved. Obviously it wouldn't stop somebody from sending such a message to any other random mailing list but... I don't think it's worth it. It's just an option. If you guys want to do it but I think that we are happy with, don't do it then. I think you are forgetting that some people actually do send votes to Devel and Secretary at the same time. And that would be a valid vote. So you would be rejecting those as well. Yeah, okay. So that's, I mean, it's a whole can of worms of course. So I think it's just better not to handle it and make sure people are not stupid by replying to votes and signing. If you do want to do this anyway, please just delete the UUID which is in the vote that you quoted. If the UUID disappears, then it won't be seen as a valid vote. Right. Right. I mean, I'm not saying we should fix this but if somebody wants to fix it, one way would be to have unique UUIDs. That is like send a mail or you get as a Debbie and Nevelle personal mail saying, this is your ballot and you can use it only once. And then there would be no problem to send it somewhere else. But yeah, I don't know if it's worth the hustle. Probably not. I mean, people who do this, they are calling other people stupid so they deserve it to have the vote ever written. Yeah, that would be good if people actually followed the instruction because now what this would require is, see what this would require is each ballot would have to be different. People would have to change the ballot and add a new UUID. Now, every election and every vote so far, even though the instructions say you've got to do, in the square box you put in one, two, three, four, and so on in the order you prefer. I get at least three to four votes where people have just marked X. So if people can't follow that kind of instruction, I doubted that we'll get everybody adding in their UUID to the ballot. Nice idea, I don't think it will work for us. I have been, I think the last four, there were a whole bunch of people who were telling me that my instructions that I put forward for voting were too complicated for people and they should be more intuitive and there have been several rounds of wording proposed to improve my instructions that, and I must confess I've kind of about reached the end of my rope and I'm going to put my foot down and say, look guys, if you can't follow these instructions as they exist now, I'm really not sure that you can understand the concepts that you're voting upon and can actually help Debian by voting. I've tried not to say this because this is harsh and rude and probably not something the secretary should be saying, but for heaven's sake, I mean how hard are the instructions right now? The other thing is I can say that the secretary will never create a new ballot whoever wants to, the DPL candidates can go create their own darn ballot if they want to get elected and anybody proposing a GR can do the same. Unfortunately, while that sounds nice, I think it will end up with ballots that are equally problematic. Some months ago there were proposals, well, many messages about a certain voting system that encouraged strategic voting. Personally, I like that Condorset voting goes against that, discourages strategic voting. What's your opinion on that? It's not right. So Condorset voting, there is a mathematical proof that it does is resistant to most of the insincere voting hacks that people have tried. Range voting, I'm not convinced, meets those criteria because every time I have asked that person to give me some kind of mathematical proof, all that I've gotten back is a lot of hand-waving and saying that I'll give you examples in which it works that way. And unfortunately, you can come up with any kind of examples like that for every single voting system where for given sets of votes for ballots, they do meet the criteria. But giving examples and anecdotes is not actually mathematical proof. So that's why I have not actually, beyond asking for clarification, I haven't replied to that person because he has been extremely persistent and not very amenable to listening to what other people have been saying. But if you do have some concern that our voting mechanism is not proof against some of these insincere voting mechanisms, feel free to read up the papers that I'll put up on that email that I'll send whenever I get back home. I do have one concern, actually. Our voting system actually faves the compromise, which usually is a good thing. But if there can be cases where we have to do one of two things, which are both extremes, and some more gets a vote on the ballot to do nothing, which is a bad thing, then this do-nothing is usually much more likely to actually win the vote because the people who prefer one end of the extreme will say, yes, one first, and the other end of the extreme, I don't want that, and the middle one, well, okay, if nothing else. And the other end of the people will do the opposite. So the middle is much more likely, and I think that can be a problem in some cases because actually our voting system prefers a favor in decision, which I don't think is a good thing. Unfortunately, I don't think it's a voting system issue. I think it's a social issue. Maybe. Because the voting system can only do what it can try to decide between people's preferences. If people are so polarized as to say that my way or the highway, that means my way and further discussion over everybody else's proposition, I don't think you can solve this mathematically. You have to solve it by having people talk to each other. Yeah, I think you have to be careful about deciding what's a problem or what you want to fix. I actually consider it a great feature that if we are still in a situation where the overall opinion of the project is very divided, that further discussion, which is our way of phrasing the choice that says we aren't ready to make a choice yet, is in effect our default behavior. We're having a discussion last night, very late, about the tech committee, which led to some interesting thoughts that I'm sure you'll all hear about before too long since we get a chance to read our late night notes and figure out what we actually said to each other. But one of the things that came up in that process is that driving things to a vote in a particular timeframe is actually okay because if we aren't yet to the point where we're prepared to make a sort of a group decision, it may well be that the answer is further discussion. And that, in effect, is a sort of twisted way of saying, you know, we weren't ready to vote yet. And I think that we have to be careful because I think, as Manoj has suggested, some of these things are social issues, not, you know, technical issues with the voting system. And in this particular case, if we have something that's hugely contentious and yet we need to make a decision, I don't think that'll be a problem. We've seen a couple cases in the past where we've come to a decision. If we have something where there are two really sort of polar opposite choices and the project's deeply divided then not making a decision until we figure out an option that leads to more social consensus is probably great. Actually, I like to create a sound bite here. Devotee is not a stick to beat part of the project on the headwind. So if we are that divided, we shouldn't be changing our voting mechanism to ramp through a solution and this affect a large chunk of the membership. Anything else? Any ramps against the way Secretary has been behaving? You seem to be mellowing with age, Manoj. At the end of the talk I gave, I did have Lucas come up and ask if... He had the view that sometimes it may be useful to be able to run polls on various different issues and if devotee could be adapted to allow unofficial polls. Do you think it's devotee's place to do that? The new one that I'm proposing, the modular, creative workflow, sure. The way it is now, devotee has been used by various people to run polls. But the way the amount of checks that we do are kind of heavyweight. I mean, it is appropriate to run all those checks, GPG check, LDAP check, et cetera, because the Constitution wants us to do that for GRs and leader votes. It might not be appropriate for anything else. Definitely, if you want to just have people's opinions, do we really care if they are DDs or if it's a self-selecting group anyway? So you might as well want to have people who are interested in tropic as opposed to people who have been blessed by the proper penguin pee. But sure, the new devotee should be lightweight enough that anybody should be able to do it. I'm hoping that I might be able to add in a functionality that we might be able to offer it to our parent organization, namely, SPI, to be able to fit in using their web front end and yet be able to plug in devotee. Because I don't think that SPI currently has multi-winner vote mechanisms that actually meet all these criteria. The simple thing of select one winner, keep them aside, select the second winner by applying condoset sequentially does not meet several of the criteria. It does not meet monotonicity. It is dissolvable, but I'm beginning to forget. When I looked at it, there were at least three criteria of the list that I had selected which were not met. Especially, I don't think it meets the submit two criteria. So it would be nice if we were able to make it useful even for SPI because I think they do more of this select M members out of more than M candidates votes. And I have had requests from all kinds of Linux users groups who want to use devotee and I have had to say that I'm sorry if you don't have Debian's LDAP mechanism, it's not going to be useful for you yet. Actually, the reason it has been taking me so long was I was trying to create an automated workflow processor where you kind of describe a word saying I want a word in which I want to do these kinds of checks and I want to use such and such a tally mechanism and then I wanted something to compose automatically the order in which the checks were run and marshal all the data from one module to the other and do it all automatically and it turns out this is not an easy problem. I mean it's doable, the grid folks have already solved it but they have solved it with a monster set of packages called Wings and Pegasus. I don't want to bring that into devotee. So I decided that if I needed to create a description of a vote and I needed to create a parser that could read the vote and execute it why not use a programming language interpreter? The Perl is a fairly decent parser of these things called descriptions of a vote in the form of a Perl script. So I have kind of let go of my ambitions of doing a workflow generation system inside devotee and I'm just saying that if you want to create a vote you have to write a Perl script, all the check methods will become Perl classes instantiate a Perl class, pass the ballots to it and there will be example scripts that you can use to base it on. It's not as interesting or elegant a solution as a workflow generator but maybe the next secretary will take that upon and we'll have these features soon. Anything else? I thank you guys again for coming here. This was a fairly dull and boring talk and I do appreciate it. Yeah, one last word before we disappear. Since it doesn't get set off in enough minutes thank you for many years of service as the WN secretary. I at least really appreciate it.