On Sun, 16 May 2004 22:09:01 +0200, Wouter Verhelst <[EMAIL PROTECTED]> said:
> On Sun, May 16, 2004 at 10:27:49AM -0500, Manoj Srivastava wrote: >> On 15 May 2004 21:11:02 +0100, Henning Makholm >> <[EMAIL PROTECTED]> said: >> > The full texts of the proposals being voted on can be found on >> > http://www.debian.org/vote/2004/vote_004 >> >> > They have been been omitted here due to their (combined) >> > length. Please go to the above URL and read the actual >> > proposals before voting. >> >> Why do developers have to be told this? > Let me turn the question around. Is there any harm in doing this? Perhaps. > Apart from that, yes, I think developers have to be told. Their > curiosity has to be tickled, to avoid that people who aren't really > interested just say "oh, postponing doesn't sound really good, > because I want to release now. Let's not postpone." Having more The point of this exercise is not to count as many uninformed hands as possible. The point is to get a measure of a reasoned decision from an informed electorate -- I can use srand to generate random votes quite easily. An informed electorate -- now that takes a modicum of due diligence on the part of the person casting the vote. It is not as if the information is hidden: the vote pages are out there in the open, and there shall be ballots that remind people where to go to. > information is a good thing; and while I could understand reasoning > for not wanting the full rationales in this mail, I second that the > ballot should either contain those full rationales, or verbosely say > it doesn't. I am not sure I want the input from people who can't immediately determine that the actual contents of the GR were not on the ballot. Debian is not about mindless participation; we are trying, after all, to create the best possible distribution; and GR's represent the most significant collective decisions we make as a body. I am not sure that spoon feeding people and coaxing them, like pup[pies, tocome to the polling station is the best thing to do. manoj -- Glib's Fourth Law of Unreliability: Investment in reliability will increase until it exceeds the probable cost of errors, or until someone insists on getting some useful work done. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]