Re: Constitution - formal proposal (v0.5)
On Fri, 3 Apr 1998, Ian Jackson wrote:
> Dale Scheetz writes ("Re: Constitution - formal proposal (v0.5)"):
> ...
> > Section 6 (and elsewhere) talks about the "Technical Commitee". Can I
> > assume that we don't currently have one of those? If I understand the
> > constitution, this means that Ian will have to appoint 5 members, and
> > those 5 members will have a week to appoint a 6th member? I saw no
> > criterion for deciding whether extra committee members were needed for the
> > extra 2 possible seats. Am I just missing something here?
>
> The motion that I proposed would have me appoint the entire technical
> committee for the first time. If we don't do that then I have to
> appoint one member, who appoints all the remaining members until there
> are 6, at which point I get to veto the 7th and 8th.
>
> I suppose I could appoint myself initially :-).
ROFL
>
> > Section 8.2 on Delegate Appointment looks like it could be a real can of
> > worms. There seems to be an inate contradiction in this section. First it
> > says that the Project leader may replace a Delegate, but then later says
> > that the PL can not make appointment contingent on the deligates
> > decisions. It could be argued then, that the PL can not dismiss a delegate
> > based on the performance (decisions made) of that delegate! What other
> > criterion would be more appropriate? Even sloth is a decision (except for
> > the species so named, of course ;-) made by the delegate.
>
> It says that the leader `may not _make the position conditional on_
> _particular_ decisions'. So, the leader can fire a delegate for being
> generally crap, but can't say `I'll give you the position if you do X'
> or `I'll fire you if you do Y'. To me making A conditional on B means
> not just using B as a part of your decision, but using it as a major
> or published criterion.
>
Which implies that the PL can fire a Delegate, if that delegate makes a
decision that the PL disagrees with! It was my understanding that a
Delegate was not supposed to have to deal with the wims of the PL. Like I
said...can of worms.
> > And finally, (yes, I'm almost out of things to say ;-) Section A.5.8 seems
> > to make the idea of a Quorum recursive. It does this by first requiring
> > that a quorum be present for a vote, and then expanding the requirement by
> > requiring that same number of votes for the proposal in order that it
> > pass. This is basically a redefinition of what constitutes a quorum in
> > this case. It seems overly complex, as all you have to do is the
> > appropriate math and propose that for these classes of vote a quorum is
> > constituted of X*Q where X is the recomputed fudge factor.
>
> I'm very confused by this. s.A.5(8) just says what a quorum means;
> the number that constitutes a quorum in any context is specified
> elsewhere.
>
Q is defined elsewhere. What constitutes a quorum appears to be defined
differrently for differing voting requirements. That is, a simple majority
vote requirement has a smaller quorum than a 2:1 voting requirement.
But the section goes on to require that the total number of votes cast in
favor of the proposal must be equal to or greater than the quorum. If the
total votes cast equals the quorum value, this requires that everyone
voting vote for the proposal. This contradicts the voting requirements,
which for a 2:1 vote only requires 2 out of 3 voters be in favor. This
looks like an additional, recursive, requirement on the definition of a
quorum.
BTW, it is non-trivial to remove leader@ from the CC list, as it doesn't
appear there. From: automatically goes into To: and debian-devel gets the
CC: slot, so actuall editing of both lines is necessary. Could you create
a more useful Reply To: field for your mail, Ian?
Waiting is,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: