[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed ballot for the GR: Deciding on the effect of GR 2004_003



On Sun, May 16, 2004 at 06:03:34PM -0500, Manoj Srivastava wrote:
> On Sun, 16 May 2004 22:09:01 +0200, Wouter Verhelst <wouter@grep.be> said: 
> 
> > On Sun, May 16, 2004 at 10:27:49AM -0500, Manoj Srivastava wrote:
> >> On 15 May 2004 21:11:02 +0100, Henning Makholm
> >> <henning@makholm.net> 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?

In theory, they don't. In theory, the options on the ballot are
self-explanatory, and developers should know where to find more
information. However, in practice, it is clear that developers often
don't take care to inform themselves adequately before voting (how do
you think we got in this mess in the first place?)

> > Let me turn the question around. Is there any harm in doing this?
> 
> 	Perhaps.

Excuse me. What??!!?!??

There is harm in reminding developers how to inform themselves before
voting??? You claim to want an "informed electorate" yet you object to
making it more obvious how to inform themselves?

> > 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.

So, what you are saying is that in order to have more informed votes,
we should make it less clear to voters how to become informed. That's
nonsense. Instead of getting more informed voters, you will get more
people voting based on the one line summaries listed.

Furthermore, this may be a bias against new developers who are a
little unfamiliar with the way votes work. Are you trying to say that
their opinion is irrelevant? That they shouldn't get a vote?

> > 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. 

As project Secretary, you are obliged to take into account the will of
_all_ Debian developers, regardless of how competent *you* feel they
are. In my eyes, statements like this undermine your suitability to be
Secretary.

It certainly isn't unlikely that a (fully competent) developer, a
little pressed for time, misses the link and votes based on the
summaries rather than the full proposals. Deliberately making the link
less visible is similar to an attempt to mislead voters into thinking
they are voting for something different than they really are. (Sound
familiar anyone?)

-- 
Duncan Findlay

Attachment: signature.asc
Description: Digital signature


Reply to: