Re: Constitution - formal proposal (v0.5.1)
Shaleh writes ("Re: Constitution - formal proposal (v0.5)"):
> This is mostly a grammatical post but other stuff as well.
>
> 1. Introduction --> "who have made common cause", this reads odd.
Not to me.
> 2.1 point 1 "A person who does not want to do perform a task", the do
> seems superfluous
Fixed.
> 3.1 Powers seems to allow a developer to ignore Debian policy
Yes. If they decide to ignore policy then the Technical Committee can
overrule them (3:1 majority) saying `you must implement it like this',
or if someone else wants to maintain the package they can do so and
the Technical Committee can decide that the new maintainer's one
should be used instead.
> It seems that the Leader can prevent people from joining the technical
> commitee and thus allow only people who are in his "camp" a voice there
No - or at least, only when the Technical Committee is only one or two
people short. After that the Technical Committee can appoint people.
Remember also that the Project Leader's decision to appoint or not a
member of the Technical Committee is subject to review by the
developers.
> 8.1 point 2 what does vetting mean???
It now says `approve'.
> And it has been mentioned before but.... When you say a 2:1 majority
> are we speaking of ALL developers and those able to vote or just those
> who voted? Or is the default a NULL vote, and this is changed as people
> vote??
See s.A.5(7), rationale text.
Dale Scheetz writes ("Re: Constitution - formal proposal (v0.5)"):
> On 2 Apr 1998, James LewisMoss wrote:
...
> > Actually assuming we are 2:1 Yes to No. Then after 134 yes votes we
> > know yes has won. After 67 no votes we know no has won. At this
> > point there is no need to take more votes. This, I believe, is what
> > is meant by 'no longer in question'.
>
> Note that this definition is more accurate than my rendition (making the
> distinction between the number of yes votes and the number of no votes
> required for "no longer in question)
>
> I think that this is another point in favor of making this clear in the
> document.
I've now stated that the `no longer in doubt' rule doesn't consider
the possibility that voters may change their votes.
Dale Scheetz writes ("Re: Constitution - formal proposal (v0.5)"):
...
> It wouldn't matter if the delegate only has one decision to make and then
> go away.
>
> People who now exercise delegated authority over areas of the project
> include Brian W. (Release Director), myself as testing coordinator, and
> many others too numerous to mention here.
>
> It was my assumtion that this clause was inserted to protect folks like
> Brian (or myself) being ejected in a fit of pique by the Project Director
> over a valid decision made by the delegate.
Indeed. Does the current wording not seem appropriate and clear ?
I'm open to suggested improvements.
Oliver Elphick writes ("Re: Constitution - formal proposal (v0.5) "):
...
> Q will very rarely be an integer; how should it be rounded? This will make
> a difference of 3 to the quorum - better to decide before it arises in
> practice.
I've now stated that Q and K are not rounded.
...
> If it is possible to change your vote, there is no need to keep the tallies
> secret, since the same information is available to all voters. If there
> is an extended voting period of a mximum of 3 weeks, it is highly likely
> that further argument may lead people to want to change their vote; this
> constitution does not explicitly permit a change of vote.
>
> The balance of the voting may tell the proponent of a losing argument
> that he needs to improve his argument or presentation. I would rather see
> public tallies with a fixed cut-off date.
No, this is not a good idea. It leads to highly unstable situations
where people's voting behaviour depends more on how the vote is going
than on the issues at hand.
For example, if you think that your opponents might fail to vote
because the outcome is safe it is advantageous to vote as close to the
deadline as possible, so as to reduce the probability that your
vote(s) will induce opposing vote(s).
I can't think offhand of anyone who uses a voting system where partial
results are known during the voting period, no doubt for this reason.
...
> > The Project Leader may:...
> > 2. Lend authority to other developers.
> > The Project Leader may make statements of support for points of
> > view or for other members of the project, when asked or otherwise;
> > these statements have force if and only if the Leader would be
> > empowered to make the decision in question.
>
> What does this actually mean? Does the Leader's statement have the
> effect of making the decision?
No, `... have force if and only if ...'.
Oliver Elphick writes ("Re: Constitution - formal proposal (v0.5) "):
...
> I don't think it reasonable to stop people from changing their votes
> because you disapprove of their being hasty. Some people are impulsive
> by nature; this is a handicap in some cases, an advantage in others.
> Allowing a change is a way of mitigating the consequences of
> impulsiveness. You should remember that there could be other reasons
> for changing: people might, for example, have suffered key bounce and
> sent bad votes inadvertently.
I've now said that the Secretary can decide whether (for a particular
poll) developers may change their votes, and that people voting on
Technical Committee can always change them.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: