Discussion:
Proposed ballot for the GR: Deciding on the effect of GR 2004_003
(too old to reply)
Manoj Srivastava
2004-05-14 19:40:33 UTC
Permalink
Hi,

This is a draft.

manoj


Voting starts on
Votes must be received by

The following ballot is for voting on a General Resolution to address
the effect of the previous general resolution, titled "Editorial
changes to the Social Contract", on the release schedule of Sarge.
The vote is being conducted in accordance with the policy delineated
in Section A, Standard Resolution Procedure, of the Debian
Constitution.

The details of the general resolution can be found at:
http://www.debian.org/vote/2004/vote_004

HOW TO VOTE

Do not erase anything between the lines below and do not change the
choice names.

In the brackets next to your most preferred choice, place a 1. Place a
2 in the brackets next to your next most preferred choice. Do not
enter a number smaller than 1 or larger than 6. You may rank options
equally (as long as all choices X you make fall in the range 1<= X <= 6).

To vote "no, no matter what" rank "Further Discussion" as more
desirable than the unacceptable choices, or you may rank the "Further
Discussion" choice, and leave choices you consider unacceptable
blank. Unranked choices are considered equally least desired choices,
and ranked below all ranked choices. (Note: if the "Further
Discussion" choice is unranked, then it is equal to all other unranked
choices, if any -- no special consideration is given to the "Further
Discussion" choice by the voting software).

Then mail the ballot to ***@vote.debian.org.
Don't worry about spacing of the columns or any quote characters (">")
that your reply inserts. NOTE: The vote must be GPG signed (or PGP
signed) with your key that is in the Debian keyring. Do _NOT_ encrypt
your ballot; the voting mechanism shall not be able to decrypt your
message.

-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
[ ] Choice 1: Postpone changes until September 2004 [needs 3:1]
[ ] Choice 2: Postpone changes until Sarge releases [needs 3:1]
[ ] Choice 3: Add apology to Social Contract [needs 3:1]
[ ] Choice 4: Revert to old wording of SC [needs 3:1]
[ ] Choice 5: "Transition Guide" foundation document [needs 3:1]
[ ] Choice 6: Further discussion
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
----------------------------------------------------------------------
The responses to a valid vote shall be signed by the vote key created
for this vote. The public key for the vote, signed by the Project
secretary, is appended below.
----------------------------------------------------------------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.4 (GNU/Linux)

mQGiBEClGZsRBAD2BRBPIafw4N5Fc/hyuzAiFio6wc2mqqx/dV7+r3r04nMVAOw2
lOPD/N2HZu3d3MTY7f/9OHgN2fszagN5vOX7g6dvzHnr0xcir6pNSFWebZ68+EnI
6fjhzMFNaHN+LCcRmnAxhRF/R+5lvTREJ1OolMvduHzJoSsFAnO9WTTOawCg44mb
U5OadGp78r/TjNPpz6yn+V0D+gNJ1d4mAlHdw3r8U+Rxj0INc6tF1VETpGHrpKjJ
7bTT3ZqK6z9S1qGdQcG3ekWjgpZBRDeEocLFuTOpxGq4LrowP8g5CDlk9imiptAo
3Lw2xVWB1ftGVyjl1wbQCCY5699Ssz8xcqIktCNrF1VyIPepiJVu/Wk8tUFNTkw7
MaXPBACPcoc9PbEUIpDlarpqthN1IOZVoEa0dA5cQorqI+mxVnszpBezNAbEz3So
3GTkgEBZrXYaGeTJdz6DJGsKP3q/Oc14wH1Toc51vSpmyEt90Ug4iRYmOIrWIo5t
bUDRiw8oBrf12sznU64+66tZta9YCM++znKiZOAg8AzmXLrUDbYAAAA8R1IgU2Fy
Z2UgVm90ZSBrZXkgKFRlbXBvcmFyeSBrZXkpIDxncl9zYXJnZUB2b3RlLmRlYmlh
bi5vcmc+iGQEExECACQFAkClGZsCGwMFCQBPGgAGCwkIBwMCAxUCAwMWAgECHgEC
F4AACgkQVxAJuhvkDPnO4QCgvWYsbtIAn7FLlZV3uy8CEG5z038AniJG5vMUrTNg
UfRwJ1Qb+lahxWr9iEwEEBECAAwFAkClGgkFgwBPGZIACgkQIbrau78kQkz49wCf
X8sJl3iiJ6BhQJw+zDtZSD06R5AAnRFtQgYxtGdtpiuAmOHtn7IhC1y7uQENBECl
GZ0QBACAFHQcsufyE9q7sn1e+xf5GDjYhRCyNkC/o4YS4/FzcPiPuC5Z2Xq9dvya
FLWLyX6hOsRGnclVRniC2pj+S6J7guE9Yn6tMFxDkv1KnZQtA+YkorXa40vAmTGQ
JxPB4IYUz6mH0jynoDFoFf0keANz2ypgogzdQLQRkoNpDhhDUwADBgP+MO4c5B3U
15m+3svQtbYr4bNywsDY5zO/WpOzhux/Fbe8vwYgznH5eKHusaGc0MHduhkK+Zih
H+e0EsmpuRytMuNulBl+0YQ0H1lSK/U7BMFgmWe/Kyih8WUOEK3/GpWOKsjPAWGn
et2iZj0+5SAA2P7/RVTt8pc+NQ96ZeMf/SKITwQYEQIADwUCQKUZnQIbDAUJAE8a
AAAKCRBXEAm6G+QM+aLsAKCzDucqbvvDxs7YbWv+CB4CGbkYcQCgpQnHY//7xrwC
5Bttf62SqJzXlT0=
=xRmW
-----END PGP PUBLIC KEY BLOCK-----
--
"If I didn't have a Unix machine, I'd feel naked." Guess Who
Manoj Srivastava <***@debian.org> <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
Osamu Aoki
2004-05-14 23:27:13 UTC
Permalink
Post by Manoj Srivastava
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
[ ] Choice 1: Postpone changes until September 2004 [needs 3:1]
[ ] Choice 2: Postpone changes until Sarge releases [needs 3:1]
[ ] Choice 3: Add apology to Social Contract [needs 3:1]
[ ] Choice 4: Revert to old wording of SC [needs 3:1]
[ ] Choice 5: "Transition Guide" foundation document [needs 3:1]
[ ] Choice 6: Further discussion
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
Is there any reason why choices are indexed as 1,2,3,... while the
proposal themselves are always indexed as A,B,C,... on vote.debian.org.

Just curious and somewhat confused.

Osamu
Henning Makholm
2004-05-15 19:52:57 UTC
Permalink
Post by Osamu Aoki
Is there any reason why choices are indexed as 1,2,3,... while the
proposal themselves are always indexed as A,B,C,... on vote.debian.org.
It turned out that the vote-tallying software has a hard-coded
assumption that the options are identified by numbers. Easier and less
risky to change the ballot than the software.

I see that the overview on vote.debian.org now does say "(choice N on
the ballot)" in the heading for each specific proposal text. I think
it would be clearer if the entire A/B/C/D/E nomenclature had been
replaced by numbers. But it's a minor point.
--
Henning Makholm "Jeg kunne ikke undgå at bemærke at han gik på hænder."
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Manoj Srivastava
2004-05-16 15:25:34 UTC
Permalink
Post by Osamu Aoki
Is there any reason why choices are indexed as 1,2,3,... while the
proposal themselves are always indexed as A,B,C,... on
vote.debian.org.
Just curious and somewhat confused.
Apart from the fact that devotee kinda wants the choices to
be numerical, there is also merit in decoupling the order on the web
page to the order on the ballot (in the past, we have randomized
ballots for impartiality).

Since my draft does not change the order, this should not be
an issue, neh?

manoj
--
He who laughs has not yet heard the bad news. Bertolt Brecht
Manoj Srivastava <***@debian.org> <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
Osamu Aoki
2004-05-16 17:19:50 UTC
Permalink
Post by Manoj Srivastava
Post by Osamu Aoki
Is there any reason why choices are indexed as 1,2,3,... while the
proposal themselves are always indexed as A,B,C,... on
vote.debian.org.
Just curious and somewhat confused.
Apart from the fact that devotee kinda wants the choices to
be numerical, there is also merit in decoupling the order on the web
page to the order on the ballot (in the past, we have randomized
ballots for impartiality).
Since my draft does not change the order, this should not be
an issue, neh?
Not a problem for me.

(Henning answered my curiosity. Thanks.)
Henning Makholm
2004-05-15 20:11:02 UTC
Permalink
Post by Manoj Srivastava
http://www.debian.org/vote/2004/vote_004
I think this reference is too weak. The link should jump out and bite
any hypothetical reader who has been vacationing on a desert island
for the last month. How about:

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.
Post by Manoj Srivastava
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
[ ] Choice 1: Postpone changes until September 2004 [needs 3:1]
[ ] Choice 2: Postpone changes until Sarge releases [needs 3:1]
[ ] Choice 3: Add apology to Social Contract [needs 3:1]
[ ] Choice 4: Revert to old wording of SC [needs 3:1]
[ ] Choice 5: "Transition Guide" foundation document [needs 3:1]
[ ] Choice 6: Further discussion
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
I'm tempted to propose guarding these lines with a torrent of
disclaimers saying that the descriptions are not attempts to describe
the full impact of each option, but in reality this will probably be
evident to any reader who genuinely does not know what this is about
("Postpone changes? Which changes?").
--
Henning Makholm "We will discuss your youth another time."
--
To UNSUBSCRIBE, email to debian-vote-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Manoj Srivastava
2004-05-16 15:27:49 UTC
Permalink
Post by Henning Makholm
Post by Manoj Srivastava
http://www.debian.org/vote/2004/vote_004
I think this reference is too weak. The link should jump out and
bite any hypothetical reader who has been vacationing on a desert
Any such DD should be actively looking to educate themselves
before exercising their franchise.
Post by Henning Makholm
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?

manoj
--
While I nodded, nearly napping, suddenly there came a tapping, As of
some one gently rapping, rapping at my chamber door. Edgar Allan Poe,
"The Raven" [Quoted in "VMS Internals and Data Structures", V4.4, when
referring to hardware interrupts.] And now I see with eye serene The
very pulse of the machine. William Wordsworth, "She Was a Phantom of
Delight" [Quoted in "VMS Internals and Data Structures", V4.4, when
referring to software interrupts.]
Manoj Srivastava <***@debian.org> <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
Graham Wilson
2004-05-16 18:22:20 UTC
Permalink
Post by Manoj Srivastava
Post by Henning Makholm
Post by Manoj Srivastava
http://www.debian.org/vote/2004/vote_004
I think this reference is too weak. The link should jump out and
bite any hypothetical reader who has been vacationing on a desert
Any such DD should be actively looking to educate themselves
before exercising their franchise.
True. However, is there any problem with trying to make this stand out?
Post by Manoj Srivastava
Post by Henning Makholm
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?
Again, is there any problem making this verbose?
--
gram
Manoj Srivastava
2004-05-16 22:58:07 UTC
Permalink
Post by Graham Wilson
On 15 May 2004 21:11:02 +0100, Henning Makholm
Post by Henning Makholm
Post by Manoj Srivastava
http://www.debian.org/vote/2004/vote_004
I think this reference is too weak. The link should jump out and
bite any hypothetical reader who has been vacationing on a desert
Any such DD should be actively looking to educate themselves before
exercising their franchise.
True. However, is there any problem with trying to make this stand out?
Seems like it already stands out: anyone paying the least bit
of attention shall otice that there are no details in the ballot, and
this URL is the only thing that points to where one may get more
information.

manoj
--
The best that we can do is to be kindly and helpful toward our friends
and fellow passengers who are clinging to the same speck of dirt while
we are drifting side by side to our common doom. Clarence Darrow
Manoj Srivastava <***@debian.org> <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
Wouter Verhelst
2004-05-16 20:09:01 UTC
Permalink
Post by Manoj Srivastava
Post by Henning Makholm
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 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.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Manoj Srivastava
2004-05-16 23:03:34 UTC
Permalink
Post by Wouter Verhelst
On 15 May 2004 21:11:02 +0100, Henning Makholm
Post by Henning Makholm
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.
Post by Wouter Verhelst
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.
Post by Wouter Verhelst
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 <***@debian.org> <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
Graham Wilson
2004-05-17 00:59:48 UTC
Permalink
Post by Manoj Srivastava
Post by Wouter Verhelst
On 15 May 2004 21:11:02 +0100, Henning Makholm
Post by Henning Makholm
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.
Perhaps there is harm in noting that the full text of the proposals have
been left out, and is available on the web?

What harm is that?
--
gram
Manoj Srivastava
2004-05-17 03:32:50 UTC
Permalink
Post by Graham Wilson
On Sun, 16 May 2004 22:09:01 +0200, Wouter Verhelst
Post by Wouter Verhelst
On 15 May 2004 21:11:02 +0100, Henning Makholm
Post by Henning Makholm
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.
Perhaps there is harm in noting that the full text of the proposals
have been left out, and is available on the web?
What harm is that?
It is belabouring the obvious. How can anyone think that 40
characters is the full text of the proposal?

And are there really debian developers who do not understand
this?
======================================================================
The details of the general resolution can be found at:
http://www.debian.org/vote/2004/vote_004
======================================================================

manoj
--
"The things to do are: the things that need doing: that /you/ see need
to be done, and that no one else seems to see need to be done. Then
you will conceive your own way of doing that which needs to be done --
that no one else has told you to do or how to do it. This will bring
out the real you that often gets buried inside a character that has
acquired a superficial array of behaviors induced or imposed by others
on the individual." --- R. Buckminster Fuller
Manoj Srivastava <***@debian.org> <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
Michael Banck
2004-05-17 07:56:52 UTC
Permalink
Post by Manoj Srivastava
It is belabouring the obvious. How can anyone think that 40
characters is the full text of the proposal?
And are there really debian developers who do not understand
this?
Yeah, let's just try it out. Three's a charm anyway, right?


Michael
--
Michael Banck
Debian Developer
***@debian.org
http://www.advogato.org/person/mbanck/diary.html
Manoj Srivastava
2004-05-19 20:27:06 UTC
Permalink
Post by Michael Banck
Post by Manoj Srivastava
It is belabouring the obvious. How can anyone think that 40
characters is the full text of the proposal?
And are there really debian developers who do not understand this?
Yeah, let's just try it out. Three's a charm anyway, right?
Oh, I think at some point people would be ashamed of their
lack of due diligence, and stop making everyone else work harder to
redo their own lack of a modicum of effort to educate themselves on
issues that rate a GR. On the other hand, I may be massively
underestimating the gall.

manoj
--
The IBM purchase of ROLM gives new meaning to the term "twisted
pair". Howard Anderson, "Yankee Group"
Manoj Srivastava <***@debian.org> <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
Duncan Findlay
2004-05-17 02:42:07 UTC
Permalink
Post by Manoj Srivastava
Post by Wouter Verhelst
On 15 May 2004 21:11:02 +0100, Henning Makholm
Post by Henning Makholm
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?)
Post by Manoj Srivastava
Post by Wouter Verhelst
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?
Post by Manoj Srivastava
Post by Wouter Verhelst
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?
Post by Manoj Srivastava
Post by Wouter Verhelst
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
Manoj Srivastava
2004-05-17 03:38:32 UTC
Permalink
Post by Duncan Findlay
On Sun, 16 May 2004 22:09:01 +0200, Wouter Verhelst
Post by Wouter Verhelst
On 15 May 2004 21:11:02 +0100, Henning Makholm
Post by Henning Makholm
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?)
Post by Wouter Verhelst
Let me turn the question around. Is there any harm in doing this?
Perhaps.
Excuse me. What??!!?!??
I see. Perhaps you can't read -- which kinda explains your
view point.
Post by Duncan Findlay
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?
Shall I tell them to breathe in, breathe out, too? Or to
make sure they eat? Or remind them they should generally sleep,
perhaps once every 24 hours as well?
Post by Duncan Findlay
Post by Wouter Verhelst
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.
If there are people who find this less clear:
======================================================================
The details of the general resolution can be found at:
http://www.debian.org/vote/2004/vote_004
======================================================================
Perhaps they should consider resigning.
Post by Duncan Findlay
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?
If they are not competent enough to follow the instructions
above, hell yes.
Post by Duncan Findlay
Post by Wouter Verhelst
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.
Bullshit. I am obligated to follow the constitution, and
decide, as do all developers, what is best for the
project. Pampering people who do not take time to do due diligence
before voting is not something I plan on doing.
Post by Duncan Findlay
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
What fucking summaries? You really think that a 40 char title
is a bloody summary of a GR proposal? And you would vote on
something compressed into 40 chars? The mind boggles.
Post by Duncan Findlay
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?)
Yes. Sounds like we are getting a lot of incompetent. lazy
people itching to blame everyone else for their lack of due
diligence.

manoj
--
You need more time; and you probably always will.
Manoj Srivastava <***@debian.org> <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
Duncan Findlay
2004-05-17 04:02:26 UTC
Permalink
Post by Manoj Srivastava
Post by Duncan Findlay
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?
Shall I tell them to breathe in, breathe out, too? Or to
make sure they eat? Or remind them they should generally sleep,
perhaps once every 24 hours as well?
That's outside your portfolio as Secretary.
Post by Manoj Srivastava
======================================================================
http://www.debian.org/vote/2004/vote_004
======================================================================
Perhaps they should consider resigning.
Even if you add the ===='s, it stands out a lot more and is easier to
notice when skimming through the otherwise boilerplate ballot. I don't
see any reason to not implement Henning's suggestions. Sure, it is (or
at least should be?) a little unnecessary, but it's not going to hurt.
Post by Manoj Srivastava
Post by Duncan Findlay
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?
If they are not competent enough to follow the instructions
above, hell yes.
Do you read every word in everything ever put in front of you? Most of
the ballot is pretty standard, so people are likely to skip over
it. Making the link a little more obvious is a good thing.
Post by Manoj Srivastava
Bullshit. I am obligated to follow the constitution, and
decide, as do all developers, what is best for the
project. Pampering people who do not take time to do due diligence
before voting is not something I plan on doing.
Nobody said anything about pampering. We're talking about making a
link a little more obvious. How could that possibly be a bad thing?
Post by Manoj Srivastava
What fucking summaries? You really think that a 40 char title
is a bloody summary of a GR proposal? And you would vote on
something compressed into 40 chars? The mind boggles.
Personally, I wouldn't vote on a 40 character summary. But some might
find the titles sufficiently self-explanatory. I don't see how
encouraging people to read the full summaries is a bad thing.
Post by Manoj Srivastava
Post by Duncan Findlay
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?)
Yes. Sounds like we are getting a lot of incompetent. lazy
people itching to blame everyone else for their lack of due
diligence.
Please, just make the link a little clearer and more obvious. Is that
really too much to ask? I assume by sending out a draft, you were
asking for suggestions on how to improve it (an incorrect
assumption?). People have responded, and you have proceeded to jump
all over these suggestions.
--
Duncan Findlay
Manoj Srivastava
2004-05-17 04:20:57 UTC
Permalink
Post by Duncan Findlay
On Sun, 16 May 2004 22:42:07 -0400, Duncan Findlay
======================================================================
http://www.debian.org/vote/2004/vote_004
======================================================================
Perhaps they should consider resigning.
Even if you add the ===='s, it stands out a lot more and is easier
to notice when skimming through the otherwise boilerplate ballot.
That seems reasonable.
Post by Duncan Findlay
don't see any reason to not implement Henning's suggestions. Sure,
it is (or at least should be?) a little unnecessary, but it's not
going to hurt.
The point is that you can't ever please every possible
person. And there comes a time when the nit picking gets
silly, as I think it has, in this case.
Post by Duncan Findlay
Post by Duncan Findlay
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?
If they are not competent enough to follow the instructions above,
hell yes.
Do you read every word in everything ever put in front of you? Most
When it comes to a GR, yes. Note to the public: GR's are big
deals. These are the most significant decisions that the developer
community takes as a whole, and these can fundamentally change the
very nature of the project.

GR's that modify Foundation documents are even more
critical; and you should not be skimming through the ballot.
Post by Duncan Findlay
of the ballot is pretty standard, so people are likely to skip over
it. Making the link a little more obvious is a good thing.
And then they realize that they do not know what the ballot
is all about, so they go back and read it. Really.
Post by Duncan Findlay
Nobody said anything about pampering. We're talking about making a
link a little more obvious. How could that possibly be a bad thing?
Cause there will always be someone out there who wants a
little bit more. A little more obvious. A little more spoon
feeding. And when he material being spoon fed is not obvious enough,
they have the gall to come back and call it "deceptive practice" and
"delibratelyt misleading".
Post by Duncan Findlay
What fucking summaries? You really think that a 40 char title is a
bloody summary of a GR proposal? And you would vote on something
compressed into 40 chars? The mind boggles.
Personally, I wouldn't vote on a 40 character summary. But some
might find the titles sufficiently self-explanatory. I don't see how
encouraging people to read the full summaries is a bad thing.
I would rather trust in the sensibility of the developer
body. You say you won't vote on a 40 char title, but you think so
little of your fellow developers to believe they shall?
Post by Duncan Findlay
Post by Duncan Findlay
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?)
Yes. Sounds like we are getting a lot of incompetent. lazy people
itching to blame everyone else for their lack of due diligence.
Please, just make the link a little clearer and more obvious. Is
that really too much to ask? I assume by sending out a draft, you
were asking for suggestions on how to improve it (an incorrect
assumption?). People have responded, and you have proceeded to jump
all over these suggestions.
I listen to suggestion. I do not follow everyone. Adding gobs
and gobs of disclaimers about the obvious is not, in my opinion, a
reasonable suggestion.

I may add a line of '='s around it, though. That did sound
reasonable.

manoj
--
Once the toothpaste is out of the tube, it's hard to get it back
in. H.R. Haldeman
Manoj Srivastava <***@debian.org> <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
Manoj Srivastava
2004-05-17 04:00:57 UTC
Permalink
Hi folks,

I think, (in a cooler vien), that one can't please
everyone. I have looked at the issues raised, and it is my considered
opinion that combined with the fact that the ballot only contains 40
char titles for each proposal, and has the following lines:
======================================================================
The details of the general resolution can be found at:
http://www.debian.org/vote/2004/vote_004
======================================================================
it should be clear to any reasonable voter where information about
the GR can be found.

The vote page not only contains the text of the proposals, it
also links in to ancilliary and supporting documents, and I think
that this deep linking is important when considering the merits of
each of the proposals. It would be difficult, if not impossible, to
include that rich set of additional information on the ballot, so I
have decided not to do a half hearted job.


manoj
--
Sic transit discus mundi From the System Administrator's Guide, by
Lars Wirzenius
Manoj Srivastava <***@debian.org> <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
Andrew Suffield
2004-05-17 14:02:10 UTC
Permalink
Post by Duncan Findlay
Post by Manoj Srivastava
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?)
I think we got into this "mess" because of a sudden and unanticipated
bout of morality on the part of the release manager. I think that
responding to a result you didn't like with anything that reduces to
"Oh, they didn't really *mean* that" rather speaks for itself.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Anthony Towns
2004-05-19 02:28:05 UTC
Permalink
Post by Andrew Suffield
I think we got into this "mess" because of a sudden and unanticipated
bout of morality on the part of the release manager.
Andrew, go fuck yourself.

If you want to say that I've been acting immorally up until last month,
have the guts to say it outright, rather than snide little remarks like
the above.

Regards,
aj
--
Anthony Towns <***@humbug.org.au> <http://azure.humbug.org.au/~aj/>
Don't assume I speak for anyone but myself. GPG signed mail preferred.

``Like the ski resort of girls looking for husbands and husbands looking
for girls, the situation is not as symmetrical as it might seem.''
Loading...