Re: Constitution - formal proposal (v0.6)
First a trivial change. "money money" in 9.2.1 should have one money deleted.
Next some suggested changes:
1.) It should be stated somewhere that a member of a committee, that is a member
of a group for which a decision is being made, does not have a vote on that
issue, as a member of the committee. If it is an issue that comes to a general
vote then they do have a vote.
This is primarily intended for the Technical Committee. A member of that
committe only needs to convince one other member to vote their way to prevent
the committee from making a decision involving themself (only 8 members and 3:1 is
required to overrule a developers decision).
2.) The secretary must be in a position of neutrality. As such they should have
no decision making powers outside their duties as secretary. In that regard
I question the wisdom of 6.1.8 and 7.1.2 which lets the secretary, in conjunction
with the chair of the Technical Committee, share the power of Leader in the
Leaders absence.
3.) A minor modification to section A.1 will make the order of events cleaner and
easier to code regarding acceptance of formal amendments. I suggest the following:
3. If a formal amendment is not accepted, it remains as an amendment
and is voted on.
4. If an amendment accepted by the proposer is not to the liking of
others, including seconders, they may propose another amendment to
reverse the earlier change.
5. If a seconder does not agree with the acceptance by the proposer
of a formal amendment they are free to remove their second (or not
as the case may be).
The current wording of this section is awkward in practice: A seconder may
be away a while and miss future changes. When they return, all the (related)
changes would have to be undone when they object to the first change. Putting
the onus on the seconder to rectify the situation (through a formal amendment)
simplifies matters.
Ian just ran into a related problem when he only accepted part of Manoj's
formal amendment. If a seconder objects they could force most of the revisions
that went into version 0.6 to be removed. Letting the proposer have power over
content voted on and letting the developers have say over the final form through
amendments seems like the right way to go. Remember if seconders aren't happy
with changes, they are free to remove their second.
This will all be much simpler when I finish the proposal automation.
Currently, proposals can be submitted and revised, can be seconded, seconds
can be withdrawn, and a web page showing all the relevant facts concerning
each proposal generated (supermajority, date last modified, earliest possible
vote date, length of vote, etc). Once I add code to handle amendments (not
difficult since they have a very similar form to proposals) I'll release
the code and start working on voting.
I was hoping to have it finished this week, but I've got too many evening
meetings. Oh well.
4.) Call for clarification. Is it the intention of A.3 that in the case that
a proposer withdraws a resolution, that the seconders are given the chance,
in order, to take over the resolution? Or should the first person who would
like to champion the cause become the new leader? It isn't clear to me how
this should be handled, so my current plan, in setting up the proposal
automation, is to leave it up to the secretary to deal with this situation
(all the proposal files are plain text. The secretary can easily modify
anything they want - except votes as they are signed using PGP).
5.)Another call for clarification. I just want to make sure I understand how
the voting is supposed to work.
Suppose there is a proposal with 3 formal amendments, a, b and c with a and b
related. If the proposer of the original proposal wants to bring this to a
vote, is it done as follows (assume all have met the discussion time criteria)?
There is an initial vote with the following choices
original proposal
original proposal modified by a
original proposal modified by b
original proposal modified by c
original proposal modified by a and c
original proposal modified by b and c
After the winner is chosen there is a second vote to approve the final version
of the proposal (or send it back for discussion).
- Jay
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: