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

Re: Initial draft proposed consitutution (v0.3)



0.3 is at http://www.chiark.greenend.org.uk/~ian/debian-organisation-0.2.html
I've change it so that .../debian-organisation.html is the most recent
version, and .../debian-organisation-0.1.html is now 0.1.

Ian.

john@dhh.gt.org writes ("Re: Initial draft proposed consitutution (v0.2)"):
> Manoj writes:
> > When the document says 2:1 vote etc, does it mean 2:1 of the total voting
> > membership, or 2:1 or the set of people who actually voted?
> 
> Ian writes:
> > The latter.  I have added some rationale.
> 
> I think you should also specify a quorum.  Do we want to reference Robert's
> Rules?

There is effectively a quorum, because a certain number of developers
must propose and second a resolution (and presumably they're in favour
of it ...)

There isn't a quorum for the Technical Committee.  I'm not sure that
there should be.

James A.Treacy writes ("Re: Initial draft proposed consitutution (v0.1)"):
> In the Voting Procedure there should be some mention of a minimum
> number of votes needed for a resolution to pass.

See my response above :-).

> It might be a good idea to specify a minimum length of time between
> submitting the same proposal (4 months should be sufficient). This
> is to prevent a group of people from wasting time by submitting the
> same idea over and over.

I think we should cross this bridge when we come to it.  Remember that
proposing a resolution requires a proposer and sqrt(n)/2 seconders,
which is currently about 1+7.

If we have 8 people who don't know when to quit invoking the formal
procedure in this way then we probabably have more serious problems ...

> (A.2.3) As I understand this section, it would be possible for a group
> to postpone a vote indefinitely by constantly proposing new amendments. This
> is not good.

No, the proponent can call for a vote anyway.  The minimum discussion
period is counted from the last _accepted_ amendment.  If the proposer
decides not to accept an amendment they can go to vote anyway, even if
the amendment was submitted very recently.  The amendment will still
be voted on, and the developers can vote for Further Discussion if
they wish.

> I'd like to see a change to 9.1.3 to have the Project Leader notify the
> developers 1 week prior to authorizing SPI to spend money. The Leader
> may not proceed with the authorization if there is a proposal made against
> the spending of the money. There should be an exception for emergencies
> though. Even in that case, the developers should be notified.

At the moment the Project Leader can't spend money on their own - they
need the approval of the SPI board.

The requirement for notification is good.  I have added it to draft
0.3.

> Just an idea which may not be tenable: could you allow for a vote to end
> in less than 2 weeks if over a certain % of developers have voted (60% say)
> and the required (super)majority has been reached?

I've added a sentence saying that even developers' votes can end when
the outcome is known.

I've just realised that the proposer of a resolution should be able to
put forward amendments without having to collect seconders, so I fixed
that too.

Ian.


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


Reply to: