Re: Proposed ballot for the GR: Deciding on the effect of GR 2004_003
On Sun, 16 May 2004 22:09:01 +0200, Wouter Verhelst <email@example.com> said:
> On Sun, May 16, 2004 at 10:27:49AM -0500, Manoj Srivastava wrote:
>> On 15 May 2004 21:11:02 +0100, Henning Makholm
>> <firstname.lastname@example.org> 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?
> 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
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@example.com> <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