Re: I hereby resign as secretary
Manoj Srivastava wrote: > > I am hereby resigning as secretary, effective immediately. Thank you very much for your work in such a difficult role for so long. Debian is certainly a better project for your efforts. > Mistakes happen. Mistakes can be recovered from. What can not, > however, is relationships, and trust, and this works both ways. It has > been made clear to me that the project no longer trusts me, and many > consider that I have been the epitome of sleaze over the years, > manipulating votes for my own ends. That hurts. I have also read > planet. The amount of vitriol there makes it untenable for me to > participate in any efforts to recover from this mess. I, for one, have never felt that you have gamed the system for your own ends. I believe that you have always done your personal best to be as fair as possible. I believe that you understand the nature of your past role as Secretary and tried to be as open as you could in the process. I trust you. I believe that a large portion of the project trusts you, also. > As to the people who emailed me that they are putting together a > petition for the DAM to have me removed from the project, I hear you > too. I am going to spend the next few days evaluating how important the > project is to me, and whether I should save you the bother or an > expulsion process. The project would suffer greatly if you left. At a conference long ago, I got a chance to sit with Ian Murdock[1]. One of the slides the presenter had was a bunch of penguins surrounding and looking on one that was laying down. The presenter used this slide to indicate that Linux users will help their fallen comrade. The presenter went on to say that it looked like the penguins, as pictured, were eating their young. That is when Ian pointed out to me how true that was in the Linux community. I wonder if Debian is exemplifying this behavior. A lot of good people have retired lately. It is starting to feel like that block of homes that has one too many For Sale signs. Why is everyone leaving? What is so bad about the area? What do they know that I don't? -- John H. Robinson, IV jaq...@debian.org http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html [1] http://en.wikipedia.org/wiki/Ian_Murdock -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: First call for votes for the Lenny release GR
Manoj Srivastava wrote: > > I was just thinking of postposing the end-of-vote cron job, so > no re-voting would be needed. > > If there is sufficient support, we could also scrap the current > vote, change our ballot, add options to it, or something, and restart > the vote, but that would need a strong grass roots support (I do not > think the secretary has the power to do so). I would like to see an updated announcement outlining the change in the voting timeframe. This way there is (hopefully) less confusion when the end of vote cron job does not come when expected (as per the original call for votes). I woud like to see this vote run its course. I see no need to modify the ballot at all. -- John H. Robinson, IV jaq...@debian.org http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The Unofficial (and Very Simple) Lenny GR: call for votes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To: debian-proj...@lists.debian.org, debian-vote@lists.debian.org Date: 2008-12-15T20:59:50+ Adeodato Sim?? wrote: > > This is an unofficial vote, but at least it will be easy to vote in. > If > FD wins in the official one, and depending on the participation on > both, > it may also give us a good approximation about what the developers > think > with respect to releasing Lenny. I support the right or priviledge of a researcher to run a poll on the topic of their choosing. I further support the right or priviledge of a Debian Developer to run a poll on a topic associatied with Debian. I support this specific poll. Keep up the work. - -- John H. Robinson, IV jaq...@debian.org http WARNING: I cannot be held responsible for the above, sbih.org ()(:[ as apparently my cats have learned how to type. spiders.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklGxh8ACgkQrelPZQd5nnRyRQCfSk8lPFXWWCiXUL4/ZdnXGafE dKcAn03YZ99mgQO0wzoh4aKJkvANdwlf =FkYq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DFSG violations in Lenny: new proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manoj Srivastava wrote: > > ,[ Proposal 5: allow Lenny to release with firmware blobs ] > | 1. We affirm that our Priorities are our users and the free software > | community (Social Contract #4); > | > | 2. We acknowledge that there is a lot of progress in the kernel firmware > | issue; most of the issues that were outstanding at the time of the > | last stable release have been sorted out. However, new issues in the > | kernel sources have cropped up fairly recently, and these new issues > | have not yet been addressed; > | > | 3. We assure the community that there will be no regressions in the > | progress made for freedom in the kernel distributed by Debian > | relative to the Etch release in Lenny (to the best of our knowledge > | as of 1 November 2008); > > | 4. We give priority to the timely release of Lenny over sorting every > | bit out; for this reason, we will treat removal of sourceless > | firmware as a best-effort process, and deliver firmware as part of > | Debian Lenny as long as we are legally allowed to do so, and the > | firmware is distributed upstream under a license that complies > | with the DFSG. > ` > I second this proposal. - -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkYhFMACgkQrelPZQd5nnRguwCgjnYS2TmuwyiLYTVsBEfoWVw6 /HAAn1jWyU/3A3sPe7IpwwRY1WpMy0ni =x1Dq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to: reduce the length of DPL election process
Simon Richter wrote: > > Which will probably mean that we will need options for this amendment in > combination with other amendments for voting. Does that need to be > spelled out, will that just magically happen or is that the most stupid > idea you have ever heard? All we would need is someone to combine the two, get enough seconds, and the combination of both ideas will appear on the ballot. So you would get four options, nicely matching the boolean table of the two ``independent'' options. -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2007: Draft ballot
Sven Luther wrote: > On Fri, Mar 16, 2007 at 04:06:34PM +, Ian Jackson wrote: > > > > Would it be possible to use just letters, rather than both letters and > > numbers ? That will make everything a little less confusing - in > > particular it makes it impossible to mistake rankings for choices and > > vice versa. > > Ian, since i retired my candidature, this problematic became mooth, as we will > no more need to go beyond the 9 choices. This time. What about for next time? Personally, I like Ian's suggestion. -- John H. Robinson, IV [EMAIL PROTECTED] because [EMAIL PROTECTED] is broken http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html http://jaqque.sbih.org/debian/new_req.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2007: Draft ballot
Josip Rodin wrote: > > While I'm at it, it would probably be fun to implement a 'higher is better' > ranking parser in a way to allow someone to vote for example > 13-53-32-5-1-_-3-2-2-_-1. Yet, that would probably confuse voters if they > were comparing that vote with a vote like 12-24-23-7-2-1-5-3-3-1-2 - > because those two different votes would be considered equal in the eyes > of the parser script. I like this idea, with the addition of the acknowledgement containing a normalised vote. 13-53-32-5-1-_-3-2-2-_-1 => 6-8-7-5-2-1-4-3-3-1-2 12-24-23-7-2-1-5-3-3-1-2 => 6-8-7-5-2-1-4-3-3-1-2 -- John H. Robinson, IV [EMAIL PROTECTED] because [EMAIL PROTECTED] is broken. http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2007: Draft ballot
Manoj Srivastava wrote: > > In the brackets next to your preferred choice, place a 1. Place a 2 in > the brackets next to your next choice. Continue till you reach your > last choice. If you have reached 9, and still have not finished, use > the letter A. Do not enter a number smaller than 1 or larger than 9, > or the letter A. You may skip numbers. You may rank options equally > (as long as all choices X you make fall in the range 0x1<= X <= 0xA). In the brackets next to your preferred choice, place an A. Place a B in the brackets next to your next choice. Continue till you reach your last choice. Do not enter a letter smaller than A or larger than J. You may skip letters. You may rank options equally (as long as all choices X you make fall in the range A <= X <= J). --snip-- - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- e0acebd2-71f1-4df8-ae4d-50355ad7aa81 [ ] Choice A: Wouter Verhelst [ ] Choice B: Aigars Mahinovs [ ] Choice C: Gustavo Franco [ ] Choice D: Sven Luther [ ] Choice E: Sam Hocevar [ ] Choice F: Steve McIntyre [ ] Choice G: Rapha?l Hertzog [ ] Choice H: Anthony Towns [ ] Choice I: Simon Richter [ ] Choice J: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- This change seems way too obvious to not be seen before. It removes all conceivable confusion. -- John H. Robinson, IV [EMAIL PROTECTED] because [EMAIL PROTECTED] is broken. http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote for the Debian Project Leader Election 2005
Hamish Moffatt wrote: > On Fri, Mar 25, 2005 at 09:34:35AM +0100, Emmanuel le Chevoir wrote: > > Emmanuel le Chevoir a écrit : > > >- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > >46348448-74a5-40ae-a651-49704435ae8c > > >- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > > > I'm so sorry for that one, that was a really stupid mistake. > > The good thing is that is received quite a bunch of interesting replies, > > along with a few (well deserved) criticisms. > > > > Again, sorry for beeing such an idiot :/ > > Does that mean you improved your vote also? ;-) I'm lost, what was wrong with his vote? -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal G (was: Proposal - Deferment of Changes from GR 2004-003)
To: to debian-devel removed Andreas Barth wrote: > * Andrew Suffield ([EMAIL PROTECTED]) [040505 14:10]: > > --- > > The Debian project resolves that it will not compromise on freedom, > > and will never knowingly issue another release (excluding point > > updates to stable releases) that contains anything in the 'main' or > > 'contrib' sections which is not free software according to the DFSG. > > --- > > I propose the following amendment, replacing the entire text of the > resolution: I second the amendment, with the typographical fixes provided in Message-ID: <[EMAIL PROTECTED]> applied. 1) were -> where 2) re-inforce -> reinforce -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html pgpNmztO3N8sw.pgp Description: PGP signature
Re: Social Contract GR's Affect on sarge
Manoj Srivastava wrote: > > No, perhaps you are right. But asking for a reasonable time to > implement the changes in the social contract does not requires > rescinding and restoring the social contract amendments; it could > just be a statement of purpose, a working guide to the change, > perhaps with a hard deadline. The foundation document stays > unchanged. i like this idea; it suits me well. Anthony Towns, in the role of Release Manager, if such a proposal were accepted by the body of Debian Developers, would this pave the way for a timely release of Sarge as was planed prior to the adoption of GR 2004-003? -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html
Re: Social Contract GR's Affect on sarge
Manoj Srivastava wrote: > > No, perhaps you are right. But asking for a reasonable time to > implement the changes in the social contract does not requires > rescinding and restoring the social contract amendments; it could > just be a statement of purpose, a working guide to the change, > perhaps with a hard deadline. The foundation document stays > unchanged. i like this idea; it suits me well. Anthony Towns, in the role of Release Manager, if such a proposal were accepted by the body of Debian Developers, would this pave the way for a timely release of Sarge as was planed prior to the adoption of GR 2004-003? -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: request for correction of minor error in ballot option
I do not know if this is required, but, I second the minor typographical change. It is good to be consistent. -john Branden Robinson wrote: > On Mon, Oct 13, 2003 at 10:51:59PM +0200, Osamu Aoki wrote: > > Was there any specific reason to use "3:1 majority" and "3:1 > > super-majority" in a same section for Proposal A and C? They look > > inconsistent to me but seem to cause no real impact. > > [as discussed with Manoj on IRC] > > I hereby request that the Project Secretary amend the "Proposal C" > ballot option, which I proposed, to use the term "majority" instead of > "super-majority". > > I further suggest that any permutation of the term "super-majority", > including "supermajority" and "super majority", also be altered to > "majority" in those portions of the ballot which are not options. > > Sorry to delay the onset of voting for this. pgpK0ZQJMOYll.pgp Description: PGP signature
Re: request for correction of minor error in ballot option
I do not know if this is required, but, I second the minor typographical change. It is good to be consistent. -john Branden Robinson wrote: > On Mon, Oct 13, 2003 at 10:51:59PM +0200, Osamu Aoki wrote: > > Was there any specific reason to use "3:1 majority" and "3:1 > > super-majority" in a same section for Proposal A and C? They look > > inconsistent to me but seem to cause no real impact. > > [as discussed with Manoj on IRC] > > I hereby request that the Project Secretary amend the "Proposal C" > ballot option, which I proposed, to use the term "majority" instead of > "super-majority". > > I further suggest that any permutation of the term "super-majority", > including "supermajority" and "super majority", also be altered to > "majority" in those portions of the ballot which are not options. > > Sorry to delay the onset of voting for this. pgp0.pgp Description: PGP signature
Re: [AMENDMENT BR3] GR: Disambiguation of Section 4.1.5 of the constitution
I hereby second the ammendment known as BR3 Branden Robinson wrote: > On Tue, Sep 23, 2003 at 12:29:40PM -0500, Manoj Srivastava wrote: > > == > > > > 4. The Developers by way of General Resolution or election > > > >4.1. Powers > > > > Together, the Developers may: > > 1. Appoint or recall the Project Leader. > > 2. Amend this constitution, provided they agree with a 3:1 majority. > > 3. Override any decision by the Project Leader or a Delegate. > > 4. Override any decision by the Technical Committee, provided they > > agree with a 2:1 majority. > > -5. Issue nontechnical policy documents and statements. > > - These include documents describing the goals of the project, its > > - relationship with other free software entities, and nontechnical > > - policies such as the free software licence terms that Debian > > - software must meet. > > - They may also include position statements about issues of the day. > > +5. Issue, supersede and withdraw nontechnical policy documents and > > + statements. > > + These include documents describing the goals of the project, its > > + relationship with other free software entities, and nontechnical > > + policies such as the free software licence terms that Debian > > + software must meet. > > + They may also include position statements about issues of the day. > > + 5.1 A Foundation Document is a document or statement regarded as > > + critical to the Project's mission and purposes. > > + 5.2 The Foundation Documents are the works entitled "Debian > > + Social Contract" and "Debian Free Software Guidelines". > > + 5.3 A Foundation Document requires a 3:1 super-majority for its > > + supercession. New Foundation Documents are issued and > > + existing ones withdrawn by amending the list of Foundation > > + Documents in this constitution. > > 6. Together with the Project Leader and SPI, make decisions about > > property held in trust for purposes related to Debian. (See > > s.9.1.) > > Thanks for preparing this latest version, Manoj. > > I propose the following amendment: > > - 5.2 The Foundation Documents are the works entitled "Debian > - Social Contract" and "Debian Free Software Guidelines". > + 5.2 The Foundation Document is the work entitled "Debian > + Social Contract". pgptSip0lYIlG.pgp Description: PGP signature
Re: [AMENDMENT BR3] GR: Disambiguation of Section 4.1.5 of the constitution
I hereby second the ammendment known as BR3 Branden Robinson wrote: > On Tue, Sep 23, 2003 at 12:29:40PM -0500, Manoj Srivastava wrote: > > == > > > > 4. The Developers by way of General Resolution or election > > > >4.1. Powers > > > > Together, the Developers may: > > 1. Appoint or recall the Project Leader. > > 2. Amend this constitution, provided they agree with a 3:1 majority. > > 3. Override any decision by the Project Leader or a Delegate. > > 4. Override any decision by the Technical Committee, provided they > > agree with a 2:1 majority. > > -5. Issue nontechnical policy documents and statements. > > - These include documents describing the goals of the project, its > > - relationship with other free software entities, and nontechnical > > - policies such as the free software licence terms that Debian > > - software must meet. > > - They may also include position statements about issues of the day. > > +5. Issue, supersede and withdraw nontechnical policy documents and > > + statements. > > + These include documents describing the goals of the project, its > > + relationship with other free software entities, and nontechnical > > + policies such as the free software licence terms that Debian > > + software must meet. > > + They may also include position statements about issues of the day. > > + 5.1 A Foundation Document is a document or statement regarded as > > + critical to the Project's mission and purposes. > > + 5.2 The Foundation Documents are the works entitled "Debian > > + Social Contract" and "Debian Free Software Guidelines". > > + 5.3 A Foundation Document requires a 3:1 super-majority for its > > + supercession. New Foundation Documents are issued and > > + existing ones withdrawn by amending the list of Foundation > > + Documents in this constitution. > > 6. Together with the Project Leader and SPI, make decisions about > > property held in trust for purposes related to Debian. (See > > s.9.1.) > > Thanks for preparing this latest version, Manoj. > > I propose the following amendment: > > - 5.2 The Foundation Documents are the works entitled "Debian > - Social Contract" and "Debian Free Software Guidelines". > + 5.2 The Foundation Document is the work entitled "Debian > + Social Contract". pgp0.pgp Description: PGP signature
Re: [AMENDMENT BR1] GR: Disambiguation of Section 4.1.5 of the constitution
i hereby second the proposal below. -john Branden Robinson wrote: > > == > 4. The Developers by way of General Resolution or election > >4.1. Powers > > Together, the Developers may: > 1. Appoint or recall the Project Leader. > 2. Amend this constitution, provided they agree with a 3:1 majority. > 3. Override any decision by the Project Leader or a Delegate. > 4. Override any decision by the Technical Committee, provided they > agree with a 2:1 majority. > -5. Issue nontechnical policy documents and statements. > - These include documents describing the goals of the project, its > - relationship with other free software entities, and nontechnical > - policies such as the free software licence terms that Debian > - software must meet. > - They may also include position statements about issues of the day. > +5. Issue, withdraw, and supsersede nontechnical policy documents > + and statements. These include documents describing the goals of > + the project, its relationship with other free software entities, > + and nontechnical policies such as the free software licence > + terms that Debian software must meet. > + They may also include position statements about issues of the day. > > == > Rationale: The clause being modified has been seen to be quite > ambiguous. Since the original wording appeared to be amenable to two > wildly different interpretations, this change adds clarifying the > language in the constitution about _changing_ non technical > documents. > == pgpDaIdJPyEs6.pgp Description: PGP signature
Re: [AMENDMENT BR1] GR: Disambiguation of Section 4.1.5 of the constitution
i hereby second the proposal below. -john Branden Robinson wrote: > > == > 4. The Developers by way of General Resolution or election > >4.1. Powers > > Together, the Developers may: > 1. Appoint or recall the Project Leader. > 2. Amend this constitution, provided they agree with a 3:1 majority. > 3. Override any decision by the Project Leader or a Delegate. > 4. Override any decision by the Technical Committee, provided they > agree with a 2:1 majority. > -5. Issue nontechnical policy documents and statements. > - These include documents describing the goals of the project, its > - relationship with other free software entities, and nontechnical > - policies such as the free software licence terms that Debian > - software must meet. > - They may also include position statements about issues of the day. > +5. Issue, withdraw, and supsersede nontechnical policy documents > + and statements. These include documents describing the goals of > + the project, its relationship with other free software entities, > + and nontechnical policies such as the free software licence > + terms that Debian software must meet. > + They may also include position statements about issues of the day. > > == > Rationale: The clause being modified has been seen to be quite > ambiguous. Since the original wording appeared to be amenable to two > wildly different interpretations, this change adds clarifying the > language in the constitution about _changing_ non technical > documents. > == pgp0.pgp Description: PGP signature
Re: Call for votes for the Condorcet/Clone proot SSD voting methodsGR
Sam Hartman wrote: > >>>>> "John" == John H Robinson, IV <[EMAIL PROTECTED]> writes: > > John> but is it a lack of interest in an issue at large, or a lack > John> of interest in a particular response to an issue that you > John> are worried about? > > Before I thought about voting, I would have said lack of interest in > the issue at large. Now, I see the arguments and believe that for > Debian it is lack of interest in a particular option. what is _your_ opinion, though? that's the crux of my question. my question may be moot, but i'm still interested. -john
Re: Call for votes for the Condorcet/Clone proot SSD voting methodsGR
Steve Langasek wrote: > > Enforced voting in order to ensure quorum is precisely an outcome I > *don't* want. Lack of quorum indicates lack of interest in the issue, > and such a lack of interest should be given appropriate consideration. but is it a lack of interest in an issue at large, or a lack of interest in a particular response to an issue that you are worried about? -john
Re: Call for votes for the Condorcet/Clone proot SSD voting methodsGR
Sam Hartman wrote: > >>>>> "John" == John H Robinson, IV <[EMAIL PROTECTED]> writes: > > John> but is it a lack of interest in an issue at large, or a lack > John> of interest in a particular response to an issue that you > John> are worried about? > > Before I thought about voting, I would have said lack of interest in > the issue at large. Now, I see the arguments and believe that for > Debian it is lack of interest in a particular option. what is _your_ opinion, though? that's the crux of my question. my question may be moot, but i'm still interested. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for the Condorcet/Clone proot SSD voting methodsGR
Steve Langasek wrote: > > Enforced voting in order to ensure quorum is precisely an outcome I > *don't* want. Lack of quorum indicates lack of interest in the issue, > and such a lack of interest should be given appropriate consideration. but is it a lack of interest in an issue at large, or a lack of interest in a particular response to an issue that you are worried about? -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for the Condorcet/Clone proof SSD voting methods GR
Raul Miller wrote: > On Tue, Jun 10, 2003 at 08:30:33PM -0700, John H. Robinson, IV wrote: > > case in point: as we add more voters that actively vote _against_ a > > proposal, we can cause an option to ``fail to meet quorum.'' > > This is completely false. Proposed change: A.6.3 Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration. a. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B. b. An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A). c. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1. Two options plus default option. 400 eligible voters. Quorum of 30. 75 voters. 75 ABD A wins easily. 75 more voters. 75 BDA as per A.6.c, the required majority ratio for A is 1. per A.6.b, V(A,D) > V(D,A) must be true lest A be dropped from consideration. V(A,D)=75; V(D,A)=76. A gets dropped from consideration. so we see that by simply doubling the number of voters, we can cause an otherwise winning option to be discarded. this has the same effect as A.6.2. -john
Re: Call for votes for the Condorcet/Clone proof SSD voting methods GR
Raul Miller wrote: > On Tue, Jun 10, 2003 at 08:30:33PM -0700, John H. Robinson, IV wrote: > > case in point: as we add more voters that actively vote _against_ a > > proposal, we can cause an option to ``fail to meet quorum.'' > > This is completely false. Proposed change: A.6.3 Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration. a. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B. b. An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A). c. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1. Two options plus default option. 400 eligible voters. Quorum of 30. 75 voters. 75 ABD A wins easily. 75 more voters. 75 BDA as per A.6.c, the required majority ratio for A is 1. per A.6.b, V(A,D) > V(D,A) must be true lest A be dropped from consideration. V(A,D)=75; V(D,A)=76. A gets dropped from consideration. so we see that by simply doubling the number of voters, we can cause an otherwise winning option to be discarded. this has the same effect as A.6.2. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for the Condorcet/Clone proof SSD voting methods GR
Raul Miller wrote: > > And, finally, the new voting system is (for the most part) compatible > with the intent of the existing voting system. It supports supermajority > (which makes changing the constitution hard), and it supports quorum > (which means very low participation can invalidate the vote). the use of the word Quorum with respect to either the current or proposed Constituction is misleading at best, and outrightly false at face value. case in point: as we add more voters that actively vote _against_ a proposal, we can cause an option to ``fail to meet quorum.'' that goes against every applicable definition of quorum that i can come across. a more accurate way to say it is that the Constitution and it's proposed replacement support an approval margin. -john
Re: Call for votes for the Condorcet/Clone proof SSD voting methods GR
Raul Miller wrote: > > And, finally, the new voting system is (for the most part) compatible > with the intent of the existing voting system. It supports supermajority > (which makes changing the constitution hard), and it supports quorum > (which means very low participation can invalidate the vote). the use of the word Quorum with respect to either the current or proposed Constituction is misleading at best, and outrightly false at face value. case in point: as we add more voters that actively vote _against_ a proposal, we can cause an option to ``fail to meet quorum.'' that goes against every applicable definition of quorum that i can come across. a more accurate way to say it is that the Constitution and it's proposed replacement support an approval margin. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Constitutional amendment: Condorcet/Clone Proof SSD votetallying
Manoj Srivastava wrote: > On Wed, 28 May 2003 03:59:32 +0200, Matthias Urlichs <[EMAIL PROTECTED]> > said: > > > This whole discussion tells me that the original proposal (with > > Manoj's s/quorum/.../ change, for consistency) should be up to that > > task. > > Cool. All we need is the other sponsors to agree (though I > agree with the rationale behind the change, I do not feel strongly > enough to have to go through and campaign for a new set of sponsors; > if 5 of the original sponsors agree to the changes, I'll put them > in). speaking only for myself, of course, i believe that such a change would lend clarity to the proposal. i cannot say that i _would_ second such a proposal, because i still feel that the mucking about with Condorcet/ Cloneproof SSD to do double duty is less than ideal. unfortunately, i have no good ideas as to how to ``solve'' this ``problem.'' no one else either cares, or has any ideas either. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD votetallying
Manoj Srivastava wrote: > On Wed, 28 May 2003 03:59:32 +0200, Matthias Urlichs <[EMAIL PROTECTED]> said: > > > This whole discussion tells me that the original proposal (with > > Manoj's s/quorum/.../ change, for consistency) should be up to that > > task. > > Cool. All we need is the other sponsors to agree (though I > agree with the rationale behind the change, I do not feel strongly > enough to have to go through and campaign for a new set of sponsors; > if 5 of the original sponsors agree to the changes, I'll put them > in). speaking only for myself, of course, i believe that such a change would lend clarity to the proposal. i cannot say that i _would_ second such a proposal, because i still feel that the mucking about with Condorcet/ Cloneproof SSD to do double duty is less than ideal. unfortunately, i have no good ideas as to how to ``solve'' this ``problem.'' no one else either cares, or has any ideas either. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Better quorum change proposal, with justifiction
Sam Hartman wrote: > > I think I'm willing to agree with you here that quorum is not a great > name for what we have in Manoj's proposal. i also got hung up on the use of the word ``quorum''. at first, i saw the word quorum, and i saw that that was not at all what was going on. i assumed that the people initially drafting the system meant quorum, not some ``buy-in'' thing. so i crafted an amendment that restored the meaning of quorum to quorum. it also brought us closer to a Condorcet/Cloneproof SSD method of tallying. after pondering, i came up with another idea tht gives us a pure Condorcet/Cloneproof SSD, provides with applicable buy-in, and supports supermajorities. please see http://lists.debian.org/debian-vote/2003/debian-vote-200305/msg00203.html Message-id: <[EMAIL PROTECTED]> -john
Re: Better quorum change proposal, with justifiction
Sam Hartman wrote: > > I think I'm willing to agree with you here that quorum is not a great > name for what we have in Manoj's proposal. i also got hung up on the use of the word ``quorum''. at first, i saw the word quorum, and i saw that that was not at all what was going on. i assumed that the people initially drafting the system meant quorum, not some ``buy-in'' thing. so i crafted an amendment that restored the meaning of quorum to quorum. it also brought us closer to a Condorcet/Cloneproof SSD method of tallying. after pondering, i came up with another idea tht gives us a pure Condorcet/Cloneproof SSD, provides with applicable buy-in, and supports supermajorities. please see http://lists.debian.org/debian-vote/2003/debian-vote-200305/msg00203.html Message-id: <[EMAIL PROTECTED]> -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Splitting Aye/Nay from vote tallying (Was: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying)
Anthony DeRobertis wrote: > On Tuesday, May 27, 2003, at 01:44 AM, John H. Robinson, IV wrote: > > > > >for the ``quorum'' requirement: this is easy. > >require X number of seconds with each anti-second counting against the > >totally number of seconds. > > So, in other words, drop Condorcet and switch to a simple majority vote > instead. You've got votes for (seconds) and votes against > (anti-seconds). How is this not a vote? this is what we are doing right now with the above-default = approval; equal-to-or-below-default = rejection. instead of trying to hide it in some strange bastardisation of Condorcet/Cloneproof SSD, bring it out into the open. plus, we get to un-bastardise Condorcet/Cloneproof SSD while we are at it. > Requiring Q seconds would be much more reasonable, methinks. i agree with you, but we loose the ability to reject. am i against that? no. not at all. however, since we as a project feel that being able to say ``No'' is desirable, it is important to be able to maintain that. so - we set the bar for getting onto the ballot higher. it does make a two-stage voting process, sort of. this is also a bit more complicated that a simple yes/no and see which is prefered (either via approval or condorcet or plurailty or whatever). i see no problem with that, as we are not choosing which option to implement, but choosing which options appear. > >this takes out all possibilities of strategic voting, and applies the > >strategy to the proposal stage. at least the vote tallying method > >remains untainted :/ > > Yeah, but it got ten times worse overall. yes, there is that. so - does anyone have any better ideas? -john
Re: Splitting Aye/Nay from vote tallying (Was: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying)
Anthony DeRobertis wrote: > On Tuesday, May 27, 2003, at 01:44 AM, John H. Robinson, IV wrote: > > > > >for the ``quorum'' requirement: this is easy. > >require X number of seconds with each anti-second counting against the > >totally number of seconds. > > So, in other words, drop Condorcet and switch to a simple majority vote > instead. You've got votes for (seconds) and votes against > (anti-seconds). How is this not a vote? this is what we are doing right now with the above-default = approval; equal-to-or-below-default = rejection. instead of trying to hide it in some strange bastardisation of Condorcet/Cloneproof SSD, bring it out into the open. plus, we get to un-bastardise Condorcet/Cloneproof SSD while we are at it. > Requiring Q seconds would be much more reasonable, methinks. i agree with you, but we loose the ability to reject. am i against that? no. not at all. however, since we as a project feel that being able to say ``No'' is desirable, it is important to be able to maintain that. so - we set the bar for getting onto the ballot higher. it does make a two-stage voting process, sort of. this is also a bit more complicated that a simple yes/no and see which is prefered (either via approval or condorcet or plurailty or whatever). i see no problem with that, as we are not choosing which option to implement, but choosing which options appear. > >this takes out all possibilities of strategic voting, and applies the > >strategy to the proposal stage. at least the vote tallying method > >remains untainted :/ > > Yeah, but it got ten times worse overall. yes, there is that. so - does anyone have any better ideas? -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Splitting Aye/Nay from vote tallying (Was: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying)
Anthony Towns wrote: > On Mon, May 26, 2003 at 08:45:31PM -0400, Andrew Pimlott wrote: > > I _think_ the same basic strategy applies: Rank the non-default > > options sincerely, then insert the default option after your "lesser > > of evils" option. > > That doesn't work. Suppose there are three options, and everyone does this. i can see where the basic flaw is now, and why, no matter what we do, we cannot fix this problem via vote-tallying. we are making our votes do double duty. we are simultaneously trying to rank in order our preferences, and say ``Aye'' or ``Nay'' to any particular option. this is affecting the ``quorum'' and super majority portions. i believe it was anthony towns that pointed out that failure to get the required seconds prevents an option from ever appearing on the ballot. i hereby state that that is a straw-man argument: the requirements to appear on the ballot are orthogonal to the vote tallying mechanism. example: in order to be president of the USA, you have to be 1) a natural borne citizen, 2) 35 years of age (i do not know if that is at time of inauguration or at time of election). to appear on the ballot, you have to have a certain number of people's signatures backing you. this number is really high, and varies state to state. to speed things up, political parties have already gotten the required signatures, and apply those signatures to a single candidate (usually, last year the arizona libertarian candidate was different from the other 49 states. fun, huh? bet you were unaware of that little election anomaly ;) i feel certain that no one would try to argue that being 34 years of age is a fault of the election tallying method (plurality or condorcet), or that anyone is going to assert that every natural-borne citizen that is 35yrs or greater MUST appear on the ballot. that would be ludicrous. so: the need to get seconds (normally, 5) is in no way, shape, or form a reflection of the vote tallying method. the problem: our vote tallying method is doing double duty. solution: split it out. how: i do not know, yet, but one possibility follows. i am making this up as i go along, so comments welcome. for the ``quorum'' requirement: this is easy. require X number of seconds with each anti-second counting against the totally number of seconds. perhaps that could be applied to super majority options also: require that the number of seconds not only be really high, but also has to beat the number of nay's by that ratio. example: option a: no super majority requirement, requires 10 seconds option b: 2:1 super majority requirement, requires 20 seconds option c: 3:2 super majority requirement, requires 15 seconds option d: 2:1 super majority requirement, requires 20 seconds option a gets 15 seconds, 6 rejects. aye-nay<10; stricken from ballot option b gets 40 seconds, 20 rejects. aye:nay ratio >= 2:1, aye-nay>=20; appears on ballot option c: gets 20 seconds, 15 rejects. aye:nay ratio < 3:2. stricken from ballot option d: gets 15 seconds, 5 rejects. aye:nay ratio >= 2:1, aye<20; stricken from ballot so the ballot would look like this: Option B Option C Default Option the vote can then be run, and counted in a pure condorcet/cloneproof SSD method. under such a scenario, i am uncertain if a default null-option would be required, but it certainly won't hurt anything. it is true that a single voter, if the only voter, could decide the entire course. however, with the high number of seconds required (i'm assuming that the number of seconds required would be increased) sufficient buy-in has already been established. i also used the base buy-in value, and scaled it per the super majority requirements. in our current system, at no time may a 2:1 or 3:2 super majority be required. these numbers are simply illustrative. this takes the burden of super-majority and buy-in OFF OF the vote, and puts it on the appear-on-ballot process. the interesting case would be the buy-in requirements in a small voting populous, such as for the tech committee. a buy-in of two would still sound reasonable: one person submits, another seconds, a second seconds. if the CTTE is 4, then if the fourth person rejects, *poof* goes the option. if the fourth person abstains or seconds, then that option would appear. for 8 members, it could go on with additional seconds and rejections. this takes out all possibilities of strategic voting, and applies the strategy to the proposal stage. at least the vote tallying method remains untainted :/ i do not think our current method of deterring R would quite work: 3/2*N**.5 (where N is the Number of Developers). that would require a supreme effort of people to second a proposal. the proposal we are discussing has only gotten around 8 seconds, that is not even Q. 5 is probably too low. .5*N**.5 could possibly be too high. where does the middle ground lie? or should the above be scrapped, perhaps for another, better, method that
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Raul Miller wrote: > > What Anthony is trying to point out, and what you're pretending to > ignore, is that what "D wins" means is "no one wins, and the vote > is thrown out". no, this is not the same. one is a legitimate, binding vote with a real bona fide winner. the other is a nullification. > Since you perhaps haven't read Manoj's proposal well enough to > see that this is the case: I challenge you to show any > >>difference in outcome<< between these two circumstances. easily: DPL elections. a thrown out and rescheduled DPL election is a lot different from None of the Above winning. Debian Constitution (proposed) Section 5.2.7. -john, who is supposed to be _enjoying_ this weekend.
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Raul Miller wrote: > On Fri, May 23, 2003 at 04:40:49PM -0700, John H. Robinson, IV wrote: > > correct me if i am wrong, but, isn't quorum suppoed to _prevent_ > > minority rule? now you are saying that minority rule is good, and > > desired? > > What do you mean? i mean to point out a hypocrisy. on the one hand, say that minority rule is bad, but implement in such a way as to allow minority rule. > There are forms of minority rule which quorum prevents, and there are > forms it allows. and the proposition uses a form that allows it. > Certainly, quorum isn't about having a small group of people dictating > to a larger group of people without the larger group having any say. true. quorum is intended to ensure that enough people participate to get good sampling. ie: no secret, behind the doors meetings to decide what really happens. > > if that is the case, i recommend scrapping the entire idea of quorum, as > > it breaks condorcet in strange and interesting ways. > > Condorcet itself allows certain forms of minority role and prevents > others. example? other than the case of extreme voter apathy, of course. > Sometimes I get the idea that you're saying things, not because you're > trying to achieve some worthwhile end, but because you like the way > they sound. Is that the case here? no, i am afraid not. > > in this case, the options were not fairly close at all. 10 people > > prefered A over B. only five people prefered B over A. that is a 2:1 > > margin. that is a 2/3'ds majority in favour of A, and it still lost. > > So what? > > In the example I presented earlier (ballot: A, B, default D, one > vote: ABD), option A was infinitely preferred over all other options. > You're arguing that we should accept such a vote, even though (other > than one person) no one wanted to (or was able to) participate in it. in a classic Condorcet, yes. but as i explained in a previous email (http://lists.debian.org/debian-vote/2003/debian-vote-200305/msg00133.html or Message-id: <[EMAIL PROTECTED]>) i outlined five major choices we could make, along with their relative merits. Arrow's Theorem shows that no voting system is perfect. so we _must_ accept some flaws. the nice thing is, we get to choose our own poison. we use a basis of Condorcet, because that is the one that is the best amongst a collection of flawed systems. two of the flaws, as far as Debian is concerned, is that Condorcet does not support a tyranny of the status-quo, nor does it prevent minority rule. we have attempted to solve the first flaw by the use of supermajorities. in so doing, we have created a new, always-present option called the Default Option which is basically a null-option. if a supermajority requiring option fails to beat the default option in a one-to-one race with respect to its supermajority requirement, that option is discarded. we have attempted to solve the second flaw by the use of quorum. in so doing, we have created a new, always-present option called the Default Option which is basically a null-option. if an option fails to beat the default option in a one-to-one race by the quorum requirement, that option is discarded. immediately, we see that the Default Option plays double duty. in the one case of supermajority, and the other case in quorum. i agree that Condorcet does make the best basis for a voting system. i do not agree, however, that our application of quorum, to prevent minority rule, is the correct or even the simplest approach. i believe that the per-option quorum opens us up to strategic-voting (rank all other options below default, so they don't make quorum, but otherwise rank them in the order that you prefer to allow the proper Condorcet ranking in the case that the other options do make quorum). my proposed solution opens up another problem, that of a single vote causes an otherwise nullified vote to declare the opposition a winner. the latter case will only occur in cases of extreme voter apathy, or when the quorum requirement is very close to the number of voters (such as in the case of small voting body). example: the technical committee has a membership from four to eight members, and quorum is always two. thus quorum can be from 25% to 50%. Manoj pointed out that his proposal would cause more votes to end in a default state than my amendment would. he is correct. under my amendment, if a vote fails to make quorum, it is as if the vote never occurred. i see this as drastically different from the case where a binding default option wins. in practice, it might not be so different (exception: DPL elections. a binding None of the Above would be a lot different from a nullification). > And yet, you're arguing that we should accept this kind of election as > valid, and apparently the basis you're using for your argument
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Anthony Towns wrote: > On Thu, May 22, 2003 at 12:43:44PM -0700, John H. Robinson, IV wrote: > > Condorcet: A wins > > Proposed: D wins > > Amended: no one wins, the vote is thrown out. > > > You mean "D wins". http://lists.debian.org/debian-vote/2003/debian-vote-200305/msg00054.html Message-id: <[EMAIL PROTECTED]> + 2. If the ballot has a quorum requirement R, and less then R votes are +cast, the entire vote is thrown out. The amendment may be withdrawn, +or a discussion period may be resumed at the sponsor's discretion. no, really, i mean ``no one wins, the vote is thrown out.'' -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Sam Hartman wrote: > > Aj has made what seems to me to be a compelling argument that > > 1) local quorum is not flawed in this case > > 2) The Debian community wants B to win votes of this form. > > What we are saying is that we are giving minorities the power in > certain limited cases to overrule the majority and force us to select > an second acceptable option in preference to an acceptable option more > preferred by the majority. I.E. when options are fairly close, a > minority finding a particular option unacceptable can change the > outcome of the election. correct me if i am wrong, but, isn't quorum suppoed to _prevent_ minority rule? now you are saying that minority rule is good, and desired? if that is the case, i recommend scrapping the entire idea of quorum, as it breaks condorcet in strange and interesting ways. in this case, the options were not fairly close at all. 10 people prefered A over B. only five people prefered B over A. that is a 2:1 margin. that is a 2/3'ds majority in favour of A, and it still lost. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Raul Miller wrote: > > > I should not be put in this position. > > On Fri, May 23, 2003 at 10:49:08AM -0700, John H. Robinson, IV wrote: > > worst case scenario: everyone feels the way you do. no one votes. > > two week discussion period resumes, or the amendment is withdrawn. > > False. i was limiting strictly to points where quorum was failed. note i did not include best case scenarios, (which would be most likely scenarios for elections such as for the DPL). those scenarios would be ones which the ideal democratic winner is the election winner. > With your proposal, the worst case scenario is: I make my choice (either > to vote or not to vote), the votes are tallied, I find out that my choice > caused my preferred option to be defeated by an option I ranked as less > desirable than default. this gets right back to the definition of quorum. if the proposal did not use the word quorum, and instead used the term buy-in, perhaps i would have had less qualms with it. i still feel that a per-option quorum or per-option buy-in is fatally flawed. you have stated that a global quorum is flawed. we have two examples of where gobal quorum is flawed: Example 1: 9 options + default, R=10. 10 voters. 9 voters vote for different options, default second, all other options unranked. the thenth voter votes for any particular option, default second, all other options unranked. result: Condorcet would select the option with two votes in favour. Proposed would select the default option (default != IDW). Amended would select the option with the two votes in favour. Example 2a: 2 options + default, R=10. 9 voters. all voters vote ADB. result: Condorcet would select option A Proposed would select the default option (default != IDW) Amended would nullify the entire vote (nullification != IDW) 2b: 2 options + default, R=10, 10 voters, 9 votes ADB; 1 vote BDA result: Condorcet would select option A Proposed would select the default option (default != IDW) Amended woulc select options A commentary: assume a global quorum. in the first example, only two people supported the winning option. in the second example, the additional vote against the option caused it to win. we have two examples of where per-option quorum is flawed: Example 1: 2 options + default, R=15. 15 voters. 10 vote ABD, 5 vote BDA result: Condorcet would select option A Proposed would select option B (B != IDW) Amended would select option A Example 2a: http://www.mathematik.uni-kl.de/~wwwstoch/voss/comp/quorum.html 4 options + default. R=45. 53 votes. ABCDE 4x 312-4 9x 3124- 13x 241-3 1x 412-3 2x 12543 9x 131-2 1x 232-1 9x 323-1 2x 312-3 3x 123-1 result: Condorcet would select Option A Proposed would select Option B (B != IDW) Amended would select Option A Example 2b: http://www.mathematik.uni-kl.de/~wwwstoch/voss/comp/quorum.html 4 options + default, R=45. 54 votes. ABCDE 4x 312-4 9x 3124- 13x 241-3 1x 412-3 2x 12543 9x 131-2 1x 232-1 9x 323-1 2x 312-3 3x 123-1 1x -1243 result: Condorcet would select Option A Proposed would select Option A Amended would select Option A commentary: in example 1, we have a case where the non-default ideal democratic winner is discarded before the vote is even tallied. in example two, a vote that simultaneously votes for B as being prefereable to all other options, and E as being preferable to default causes E to make its per-option quorum, which allows A, the ideal democratic winner, to win. in the second example, i changed the new vote from the one on the webpage to indicate that not only is it a vote for B, but it is also a vote AGAINST A. A is ranked lower than default, and that vote causes A to win. since this is a new vote, not a changed one, this does not break the Monotonicity Criterion. > Now, clearly, we're talking about two different scenarios here (one > where you choose to vote, one where you choose not to vote). However, > until the votes are tallied, you can't know which scenario you're in. we have a few options that we can choose: 1) use a pure condorcet/cloneproof SSD, ignoring all quota and supermajority requirements. this allows for a minority rule (assuming rampant voter apathy) and prevents the tyranny of the status-quo 2) use a per-option quorum, which allows for strategic voting (vote the less-preffered option under default to prevent aiding the other options from making their per-option quorums) 3) use a global quorum, which rewards voter apathy (as per some arguments). 4+5) use either quorum method, along with a super majority. each method is flawed.
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Manoj Srivastava wrote: > > Right. Leads to a lot of soul searching -- I no longer know > whether I am helping or hurting my candidate by expressing my true > preference. > > I should not be put in this position. worst case scenario: everyone feels the way you do. no one votes. two week discussion period resumes, or the amendment is withdrawn. second worst case scenario: a lot of people feel the way you do, few people vote. less than quorum. two week discussion period resumes, as per sponsors wishes (he hopes to get more people interested). people still have not changed their minds. not enough people vote. two week discussion period resumes. repeat this 26 times, and a whole year has gone by with no action whatsoever. eventually, people will get tired of seeing this measure and will either vote, come to a workable compromise (where competing options are removed), or the sponsor will tire of the attempt. that is the price you will have to pay for apathy, regardless. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Anthony Towns wrote: > > Yes, that's why we're in favour of per-option quorums, which don't > introduce flawed incentives for little reason other than matching > tradition. instead, the per-option quorum will throw out the IDW in favour of a less-favoured option due to quorum requirements. R=15 10 ABD 5 BDA -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Buddha Buck wrote: > > > >another example: DPL election, two candidates, R=45 > > > >450x DAB > >45x ADB > > > >Condorcet: D wins > >Proposed: A wins > >Amended: D wins > > You are going to have to walk me though this one. Here's what I see > happening under Manoj's proposal: > > 45 voters prefer A to D, which is equal to R, so A "meets quorum". > No voters prefer B to D, which is less than R, so B does not meet > quorum, and is eliminated. > > More voters prefer D over A than A over D, so A is eliminated as not > acceptable. > > The only remaining candidate to feed into the SSD procedure is D, so D wins. > > How do you get A winning? of course, Buddha is correct. i ran the scripts wrong. user error. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Raul Miller wrote: > On Thu, May 22, 2003 at 10:21:45AM -0700, John H. Robinson, IV wrote: > > you, sir, are the one changing the meaning of of the word quorum. my > > amendment restores the meaning of quorum with respect to the Debian > > voting mechanism. > > False. which part, that ``quorum'' is being redefined, or that my amendment fails to restore that definition? > Nevertheless, at no point during a debian vote is anybody "present" at > any bench or any other such location. It's true, to my knowledge, that > everybody is on this same planet, but that's not something that changes. we don't use the bench definition, we use the second definition. i thought about cutting out the misleading parts, and leaving in only the relevant parts, but i did not want to be accused of withholding information from those that did not have access to the OED. i will repeat the relevant definition here, from the OED: quorum 2. A fixed number of members of any body, society, etc., whose presence is necessary for the proper or valid transaction of business. to give another example where physical location is not taken as part of quorum, our parent organisation, Software in the Public Interest holds its board meetings on an IRC channel. having a client connected to the IRC network, and participating in the channel where the meeting is taking place is sufficient to indicate presence. the proposed version says that in order to qualify as present, you have to agree with a particular option. my amendment equates simply voting with presence for the purposes of meeting quorum. another example: DPL election, two candidates, R=45 450x DAB 45x ADB Condorcet: D wins Proposed: A wins Amended: D wins here we have a case where ten times the number of people think that both candidates are so rotten, they would rather see no one in office. a minority of a voters would like to see their candidate win. under the proposed mechanism, the minority of the voters win, because the loud majority voice was squelched by the per-option implementation of quota. > Instead, we use the concept of people taking an active part in > approving the option(s) they're voting on. please see the above vote of where this could lead to a Minority Rule. in no definition that i provided, or that i found, either in the OED, or on dictionary.com, did it say that quorum is the minimum number of people that support an option. if you have a reference, please provide it. i searched, and came up with nothing. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Matthias Urlichs wrote: > > Simple reasoning: "ranking all the options the same" has the same effect as > "not voting at all" WRT the outcome of the vote. Absent reasons to the > contrary, it therefore should also be considered equivalent WRT the > Monotonicity Criterion, or violation thereof, or lack thereof. for purposes of argument, i will accept that as true. let us review the Monotonicity Criterion (MC) again: = http://electionmethods.org/evaluation.html#MC = = With the relative order or rating of the other candidates unchanged, = voting a candidate higher should never cause the candidate to lose, = nor should voting a candidate lower ever cause the candidate to win. for the purposes of this discussion, i take the Statement of Criterion's use of candidate to be equivalent in concept to the Debian voting mechinism's concept of option. Scenario: R=10; two options + default option Original vote: 9 ABD Condorcet: A wins Proposed: D wins Amended: no one wins, the vote is thrown out. one more person votes: 9 ABD 1 BDA Classic: A wins Proposed: B wins Amended: A wins you are saying that one voter effectively changed his vote to where B was raised with respect to the other options. to fail the MC, before B would have had to win, and now B would have to lose. before, B did not win. so that fact that B loses now has _NO EFFECT_ with respect to MC. no case, either Condorcet, Proposed, or Amended fails the MC. please provide a real example where the Amended proposition fails MC before making this accusation again. if you are going to claim that nullifying a vote is identicle to all options losing, then i am afraid we have an un-breachable conflict. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Manoj Srivastava wrote: > > If you [Buddha Buck] meant to change the meaning of quorum, I must > confess I disagree. you, sir, are the one changing the meaning of of the word quorum. my amendment restores the meaning of quorum with respect to the Debian voting mechanism. The Oxford English Dictionary: quorum 1. Orig., certain justices of the peace, usually of eminent learning or ability, whose presence was necessary to constitute a bench; latterly the term was loosely applied to all justices. b. transf. Applied to similarly distinguished members of other bodies; hence, a select company. 2. A fixed number of members of any body, society, etc., whose presence is necessary for the proper or valid transaction of business. 3. Necessary materials. Obs. rare. The American Heritage Dictionary of the English Language, Fourth Edition: quorum n. 1. The minimal number of officers and members of a committee or organization, usually a majority, who must be present for valid transaction of business. 2. A select group. please note that at no point does quorum say that the majority have to like the business being transacted, just that they must be present. my amendment restores the meaning of quorum to quorum. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Steve Langasek wrote: > > Why do you believe it's meaningful to distinguish between "the default > option wins" and "the entire vote is thrown out"? When is status quo > != the default option? 5.2. Appointment 1. The Project Leader is elected by the Developers. . . . 7. The decision will be made using Concorde Vote Counting. The quorum is the same as for a General Resolution (s.4.2) and the default option is None Of The Above. the proposal re-words 5.2.7 to: 7. The decision will be made using the method specified in section A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (s.4.2) and the default option is "None Of The Above". in this case, for the default option to be equal to status quo, the default option would have to be ``The current officeholder.'' however, the default option is ``None Of The Above.'' if the default option won, then there would be no one in the office of Project Leader. that is significantly different from staus quo. under the amendment, if a Project Leader election failed to meet quorum, then elections would be pushed back another two weeks, plus or minus one week at the pleasure of the current Project Leader. of course, this does not affect the term of the Project Leader as specified by 5.2.8 (The Project Leader serves for one year from their election). only in the case (as per the proposed A.3.3, which is not affected by the amendment) that the default option is not specified, does it revert to Further Discssion. within the scope of the constitution, the only time that the default option is specified is for Project Leader elections. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Anthony Towns wrote: > > For reference, "back to the Condorcet standard" is not what we > want here. The default option allows allows us to combine condorcet > preferential voting, with an approval-vote style calculation of majorities > or acceptability. the proposal uses Condorcet as a standard, and tries to add Quota and Supermajority options in a way that does not break Condorcet. the way that Quota is handled does break Condorcet, by allowing a winner that is not the Ideal Democratic Winner. my amendment fixes that issue. my amendment does not address the issue of Supermajority. > > while ensuring that a few developers (less that R) cannot make > > any ``stealth decisions''. > > Likewise, the quorum requirement is made on a per-option basis > specifically to ensure that there's no bias in the system -- that is, > there's no incentive not to vote for an option you like, because that > would in any way make it more likely for an option you dislike to win. it inherently biases the default option. my amendment removes that bias. may i assume that you beleive all voters support the default option in all cases? > For reference, my only quibbles with the draft are in the wording of: Manoj addressed these sufficiently in Message-ID: <[EMAIL PROTECTED]> -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Raul Miller wrote: > > > Expressed in terms of scenario: A vs B, quorum 20 > > > > > > Case 1: > > > > > > 15 ABD > > > D wins > > On Tue, May 20, 2003 at 05:30:29PM -0700, John H. Robinson, IV wrote: > > 15 > That's what I said, though perhaps too tersely. D is the > default option. "D wins" means the election defaults. > > > > Case 2: > > > 15 ABD > > > 8 BDA > > > A wins > > > > > > Here, the vote(s) for B caused A to win. > > > > these are new votes, not re-ordered existing votes. this does not fail > > the Monotonicity Criterion. > > You do not understand the Monotonicity Criterion. = http://electionmethods.org/evaluation.html#MC = = Monotonicity Criterion (MC) = Statement of Criterion = With the relative order or rating of the other candidates = unchanged, voting a candidate higher should never cause the = candidate to lose, nor should voting a candidate lower ever cause = the candidate to win. please show how either 1) changing the order of an existing vote, under my amendment, causes the winner to change in accordance with the MC as described above. (ie: moving an option lower causes the option to WIN, or moving an option lower causes the option to LOSE) -or- 2) how casting a new vote is equivalent, with respect to the MC, to changing the order of an already existing vote, and how discarding the entire process is equivalent to causing an option to win or lose. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
To: to debian-devel dropped. let's keep the discussion on -vote. Mark Brown wrote: > On Wed, May 21, 2003 at 10:12:52AM +0200, Sven Luther wrote: > > > But you cannot know what the situation is, unless you have insider > > knowledge, the votes are secrets, and the results published only after > > the election is closed. > > This doesn't change the fact that there is a chance that by voting > you'll have an effect other than that which you'd intended. It's a > fairly small chance but it's there. this leaves three choices: 1) one voter decides the entire election (no quorum) 2) the winner potentially loses (per-item quorum) 3) a vote against a proposition causes that proposition to win (per-vote quorum) let's see if we can make the per-item quorum behave like the per-vote quorum where a vote _against_ an item causes that item to win: quorum of R=12. two options, plus the default option. a single voter. 1 BA A.6.2. If the ballot has a quorum requirement R any options other than the default option which do not receive at least R votes ranking that option above the default option are dropped from consideration. B and A each have only one vote over D, thus B and A are both dropped from consideration. that leaves one vote for D. there is no majority ratio, so A.6.3 does not apply. A.6.4 has only D, so D would win. thus, in the case of a single voter AGAINST the default option, the default option wins. this is not very likely, but this is also the case. under the amendment, A.6.2 is changed thusly: A.6.2. If the ballot has a quorum requirement R, and less then R votes are cast, the entire vote is thrown out. The amendment may be withdrawn, or a discussion period may be resumed at the sponsor's discretion. 1<12, so the vote is thrown out. the sponsor may then either withdraw the proposition, or resume a discussion period. we see that the proposal suffers the same flaw that amendment is accused of having. this leaves us with three choices: 1) one voter decides the entire election (no quorum) 2) the winner potentially loses, and a vote against a proposition causes that proposition to win (per-item quorum) 3) a vote against a proposition causes that proposition to win (per-vote quorum) -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Raul Miller wrote: > On Tue, May 20, 2003 at 02:39:08PM -0700, John H. Robinson, IV wrote: > > > > this is a strawman, because if > achieve the R+1>default per-item quota. > > Expressed in terms of scenario: A vs B, quorum 20 > > Case 1: > > 15 ABD > D wins 15 Case 2: > 15 ABD > 8 BDA > A wins > > Here, the vote(s) for B caused A to win. these are new votes, not re-ordered existing votes. this does not fail the Monotonicity Criterion. under a Classic Condorcet/Cloneproof SSD, both case 1 and case 2 would have A as the winner. this is no different than, say, a board meeting vote. if you show up, then any votes taken are binding regardless if you abstain or not. the only difference here is that if you vote at all, you are counted has having participated. this is a tradeoff between ``a vote against causes the opponent to win'' and ``stealth decisions by a few developers.'' one way respects the will of the voters, the other way does not. my amendment respects the will of the voters. the proposal does not. > > > To make your proposal work right, we'd need a separate quorum > > > determination phase which is independent of the voting phase. > > > > i fail to see that argument. > > See above. what would the separate quorum determination determine? when would this determination take place? -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Manoj Srivastava wrote: > > > Scenario A: > Suppose the tech ctte has 10 members, and is trying to vote on > the rainbow vote. The quorum is 4. (If you recall, the rainbow vote > had 10 options). > > All 10 members vote -- and they all like like different > colors, except that two people like red. Most are indifferent about > the colors they did not chose, but they do not feel they should win > -- and express their preferences by either only voting for the color > of their choice. > > In my version, since no option got the needed 4 votes, there > is no winner. Let us compare three ways of counting this exact vote: 1) ``Classic'' Condorcet/Cloneproff SSD, with no quota requirements. 2) The newly proposed scenario. 3) The amended proposed. under Classic method, Red does win. under the proposed method, there is no vote. under the amended proposition, Red wins. the proposal brings the Quorum voting method back to the Condorcet standard, while ensuring that a few developers (less that R) cannot make any ``stealth decisions''. > In this amendment, red wins -- even though only 2 of the 10 > people voted for it (less than the quorum of 4). Red won, even though > 8 out of 10 people did not want to see it as winner. those 8 people did not establish a priority between the remainder, and as such, were indiferent to the results. if any one of them had marked red below the rest,, such as 122322, then all the colours would have tied. > Consider the same scenario with 100 voters, quorum 9; and 10 > voting: even though only 2 people prefer red, it shall win. this is what the voters had prefered. i fail to see the problem. > Logically, I think, the sheer indifference of the voting > population would be better reflected by not selecting a winner. if you desire more buy-in, change the quota as required. 3*1/2sqrt(100) is 15. > Scenario B: > > Consider the case where the quorum is 45, and there have been > 44 votes -- 23 for, 21 against. (Only one option on the ballot). I am > opposed to the option. > > At this point; under my version; I can express my opinions > with no fear of harming my candidate. Under your amendment; if I do > not vote; the vote is nullified. However, if I vote against the > option -- the option shall win!! > > If I do not vote, but some one else opposed to the option > votes before the vote ends --- the option wins (even though the vote > was against it)!!. If I had voted along with this other person, the > vote would have been a draw. > > So, if two people opposed to the option do not vote; the > option loses. If either votes against the option, the option wins -- > if they both vote against the option, the vote is a draw, and the > casting vote, if any, gets to decide. let us again consider this under the three methods, Classic, Proposed, and Amended. Classic: Proposed: Amended: AB 1- x23A wins No Vote No Vote -1 x21 1- x23A wins No Vote A wins -1 x22 1- x23B wins No Vote B wins -1 x24 we can plainly see that the amended version prevents a few voters to make a decision for the whole, but does allow for the will of sufficient voters to be made. > This fails the Monotonicity Criterion (MC) > > Statement of Criterion > >With the relative order or rating of the other >candidates unchanged, voting a candidate higher should >never cause the candidate to lose, nor should voting a >candidate lower ever cause the candidate to win. > > This is really bad. If this were the case. However, there was no changing the order of vote. the amendment maintains the Monotonicity Criterion. unless, of course, you consider casting a new vote the same as changing an existing one. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Raul Miller wrote: > On Tue, May 20, 2003 at 12:19:33PM -0700, John H. Robinson, IV wrote: > >The amendment uses the concept of a Quorum requirement to inhibit > >"stealth decisions" by only a handful of developers. While this is a > >good thing, the per-option quorum from the amendment has a tendency to > >further influence the outcome of the vote in a hard-to-understand > >way. This modification corrects this deficiency. > > "Hard to understand"? We'd require a certain level of voter approval > before we'll consider an option -- options which don't achieve that > can't win. How is this "hard to understand"? by counting a ranking higher than default as a special vote. this is what makes it hard to understand. it also opens up the avenue for strategic voting via insincere voting. example: quorum of 20, two ballots on the measure, plus the default option. two major schools of thought: those that support option A, and those that support option B. privately, each consider action on the item better than no action, but the A supporters, being the smaller of the two camps (10 members, vs the 15 members for B), really want their measure to win. they, as a block, vote 132. the B supporters vote sincerely, and vote 213. using the rules as proposed by Manoj, option B would fail to make its better-than-default quota (having only 15 of 20). option B would then be dropped. A easily beats default, and thus A wins. using a straight Condorcet, or even a Cloneproof SSD, option B would win. my amendment restores that feature of Condorcet/Cloneproof SSD. > Note also that your amendment would create situations in which a > developer voting against an option might cause that option to win*. > How is this "easier to understand"? > > * For example: > >quorum: 20 > >developer has reason to believe that not many votes will be cast. >developer has reason to believe that the few votes which will be >cast will be in favor of an option which developer is opposed to. > >Casting ballot against that option might cause ballot to achieve >quorum. this is a strawman, because if default per-item quota. >[Yes, this circumstance is unlikely -- that's because "not meeting >quorum" is itself unlikely. If "not meeting quorum" becomes >likely then this example also becomes likely.] even if this were the case, if there were no quota requirements, as in a straight Condorcet or Cloneproof SSD, the most preferred option would win regardless. the purpose of quorum is to inhibit ``stealth decisions'' by only a few developers. this purpose is met very well by the amended implementation of quorum. quorum is not meant to change the winner of the vote. > To make your proposal work right, we'd need a separate quorum > determination phase which is independent of the voting phase. i fail to see that argument. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Matthias Urlichs wrote: > > You actually propose two separate amendments. Please don't do that, it > smells of politics. :-/ the changes are related, if just 2 was changed, then the majority requirements in 3 have an undesired side-effect. let me find that message . . = http://lists.debian.org/debian-vote/2003/debian-vote-200305/msg00046.html = = If no supermajority is required the majority ratio is 1, = which means that the option is dropped if V(A,D) < V(D,A)+1. = So this implements a quorum of 1 in the sense of the original = draft for all options. > The point of wording it the "old" way was that any option which is ranked > below the default by a majority is removed before starting the algorithm. Not correct. The original proposal simply threw out the voter's intent iff the option did not have R+1 people ranking it higher than default. this is where the concept of quorum is being mis-applied. this is what is being fixed. > That is intentional; otherwise, a case can be constructed where such an > option could win, which is Not Good. a much easier and likely case can be constructed where an otherwise winning option is dropped before consideration, which is Even Worse. -john
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
Fellow developers, I propose the following amendment to the Condorcet/Clone Proof SSD vote tallying Constitutional amendment. This amendment supersedes the amendment proposed in Message-ID: <[EMAIL PROTECTED]> If the sponsor rejects this change, I request seconds on this amendment, so that it appears on the ballot. Rationale for change: The amendment uses the concept of a Quorum requirement to inhibit "stealth decisions" by only a handful of developers. While this is a good thing, the per-option quorum from the amendment has a tendency to further influence the outcome of the vote in a hard-to-understand way. This modification corrects this deficiency. An easy example: a ballot with two items plus the default item. Quorum is 20, with 25 eligible voters voting. A B D # of ballots cast 2 1 315 1 210 Here, option B is preferred over option A by the voters. Under the original proposal, Option B would be discarded due to insufficient quorum requirements, and A would win. Under the amended proposal, option B would win. Please join the discussion on debian-vote. -- John H. Robinson, IV jaqque () debian () org --- proposal-srivasta Fri May 16 09:42:59 2003 +++ proposal-jaqque Mon May 19 11:43:13 2003 @@ -1,139 +1,139 @@ PROPOSAL __ Constitutional amendment: Condorcet/Clone Proof SSD vote tallying: __ Under 4.2 Procedure [for developers during a general resolution or election], change item 3 to read: 3. Votes are taken by the Project Secretary. Votes, tallies, and results are not revealed during the voting period; after the vote the Project Secretary lists all the votes cast. The voting period is 2 weeks, but may be varied by up to 1 week by the Project Leader. __ Under 5.2 Appointment of project leader, change item 7 to read: 7. The decision will be made using the method specified in section A.6 of the Standard Resolution Procedure. The quorum is the same as for a General Resolution (s.4.2) and the default option is "None Of The Above". __ Under 6.1 Powers [of the technical committee], change item 7 to read: 7. Appoint the Chairman of the Technical Committee. The Chairman is elected by the Committee from its members. All members of the committee are automatically nominated; the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). The members may vote by public acclamation for any fellow committee member, including themselves; there is no default option. The vote finishes when all the members have voted, or when the voting period has ended. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure. __ Under A.2 Calling for a vote, change items 2 and 4 to read 2. The proposer or any sponsor of a resolution may call for a vote on that resolution and all related amendments. 4. The minimum discussion period is counted from the time the last formal amendment was accepted, or since the whole resolution was proposed if no amendments have been proposed and accepted. __ Replace A.3 with: A.3. Voting procedure 1. Each resolution and its related amendments is voted on in a single ballot that includes an option for the original resolution, each amendment, and the default option (where applicable). 2. The default option must not have any supermajority requirements. Options which do not have an explicit supermajority requirement have a 1:1 majority requirement. 3. The votes are counted according to the the rules in A.6. The default option is "Further Discussion", unless specified otherwise. 4. In cases of doubt the Project Secretary shall decide on matters of procedure. __ Replace A.5 with: A.5. Expiry If a proposed resolution has not been discussed, amended, voted on or otherwise dealt with for 4 weeks the secretary may issue a statement that the issue is being withdrawn. If none of the sponsors of any of the proposals object within a week, the issue is withdrawn. The secretary may also include suggestions o
Re: Constitutional amendment: Condorcet/Clone Proof SSD vote tallying
ment may be withdrawn, or resume a discussion period at the sponsor's discretion. > 3. Any (non-default) option which does not defeat the default option > by its required majority ratio is dropped from consideration. > a. Given two options A and B, V(A,B) is the number of voters >who prefer option A over option B. > b. An option A defeats the default option D by a majority >ratio N, if V(A,D) is strictly greater than N * V(D,A). > c. If a supermajority of S:1 is required for A, its majority ratio >is S; otherwise, its majority ratio is 1. > 4. From the list of undropped options, we generate a list of > pairwise defeats. > a. An option A defeats an option B, if V(A,B) is strictly greater >than V(B,A). > 5. From the list of [undropped] pairwise defeats, we generate a > set of transitive defeats. > a. An option A transitively defeats an option C if A defeats >C or if there is some other option B where A defeats B AND >B transitively defeats C. > 6. We construct the Schwartz set from the set of transitive defeats. > a. An option A is in the Schwartz set if for all options B, >either A transitively defeats B, or B does not transitively >defeat A. > 7. If there are defeats between options in the Schwartz set, > we drop the weakest such defeats from the list of pairwise > defeats, and return to step 5. > a. A defeat (A,X) is weaker than a defeat (B,Y) if V(A,X) >is less than V(B,Y). Also, (A,X) is weaker than (B,Y) if >V(A,X) is equal to V(B,Y) and V(X,A) is greater than V(Y,B). > b. A weakest defeat is a defeat that has no other defeat weaker >than it. There may be more than one such defeat. > 8. If there are no defeats within the Schwartz set, then the winner > is chosen from the options in the Schwartz set. If there is > only one such option, it is the winner. If there are multiple > options, the elector with the casting vote chooses which of those > options wins. > > RATIONALE: 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. > > __ Rationale for change: If a person votes, but they do not list a specific item, that person has still indicated a preference for that item as being lower than all ranked options. This treats a -1 ballot equal to a 21 ballot. -- John H. Robinson, IV jaqque () debian () org pgpsZSai8n6H3.pgp Description: PGP signature
Re: Ending votes early
Manoj Srivastava wrote: > > I suggest we strike the clause about the secretary's ability > to end votes early. i concur. -john
Re: supermajority options
Chris Lawrence wrote: > > Except, we're stuck with the non-compromise in the meantime. If Vote > #1 is "rm -rf ftp.debian.org:/debian/pool/non-free", it's going to be > a bit of a pain to fix that :-) restore from backup. restore from snapshot.debian.org not that hard. -john
Re: supermajority options
Chris Lawrence wrote: > > Except, we're stuck with the non-compromise in the meantime. If Vote > #1 is "rm -rf ftp.debian.org:/debian/pool/non-free", it's going to be > a bit of a pain to fix that :-) restore from backup. restore from snapshot.debian.org not that hard. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: supermajority options
Raul Miller wrote: > > I'm assuming that we can describe an implementation of supermajority > with CpSSD where supermajority does not encourage insincere voting. WRT changes to the Constitution, a Tyrrany of the Status Quo may not be a bad thing. my sole purpose in bringing up the study was to make the point that Supermajorities cause that. in the case of a Near Unanimous Decision being overturned by a slightly-over-half majority is yes. that is a fine thing. if half of the voters changed their mind, then there must have been something really bad about the previous decision. if the new direction is bad, then we can use the same process to fix it, again. at some point, either it will be fixed, or the populace will get fed up with the whole thing, and stop voting. > If we can't find a decent implementation of supermajority, I'll be > forced to agree with you that we should drop the idea of supermajority. > However, I'm not ready to give up yet. please, press on. if we can find an acceptable method of counting Supermajorities, then we can discuss the merits of Supermajorities further. i'm actually on the fence about Supermajorities in theory, though i don't like the idea of a flawed implementation. -john
Re: Nov 19 draft of voting amendment
Jochen Voss wrote: > Hello, > > On Wed, Nov 20, 2002 at 05:24:02PM +1000, Anthony Towns wrote: > > 2. If fewer ballots are received than the required quorum for > > the vote, the default option is declared the winner. > This is a version of quorum I could happily live with. provided that the Default Option is, as the Constitution decrees, Further Discussion, then this too i can live with. if the Default Option is something other that Further Discussion or Forget We Ever Had This Vote, then i cannot agree. i'd prefer to see the whole vote thrown out (non-binding) however. -john
Re: supermajority options
Raul Miller wrote: > Branden Robinson wrote: > > > Supermajority requirements don't retard mistakes, just change. > > On Wed, Nov 20, 2002 at 11:04:10PM -0800, John H. Robinson, IV wrote: > > i tend to agree with the philosophy that you need to convince at least > > half of the voting populous. > > [1] Who is the voting populous? depends upon where you count, you have all elgible voters, then you have those voters that actually vote, then you have the minimum number of voters to vote for a vote to be binding. the last one refers to quorum. i specifically meant half of those that are interested enough to actually vote. if that number fails to meet quorom, then there is not enough interest in the issue to perform any action on it. > [2] Why are they the voting populous? depends upon context. in the US, it is citizens over 18 that have not had their right to vote (ie: convicted of a felony) revoked. in this context, it is each Debian Developer as listed in the Constitution. in other contexts, by virute of being in the set defined as The Set of Eligble Voters,or however you want to phrase it > [3] Is competence an issue? Why or why not? yes it is. in the US system, it is assumed that you are competent at age > 18, until proven otherwise (ie: convicted of a felony) in this context, each DD has been vetted by the NM procress, in whatever form that was at the time of induction. in this context, we also demand competence by forcing voters to follow directions on filling out and returning the ballot. > [4] Is involvement an issue? Why or why not? yes. you have to have at least ONE person vote. if NO ONE participates, then you have no results. you can increase the demands of participation via quorum requirements. i can see requiring a higher quorom for certain actions (Constitutional Ammendment) than for other things (Official Debian Mascot) to ensure that there is enough interest in the issue. i beleive that the more interest you have, the more likely you are to see a greater reflection of the groups desire. you get a perfect picture at 100% participation. if every eligble DD voted, and the Smith set had only 415:414 would that indicate that the Debian Project should move in the direction indicated? > [Hint: for most things in Debian, you need to convince at least one > person who happens to be the package maintainer.] yep. in the case of GR's, you need to convince six (sponsor and five seconds) > > Condorecet seems pretty resilient to insincere voting. for each method > > of counting Supermajorities, it has been shown to where it possible, in > > some cases almost trivial, for an insincere vote to change the result of > > an election. that appears to defeat the whole purpose of using Condorcet > > to begin with. > > For some methods, this is true. > > You seem to be assuming this is true for all methods, but you offer > no proof. that is correct. i do not have the math to do that. however, those with the math (here i refer to electionmethods.org) do not address the issue of Supermahorities at all. > > just out of idle curiosity, has anyone asked the electionmethods people > > about Condorcet+Supermajority? > > Yes. > > Unfortunately, most of them seemed to lose interest in the discussion > before we had much discussed the underlying issues. :( so we are floundering on our own on this one? > That said: Debian 3:1 supermajority is LESS OF A CONSTRAINT than a > requirement that a majority of the voting population agree. depending upon quorum requirements, and how you defice ``voting population.'' most methods define it as those that are eliglble to vote _and_ actually vote. this is where quorum comes in: that there is sufficient interest to use as a statistical model that the subset reflects the entire set. > Are you suggesting that we prefer majority rule because it's more of a > constraint ["more tyranical"] than supermajority? i will agree with branden that the use of the word tyrannical in this case is bad. however, i will still answer the question. i am suggesting that we prefer majority rule because with our election method (Condorcet) it has been shown that at least some methods of counting Supermajorities can lead to insincere voting for strategic purposes being effective. this is one of the things we wish to _avoid_. > Or are you saying something else that I've completely misunderstood? something else (see above). -john
Re: supermajority options
Raul Miller wrote: > > I'm assuming that we can describe an implementation of supermajority > with CpSSD where supermajority does not encourage insincere voting. WRT changes to the Constitution, a Tyrrany of the Status Quo may not be a bad thing. my sole purpose in bringing up the study was to make the point that Supermajorities cause that. in the case of a Near Unanimous Decision being overturned by a slightly-over-half majority is yes. that is a fine thing. if half of the voters changed their mind, then there must have been something really bad about the previous decision. if the new direction is bad, then we can use the same process to fix it, again. at some point, either it will be fixed, or the populace will get fed up with the whole thing, and stop voting. > If we can't find a decent implementation of supermajority, I'll be > forced to agree with you that we should drop the idea of supermajority. > However, I'm not ready to give up yet. please, press on. if we can find an acceptable method of counting Supermajorities, then we can discuss the merits of Supermajorities further. i'm actually on the fence about Supermajorities in theory, though i don't like the idea of a flawed implementation. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Nov 19 draft of voting amendment
Jochen Voss wrote: > Hello, > > On Wed, Nov 20, 2002 at 05:24:02PM +1000, Anthony Towns wrote: > > 2. If fewer ballots are received than the required quorum for > > the vote, the default option is declared the winner. > This is a version of quorum I could happily live with. provided that the Default Option is, as the Constitution decrees, Further Discussion, then this too i can live with. if the Default Option is something other that Further Discussion or Forget We Ever Had This Vote, then i cannot agree. i'd prefer to see the whole vote thrown out (non-binding) however. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: supermajority options
Raul Miller wrote: > Branden Robinson wrote: > > > Supermajority requirements don't retard mistakes, just change. > > On Wed, Nov 20, 2002 at 11:04:10PM -0800, John H. Robinson, IV wrote: > > i tend to agree with the philosophy that you need to convince at least > > half of the voting populous. > > [1] Who is the voting populous? depends upon where you count, you have all elgible voters, then you have those voters that actually vote, then you have the minimum number of voters to vote for a vote to be binding. the last one refers to quorum. i specifically meant half of those that are interested enough to actually vote. if that number fails to meet quorom, then there is not enough interest in the issue to perform any action on it. > [2] Why are they the voting populous? depends upon context. in the US, it is citizens over 18 that have not had their right to vote (ie: convicted of a felony) revoked. in this context, it is each Debian Developer as listed in the Constitution. in other contexts, by virute of being in the set defined as The Set of Eligble Voters,or however you want to phrase it > [3] Is competence an issue? Why or why not? yes it is. in the US system, it is assumed that you are competent at age > 18, until proven otherwise (ie: convicted of a felony) in this context, each DD has been vetted by the NM procress, in whatever form that was at the time of induction. in this context, we also demand competence by forcing voters to follow directions on filling out and returning the ballot. > [4] Is involvement an issue? Why or why not? yes. you have to have at least ONE person vote. if NO ONE participates, then you have no results. you can increase the demands of participation via quorum requirements. i can see requiring a higher quorom for certain actions (Constitutional Ammendment) than for other things (Official Debian Mascot) to ensure that there is enough interest in the issue. i beleive that the more interest you have, the more likely you are to see a greater reflection of the groups desire. you get a perfect picture at 100% participation. if every eligble DD voted, and the Smith set had only 415:414 would that indicate that the Debian Project should move in the direction indicated? > [Hint: for most things in Debian, you need to convince at least one > person who happens to be the package maintainer.] yep. in the case of GR's, you need to convince six (sponsor and five seconds) > > Condorecet seems pretty resilient to insincere voting. for each method > > of counting Supermajorities, it has been shown to where it possible, in > > some cases almost trivial, for an insincere vote to change the result of > > an election. that appears to defeat the whole purpose of using Condorcet > > to begin with. > > For some methods, this is true. > > You seem to be assuming this is true for all methods, but you offer > no proof. that is correct. i do not have the math to do that. however, those with the math (here i refer to electionmethods.org) do not address the issue of Supermahorities at all. > > just out of idle curiosity, has anyone asked the electionmethods people > > about Condorcet+Supermajority? > > Yes. > > Unfortunately, most of them seemed to lose interest in the discussion > before we had much discussed the underlying issues. :( so we are floundering on our own on this one? > That said: Debian 3:1 supermajority is LESS OF A CONSTRAINT than a > requirement that a majority of the voting population agree. depending upon quorum requirements, and how you defice ``voting population.'' most methods define it as those that are eliglble to vote _and_ actually vote. this is where quorum comes in: that there is sufficient interest to use as a statistical model that the subset reflects the entire set. > Are you suggesting that we prefer majority rule because it's more of a > constraint ["more tyranical"] than supermajority? i will agree with branden that the use of the word tyrannical in this case is bad. however, i will still answer the question. i am suggesting that we prefer majority rule because with our election method (Condorcet) it has been shown that at least some methods of counting Supermajorities can lead to insincere voting for strategic purposes being effective. this is one of the things we wish to _avoid_. > Or are you saying something else that I've completely misunderstood? something else (see above). -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: supermajority options
Branden Robinson wrote: > > > Also, what do you think of imposing some kind of quorum requirement > > (like maybe 1% of the voters need to vote in an election which > > changes the constitution, or some other such thing quite a bit more > > severe for our current set of developers than that of any draft I've > > proposed)? > > While it is true that I think quorum requirements are superfluous as > well, I don't see perceive them carrying the same baggage as > supermajority requirements, so I would not object to your above > proposal. i have no problem with any quorum requirement provided the following points are met: 1) it is a reasonable number * in a body as large as Debian, 90% quorum would be unreasonable. * 25% i think is getting close to the upper end. * 1.5*sqrt(num of electorate) seems low, but acceptable. * for comparison, what was the voter turnout for the last few votes? 2) quorum applies to _entire_ ballots returned, not specific entries on the ballots. 3) failure to meet quorum results in a thrown out vote * as if the vote had never taken place * as a reasonable option, though not preferred, the Default Option of Further Discussion is declared the winner. * but that leads to the point: how can a vote be binding, if quorum was not met? -john
Re: supermajority options
Branden Robinson wrote: > > > Also, what do you think of imposing some kind of quorum requirement > > (like maybe 1% of the voters need to vote in an election which > > changes the constitution, or some other such thing quite a bit more > > severe for our current set of developers than that of any draft I've > > proposed)? > > While it is true that I think quorum requirements are superfluous as > well, I don't see perceive them carrying the same baggage as > supermajority requirements, so I would not object to your above > proposal. i have no problem with any quorum requirement provided the following points are met: 1) it is a reasonable number * in a body as large as Debian, 90% quorum would be unreasonable. * 25% i think is getting close to the upper end. * 1.5*sqrt(num of electorate) seems low, but acceptable. * for comparison, what was the voter turnout for the last few votes? 2) quorum applies to _entire_ ballots returned, not specific entries on the ballots. 3) failure to meet quorum results in a thrown out vote * as if the vote had never taken place * as a reasonable option, though not preferred, the Default Option of Further Discussion is declared the winner. * but that leads to the point: how can a vote be binding, if quorum was not met? -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: supermajority options
Branden Robinson wrote: > > Supermajority requirements don't retard mistakes, just change. i tend to agree with the philosophy that you need to convince at least half of the voting populous. Condorecet seems pretty resilient to insincere voting. for each method of counting Supermajorities, it has been shown to where it possible, in some cases almost trivial, for an insincere vote to change the result of an election. that appears to defeat the whole purpose of using Condorcet to begin with. just out of idle curiosity, has anyone asked the electionmethods people about Condorcet+Supermajority? should someone? a google search produced this: http://www.google.com/search?q=cache:4wJT-1c0FykC:www.democ.uci.edu/democ/papers/McGann02.pdf+condorcet+supermajority&hl=en&ie=UTF-8 this paper seems to say that supermajorities produce a tyranny of the status quo, *at the expense of the minority* -john
Re: supermajority options
Branden Robinson wrote: > > Supermajority requirements don't retard mistakes, just change. i tend to agree with the philosophy that you need to convince at least half of the voting populous. Condorecet seems pretty resilient to insincere voting. for each method of counting Supermajorities, it has been shown to where it possible, in some cases almost trivial, for an insincere vote to change the result of an election. that appears to defeat the whole purpose of using Condorcet to begin with. just out of idle curiosity, has anyone asked the electionmethods people about Condorcet+Supermajority? should someone? a google search produced this: http://www.google.com/search?q=cache:4wJT-1c0FykC:www.democ.uci.edu/democ/papers/McGann02.pdf+condorcet+supermajority&hl=en&ie=UTF-8 this paper seems to say that supermajorities produce a tyranny of the status quo, *at the expense of the minority* -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Another proposal.
Matthias Urlichs wrote: > Hi, > > John H. Robinson, IV: > > also, with the Condorcet + SSD election method, is the supermajority > > requirements really required? it does allow a vocal minority to block an > > action. > > No it doesn't. If a majority rank option A first, that option wins -- end > of vote. (Unless you use the Borda method ... but we don't.) sorry, poor pronoun placement on my part. my meaning was: also, with the Condorcet + SSD election method, is the supermajority requirements really required? the supermajority requirement does allow a vocal minority to block an action. the case brought up, changing the constitution, i think is a good example: it requires 3:1. this means that such an option requires a lot of buy-in. i'm ambivalent over the whole Supermajority and Quorum thing. I'll re-read the lastest draft, real slowly, and see how i feel after that. -john
Re: Another proposal.
Raul Miller wrote: > > That's the way I read his suggestion, also. And that's what I was saying > is bad. I don't think you understood my objection. > > Here's the problem: a vote against an option can cause quorum to be met > and therefore cause the option to win. This discourages sincere votes > against the option. i don't buy that logic. the case is true, and having X>Q votes causes the vote to be binding. you are assuming that only proponents of a ballot will bother to vote. if the proponent fails to get anyone interested in her ballot other than her self and her second, then votes against would have a sincere impact and prevent Further Discussion. i can see two major outcomes when X
Re: Another proposal.
Matthias Urlichs wrote: > Hi, > > John H. Robinson, IV: > > also, with the Condorcet + SSD election method, is the supermajority > > requirements really required? it does allow a vocal minority to block an > > action. > > No it doesn't. If a majority rank option A first, that option wins -- end > of vote. (Unless you use the Borda method ... but we don't.) sorry, poor pronoun placement on my part. my meaning was: also, with the Condorcet + SSD election method, is the supermajority requirements really required? the supermajority requirement does allow a vocal minority to block an action. the case brought up, changing the constitution, i think is a good example: it requires 3:1. this means that such an option requires a lot of buy-in. i'm ambivalent over the whole Supermajority and Quorum thing. I'll re-read the lastest draft, real slowly, and see how i feel after that. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Another proposal.
Raul Miller wrote: > > That's the way I read his suggestion, also. And that's what I was saying > is bad. I don't think you understood my objection. > > Here's the problem: a vote against an option can cause quorum to be met > and therefore cause the option to win. This discourages sincere votes > against the option. i don't buy that logic. the case is true, and having X>Q votes causes the vote to be binding. you are assuming that only proponents of a ballot will bother to vote. if the proponent fails to get anyone interested in her ballot other than her self and her second, then votes against would have a sincere impact and prevent Further Discussion. i can see two major outcomes when X
Re: Another proposal.
Raul Miller wrote: > > On the other hand, we've never had an official vote which was even close > to failing to meet our quorum requirement. let me see if i undserstand this quorom thing: we want to know that a significant portion of the electorate care enough to represent themselves. so would not the quorum be the simple number of votes cast? if the quorum is 72, and seventy people vote, then quorom is not met, and the vote is invalidated on those grounds. regardless if all vote ABF and thus A has supermajority (at any ratio) over B and F. i had always understood quorum as the minimum number of participants to conduct business. also, with the Condorcet + SSD election method, is the supermajority requirements really required? it does allow a vocal minority to block an action. is that desired? if so, why? -john i may spell quorum wrong, but at least i am consistent (too lazy to do a :%s/quorom/quorum)
Re: Another proposal.
Raul Miller wrote: > > On the other hand, we've never had an official vote which was even close > to failing to meet our quorum requirement. let me see if i undserstand this quorom thing: we want to know that a significant portion of the electorate care enough to represent themselves. so would not the quorum be the simple number of votes cast? if the quorum is 72, and seventy people vote, then quorom is not met, and the vote is invalidated on those grounds. regardless if all vote ABF and thus A has supermajority (at any ratio) over B and F. i had always understood quorum as the minimum number of participants to conduct business. also, with the Condorcet + SSD election method, is the supermajority requirements really required? it does allow a vocal minority to block an action. is that desired? if so, why? -john i may spell quorum wrong, but at least i am consistent (too lazy to do a :%s/quorom/quorum) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Wed, Apr 03, 2002 at 01:58:36PM -0500, Jeff Licquia wrote: > On Wed, 2002-04-03 at 12:48, John H. Robinson, IV wrote: > > On Wed, Apr 03, 2002 at 12:16:18AM -0500, Anthony DeRobertis wrote: > > > > > > 5) Each voter can verify the correctness of his vote > > > 8) No voter can prove to another person how he voted. > > > > these two seem mutually exclusive. > > It's theoretically possible to satisfy both goals at once. (Whether > it's practically possible is another matter; it's been a while since > I've real _Applied Cryptography_.) i've never read it. perhaps i should put that on my to-read list. so how can we facilitate 5, while keeping 8 true? in our current scheme, we have the entire list of votes. so say i voted 2341, and you voted 2341, and a third person voted 1234. we get the following tallies: 1234 2341 4321 we both see that our vote was tallied, and counted properly (yes, this is the exact situation that we saw before ;) both of our names are listed, and we see that the number of voters match the number of votes. however, there is an extra vote, 4321, that does not match anyone. i cannot prove that the 2341 is mine, just as youcannot prove that it is yours, only that it matches what we voted. so the secret tokens came along, with our logins as the salt, so we can correlate conclusively. this is why, on the surface, i believe points 5 and 8 are mutually exclusive: with no identifying marks, all identicle votes are indistiguishable. in a paper puch ballot, at least in my voting district, you get a little receipt with a number, that number matches the number on the ballot itself. the only way to prove how i voted is to match my little recepit with the paper ballot locked away somewhere (yes, for those interested, i ensured i had no hanging or swinging chads ;). of course, i could not prove to my own satisfaction that my vote was actually counted :( -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Wed, Apr 03, 2002 at 12:16:18AM -0500, Anthony DeRobertis wrote: > I assume the following are the goals of verifying a vote. I > believe these goals are justified: > > 5) Each voter can verify the correctness of his vote > 8) No voter can prove to another person how he voted. these two seem mutually exclusive. if you can prove your own vote, how could you possibly not be able to prove that vote to another person? -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Wed, Apr 03, 2002 at 01:58:36PM -0500, Jeff Licquia wrote: > On Wed, 2002-04-03 at 12:48, John H. Robinson, IV wrote: > > On Wed, Apr 03, 2002 at 12:16:18AM -0500, Anthony DeRobertis wrote: > > > > > > 5) Each voter can verify the correctness of his vote > > > 8) No voter can prove to another person how he voted. > > > > these two seem mutually exclusive. > > It's theoretically possible to satisfy both goals at once. (Whether > it's practically possible is another matter; it's been a while since > I've real _Applied Cryptography_.) i've never read it. perhaps i should put that on my to-read list. so how can we facilitate 5, while keeping 8 true? in our current scheme, we have the entire list of votes. so say i voted 2341, and you voted 2341, and a third person voted 1234. we get the following tallies: 1234 2341 4321 we both see that our vote was tallied, and counted properly (yes, this is the exact situation that we saw before ;) both of our names are listed, and we see that the number of voters match the number of votes. however, there is an extra vote, 4321, that does not match anyone. i cannot prove that the 2341 is mine, just as youcannot prove that it is yours, only that it matches what we voted. so the secret tokens came along, with our logins as the salt, so we can correlate conclusively. this is why, on the surface, i believe points 5 and 8 are mutually exclusive: with no identifying marks, all identicle votes are indistiguishable. in a paper puch ballot, at least in my voting district, you get a little receipt with a number, that number matches the number on the ballot itself. the only way to prove how i voted is to match my little recepit with the paper ballot locked away somewhere (yes, for those interested, i ensured i had no hanging or swinging chads ;). of course, i could not prove to my own satisfaction that my vote was actually counted :( -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Wed, Apr 03, 2002 at 12:16:18AM -0500, Anthony DeRobertis wrote: > I assume the following are the goals of verifying a vote. I > believe these goals are justified: > > 5) Each voter can verify the correctness of his vote > 8) No voter can prove to another person how he voted. these two seem mutually exclusive. if you can prove your own vote, how could you possibly not be able to prove that vote to another person? -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret votes HOWTO
On Wed, Apr 04, 2001 at 09:59:26PM -0700, Seth Arnold wrote:
>
> However, I think we agree that it really ought to be hashed -- I like
> how the hash ties the vote to the voter along with the secret
> information in a manner that is inextricable yet anonymous.
hashed:
12345 553f1ae9b45bee7aeede6a97605bacaa
nothashed:
12345 0xF456 5492
(for the hased, i hased the vote (12345), with the d.o login (alice),
and the user-supplied entropy (s3kr!t))
the nothashed has the vote, the system supplied entropy, and the
user-supplied entropy.
i am not here to argue the relative merits of the strength of entropy
pools. the idea is to say ``yes, that is my vote, and that is how i
voted, and when i tally up the votes, they come out to what the
secretary said they came up with. i know my vote was not tampered with,
and yes, and my name does show up at the list in the bottom :)''
the point is, the hash is not required. the per-user verification is. i
think manoj and i agree that checking (say) 8 digits is easier than an
md5sum.
at any rate, system-supplied entropy and user supplied entropy will be
required (in the hash case, it can be username. in the nothashed case,
it would be an arbitrary value sent along with the confirmation)
i suppose if one were so inclined, one could use a bit of both:
bothhash:
12345 553f1ae9b45bee7aeede6a97605bacaa s3kr!t
this way we have both the hash, and the user-supplied entropy. so the
user need only scan for their splied entropy and perform further
verification as required.
but in this case, the md5sum only masks as server side entropy.
(but it also makes it trivial to determine who cast the vote:
% for i in ${=USERS}; do [ `echo 12345 $i s3kr\!t | md5sum` =
553f1ae9b45bee7aeede6a97605bacaa ] && echo it was ${i}\`s vote ; done
and that violates the whole idea of a secret vote, so that idea is bad.
let's ignore that one, shall we?
so: hashed and nothashed both provide the same benefits. it's just a
matter of which is prefered.
-john
Re: Secret votes HOWTO
On Wed, Apr 04, 2001 at 09:59:26PM -0700, Seth Arnold wrote:
>
> However, I think we agree that it really ought to be hashed -- I like
> how the hash ties the vote to the voter along with the secret
> information in a manner that is inextricable yet anonymous.
hashed:
12345 553f1ae9b45bee7aeede6a97605bacaa
nothashed:
12345 0xF456 5492
(for the hased, i hased the vote (12345), with the d.o login (alice),
and the user-supplied entropy (s3kr!t))
the nothashed has the vote, the system supplied entropy, and the
user-supplied entropy.
i am not here to argue the relative merits of the strength of entropy
pools. the idea is to say ``yes, that is my vote, and that is how i
voted, and when i tally up the votes, they come out to what the
secretary said they came up with. i know my vote was not tampered with,
and yes, and my name does show up at the list in the bottom :)''
the point is, the hash is not required. the per-user verification is. i
think manoj and i agree that checking (say) 8 digits is easier than an
md5sum.
at any rate, system-supplied entropy and user supplied entropy will be
required (in the hash case, it can be username. in the nothashed case,
it would be an arbitrary value sent along with the confirmation)
i suppose if one were so inclined, one could use a bit of both:
bothhash:
12345 553f1ae9b45bee7aeede6a97605bacaa s3kr!t
this way we have both the hash, and the user-supplied entropy. so the
user need only scan for their splied entropy and perform further
verification as required.
but in this case, the md5sum only masks as server side entropy.
(but it also makes it trivial to determine who cast the vote:
% for i in ${=USERS}; do [ `echo 12345 $i s3kr\!t | md5sum` =
553f1ae9b45bee7aeede6a97605bacaa ] && echo it was ${i}\`s vote ; done
and that violates the whole idea of a secret vote, so that idea is bad.
let's ignore that one, shall we?
so: hashed and nothashed both provide the same benefits. it's just a
matter of which is prefered.
-john
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret votes HOWTO
On Sat, Mar 31, 2001 at 07:47:41PM -0500, Raul Miller wrote: > > $ echo '12345 alice 3125' | md5sum > 9351a30fdcaca3caf8562172b2d02512 > $ > > I was thinking the response would be: > > To: Alice <[EMAIL PROTECTED]> > From: [EMAIL PROTECTED] > Subject: Your vote has been counted > > Your vote is '12345 alice 3125' > Your ID (the md5sum of your vote) is 9351a30fdcaca3caf8562172b2d02512 oh. that works too, since alice (the debian login) would be unique, and be enough to prevent collisions. but it is harder to scan for 33 numbers than (say) 8. but other than that, the results are the same: a unique, reporoduceable identifier that is difficult to surreptitiously change. -john
Re: Secret votes HOWTO
On Sat, Mar 31, 2001 at 06:01:35PM -0500, Raul Miller wrote: > On Sat, Mar 31, 2001 at 02:48:51PM -0800, John H. Robinson, IV wrote: > > user-supplied random data plus system-generated random data would > > probably be required, to prevent collision between Alice and Bob both > > supplying the same random data. > > Alternatively, the user's debian-id could be included (since this is > guaranteed to be unique for any valid voter). i was thinking something like: ---cut here--- To: [EMAIL PROTECTED] From: Alice <[EMAIL PROTECTED]> Subject: My Vote [12345] 3125 To: Alice <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] Subject: Your vote has been counted Your ID is 3125- ---cut here--- where 3125 is the user supplied, and is the system supplied. and the votes would be listed as: ---cut here--- --1-- 3125-0837 12345 3125- 54321 -5433 the following people voted: alice bob charlie ---cut here--- or whatever. if you hash it, then the user can't tell if the result has been mucked with or not. and if you used debian-id (what is this? the UID on the debian systems?) then a simple lookup could tell the Thought Police who voted how. > However, you still need some source of randomness (user-supplied is best, > I think) to avoid dictionary analysis of the acknowledgement hash. only if the user could indeed verify that her salt is part of the hash. otherwise you could get into the ``everyone that votes 12345 gets the hash of 0xDEADBEEF'' -john
Re: Secret votes HOWTO
On Sat, Mar 31, 2001 at 07:47:41PM -0500, Raul Miller wrote: > > $ echo '12345 alice 3125' | md5sum > 9351a30fdcaca3caf8562172b2d02512 > $ > > I was thinking the response would be: > > To: Alice <[EMAIL PROTECTED]> > From: [EMAIL PROTECTED] > Subject: Your vote has been counted > > Your vote is '12345 alice 3125' > Your ID (the md5sum of your vote) is 9351a30fdcaca3caf8562172b2d02512 oh. that works too, since alice (the debian login) would be unique, and be enough to prevent collisions. but it is harder to scan for 33 numbers than (say) 8. but other than that, the results are the same: a unique, reporoduceable identifier that is difficult to surreptitiously change. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret votes HOWTO
On Sat, Mar 31, 2001 at 02:29:41PM -0800, Seth Arnold wrote: > > The idea I like the most so far is the 'user-supplied random nonce' > idea. I like this idea because using a collection of other data is > liable to failure because stupid email systems manage to molest email > in the strangest fashion: "From " to ">From ", etc. user-supplied random data plus system-generated random data would probably be required, to prevent collision between Alice and Bob both supplying the same random data. -john
Re: Secret votes HOWTO
On Sat, Mar 31, 2001 at 06:01:35PM -0500, Raul Miller wrote: > On Sat, Mar 31, 2001 at 02:48:51PM -0800, John H. Robinson, IV wrote: > > user-supplied random data plus system-generated random data would > > probably be required, to prevent collision between Alice and Bob both > > supplying the same random data. > > Alternatively, the user's debian-id could be included (since this is > guaranteed to be unique for any valid voter). i was thinking something like: ---cut here--- To: [EMAIL PROTECTED] From: Alice <[EMAIL PROTECTED]> Subject: My Vote [12345] 3125 To: Alice <[EMAIL PROTECTED]> From: [EMAIL PROTECTED] Subject: Your vote has been counted Your ID is 3125- ---cut here--- where 3125 is the user supplied, and is the system supplied. and the votes would be listed as: ---cut here--- --1-- 3125-0837 12345 3125- 54321 -5433 the following people voted: alice bob charlie ---cut here--- or whatever. if you hash it, then the user can't tell if the result has been mucked with or not. and if you used debian-id (what is this? the UID on the debian systems?) then a simple lookup could tell the Thought Police who voted how. > However, you still need some source of randomness (user-supplied is best, > I think) to avoid dictionary analysis of the acknowledgement hash. only if the user could indeed verify that her salt is part of the hash. otherwise you could get into the ``everyone that votes 12345 gets the hash of 0xDEADBEEF'' -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret votes HOWTO
On Sat, Mar 31, 2001 at 02:29:41PM -0800, Seth Arnold wrote: > > The idea I like the most so far is the 'user-supplied random nonce' > idea. I like this idea because using a collection of other data is > liable to failure because stupid email systems manage to molest email > in the strangest fashion: "From " to ">From ", etc. user-supplied random data plus system-generated random data would probably be required, to prevent collision between Alice and Bob both supplying the same random data. -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Debian Project Leader Chosen
On Thu, Mar 29, 2001 at 10:16:16PM -0800, John H. Robinson, IV wrote: > On Thu, Mar 29, 2001 at 10:40:56PM -0500, Rob Mahurin wrote: > > Only the fool would take trouble to verify that his sentence was > > composed of ten a's, three b's, four c's, four d's, forty-six e's, > > sixteen f's, four g's, thirteen h's, fifteen i's, two k's, nine l's, > > four m's, twenty-five n's, twenty-four o's, five p's, sixteen r's, > > forty-one s's, thirty-seven t's, ten u's, eight v's, eight w's, four > > x's, eleven y's, twenty-seven commas, twenty-three apostrophes, seven > > hyphens, and last but not least, a single ! > > -- Lee Sallows, quoted in Hofstadter's > > _Metamagical Themas_ > > i only count twenty-three o's can i take this back now? it seems i failed to count O as an o :( -john
Re: New Debian Project Leader Chosen
On Thu, Mar 29, 2001 at 10:40:56PM -0500, Rob Mahurin wrote:
> Only the fool would take trouble to verify that his sentence was
> composed of ten a's, three b's, four c's, four d's, forty-six e's,
> sixteen f's, four g's, thirteen h's, fifteen i's, two k's, nine l's,
> four m's, twenty-five n's, twenty-four o's, five p's, sixteen r's,
> forty-one s's, thirty-seven t's, ten u's, eight v's, eight w's, four
> x's, eleven y's, twenty-seven commas, twenty-three apostrophes, seven
> hyphens, and last but not least, a single !
> -- Lee Sallows, quoted in Hofstadter's
> _Metamagical Themas_
i only count twenty-three o's
% for i in {a-z} , \' \\- \!; do echo -n $i:; echo $sentence | tr -cd "[^$i]" |
wc -c ; done
o: 23
-john
Re: New Debian Project Leader Chosen
On Thu, Mar 29, 2001 at 10:16:16PM -0800, John H. Robinson, IV wrote: > On Thu, Mar 29, 2001 at 10:40:56PM -0500, Rob Mahurin wrote: > > Only the fool would take trouble to verify that his sentence was > > composed of ten a's, three b's, four c's, four d's, forty-six e's, > > sixteen f's, four g's, thirteen h's, fifteen i's, two k's, nine l's, > > four m's, twenty-five n's, twenty-four o's, five p's, sixteen r's, > > forty-one s's, thirty-seven t's, ten u's, eight v's, eight w's, four > > x's, eleven y's, twenty-seven commas, twenty-three apostrophes, seven > > hyphens, and last but not least, a single ! > > -- Lee Sallows, quoted in Hofstadter's > > _Metamagical Themas_ > > i only count twenty-three o's can i take this back now? it seems i failed to count O as an o :( -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Debian Project Leader Chosen
On Thu, Mar 29, 2001 at 10:40:56PM -0500, Rob Mahurin wrote:
> Only the fool would take trouble to verify that his sentence was
> composed of ten a's, three b's, four c's, four d's, forty-six e's,
> sixteen f's, four g's, thirteen h's, fifteen i's, two k's, nine l's,
> four m's, twenty-five n's, twenty-four o's, five p's, sixteen r's,
> forty-one s's, thirty-seven t's, ten u's, eight v's, eight w's, four
> x's, eleven y's, twenty-seven commas, twenty-three apostrophes, seven
> hyphens, and last but not least, a single !
> -- Lee Sallows, quoted in Hofstadter's
> _Metamagical Themas_
i only count twenty-three o's
% for i in {a-z} , \' \\- \!; do echo -n $i:; echo $sentence | tr -cd "[^$i]" | wc -c
; done
o: 23
-john
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vote Tallied
On Wed, Mar 21, 2001 at 12:20:32AM -0500, Branden Robinson wrote: > On Wed, Mar 21, 2001 at 02:58:57PM +1000, Anthony Towns wrote: > > I didn't receive a second confirmation; > > Me neither, and I have not re-voted. what branden said -john
Re: Vote Tallied
On Wed, Mar 21, 2001 at 12:20:32AM -0500, Branden Robinson wrote: > On Wed, Mar 21, 2001 at 02:58:57PM +1000, Anthony Towns wrote: > > I didn't receive a second confirmation; > > Me neither, and I have not re-voted. what branden said -john -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some questions for the DPL candidates
On Fri, Mar 09, 2001 at 08:41:30PM +1100, Craig Sanders wrote:
>
> what is it about "do you intend to take any action?" that is too complex
> for a yes/no answer?
i think the wording of the question is bad.
two possible alternates:
1) do you support the removal of non-free?
to determine the candidate's stance on the issue
-or-
2) will you attempt to get the issue finally resolved during your term?
to determine the canditate's willingness to take action
let's say i support the keeping of non-free, but i, as DPL, bring it up for a
general vote. if the vote went ``remove non-free'', then i would have
had taken action to remove non-free. i would be able to answer the first
question with a ``no'' but the second question with a ``yes.''
> it's a really simple and straight forward question. either there is an
> intention to take action ("yes"), or there is not ("no").
--- craing sanders wrote ---
Message-ID: <[EMAIL PROTECTED]>
do you intend to take any action to have non-free removed from the
debian archives? (this is a yes or no question, but feel free to make
comments after answering yes or no).
--- end quote ---
if i say yes, then i support the removal of non-free.
if i say no, then i wish to avoid this hot-topic altogether.
this is a ``have you stopped [insert really bad thing] yet?'' question
after all.
> normal politicians give me the shits, which is *precisely* why i want a
> clear and direct answer to the question.
i agree with this sentiment, however your question did force the
candidate into the position of waffling.
-john
Re: Some questions for the DPL candidates
On Fri, Mar 09, 2001 at 08:41:30PM +1100, Craig Sanders wrote:
>
> what is it about "do you intend to take any action?" that is too complex
> for a yes/no answer?
i think the wording of the question is bad.
two possible alternates:
1) do you support the removal of non-free?
to determine the candidate's stance on the issue
-or-
2) will you attempt to get the issue finally resolved during your term?
to determine the canditate's willingness to take action
let's say i support the keeping of non-free, but i, as DPL, bring it up for a
general vote. if the vote went ``remove non-free'', then i would have
had taken action to remove non-free. i would be able to answer the first
question with a ``no'' but the second question with a ``yes.''
> it's a really simple and straight forward question. either there is an
> intention to take action ("yes"), or there is not ("no").
--- craing sanders wrote ---
Message-ID: <[EMAIL PROTECTED]>
do you intend to take any action to have non-free removed from the
debian archives? (this is a yes or no question, but feel free to make
comments after answering yes or no).
--- end quote ---
if i say yes, then i support the removal of non-free.
if i say no, then i wish to avoid this hot-topic altogether.
this is a ``have you stopped [insert really bad thing] yet?'' question
after all.
> normal politicians give me the shits, which is *precisely* why i want a
> clear and direct answer to the question.
i agree with this sentiment, however your question did force the
candidate into the position of waffling.
-john
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
