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

Re: Initial draft proposed constitution (v0.3)



Bob Hilliard writes ("Re: Initial draft proposed constitution (v0.2)"):
>      Should the constitution mention some of the offices that are
> currently filled, such as VP of Engineering and Policy Manager and
> define their duties and method of appointment?

No.  They're the Project Leader's Delegates, and that's already
covered.  I don't see any need to put that in the constitution.

Raul Miller writes ("Re: Initial draft proposed consitutution (v0.2)"):
> Ian Jackson <leader@debian.org> wrote:
> > On the other hand: suggest a better way of making the kind of
> > important decision I'm suggesting would be done by vote. Previously we
> > had flamewar-followed-by-fiat, which I don't think worked particularly
> > well.
> 
> How about this: if a vote shows unusually high or low turnout, adjust
> the quorum for the next vote in the appropriate direction. [And leave
> it there till the active voting record indicates a further change is
> needed.] Thus, you set the initial quorum then let activity rather than
> membership dictate the changes.
> 
> [For better or worse, this roughly approximates our current practice.]

Err, this seems to be a discussion about quorums rather than about
voting per se.  However, very well ...

Currently, there is no quorum except the number of seconders.  Do you
think that there should be a separate (higher, presumably)
participation requirement for votes to that for propositions ?

This may solve the problem of requiring very many seconders; we could
limit Q to 10 and have a voting quorum of 3 sqrt(n), for example, or
do as you suggest with varying quora.

Would you like to propose an actual formula for the dynamically
adjusting quora ?  It should preferably depend on more than just the
previous vote, because some votes will be more or less popular than
others.

> Also, if fraud ever turns up, prohibit those responsible from further
> voting and provide a mechanism to transform the decisions from votes
> whose integrity is suspect to suggestions rather than requirements,
> while trying to clean up the damage. [Hopefully, this event will never
> occur.]

I think we can leave this kind of thing up to the Project Secretary,
who takes the votes and has the power to adjudicate disputes.

Kai Henningsen writes ("Re: Initial draft proposed consitutution (v0.2)"):
...
> Can you please explain 4.2? I always thought my English was fairly good,  
> but it's not up to that one.

I presume it's the second paragraph you're confused by ?  That's there
to make it possible to hold up a decision by the Project Leader until
a vote can be taken.  This takes more people to do than just to force
a vote.

> As to seconding, seems to me with ~ 300 developers, Q is something like  
> 8.7. Needing seconding from that many is bound to require a procedure all  
> for itself.

You think so ?  You don't think
  X: I propose the following
  A,B,C,D,E,F,G,H,I: seconded
will be easy ?

Alternatively we could have these things go by email.  Do you think
that 9 is too many ?  Do you think it should depend on the number of
current developers at all ?

See my comments to Raul, above.

john@dhh.gt.org writes ("Re: Initial draft proposed consitutution (v0.1)"):
...
> The leader's power to arbitrarily expel and admit developers could be used
> by a clique to gain control.  While I don't think this is too likely, a
> constitution should not leave such loopholes.  More serious is the matter
> of perception.  I think your wording gives an authoritarian impression,
> with one person appearing to have the power to admit or expel.  Mine makes
> it clear that these important decisions are in the hands of the membership.

Have you actually read v0.2 ?  It has a sentence pointing out that
this decision is in the hands of the membership.

...
> I don't think that most members will realize that such a thing is possible
> unless it is explicitly stated in the constitution.
...

It is now explicitly stated.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: