Re: Constitution - formal proposal (v0.6)
James A.Treacy writes ("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).
I've added something about this to the Technical Committee section.
It doesn't seem relevant for other kinds of votes. (For example,
clearly the Project Leader should get ordinary votes as a Developer,
even in votes to override the Leader.)
> 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.
This is intended to be used in emergency. You'll note:
When acting together to stand in for an absent Project Leader the
Chairman of the Technical Committee and the Project Secretary
should make decisions only when absolutely necessary and only when
consistent with the consensus of the developers.
It's common practice to have `neutral' officers like the Secretary act
as a stand-in for a `political' officer in times of extreme need.
> 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.
No, because the seconder shouldn't need to gather seconders for their
amendment in this case.
If the problem you describe arises then I'm sure that a consensus can
be reached about how things should be voted on. If things get too
silly the Secretary can make a decision.
I've added a paragraph that allows the proposer of a resolution to
suggest changes to amendments, so that if everyone is being reasonable
the `best' form of each amendment can be voted on.
> 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.
I think removing one's second for not liking an amendment is
overkill and not granular enough.
> This will all be much simpler when I finish the proposal automation.
I disapprove of the idea of automation.
s4.2(5):
Proposals, seconds, amendments, calls for votes and other formal
actions are made by announcement on a public-readable electronic
mailing list designated by the Project Leader's Delegate(s); any
developer may post there.
Are you proposing a change to this ?
I know that we're hackers, but there are some things best left to
people.
...
> 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).
I've clarified this in my latest draft.
> 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).
Exactly what options are available in what order is decided on by the
Secretary.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: