[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 Mon, 17 May 2004 00:02:26 -0400, Duncan Findlay <duncf@debian.org> said:

> On Sun, May 16, 2004 at 10:38:32PM -0500, Manoj Srivastava wrote:
>> On Sun, 16 May 2004 22:42:07 -0400, Duncan Findlay
>> <duncf@debian.org> said:

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

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

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

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

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

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

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

>> > 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   <srivasta@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



Reply to: