Re: Constitution - formal proposal (v0.6)
> > 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.
>
I feel that the current wording could lead to problems but don't have a good
way to resolve it. If it does become a problem, I'm sure the secretary will
let us know. :)
> 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 ?
>
Not at all. If a few proposals are running simultaneously, each with a few
formal amendments, it could get quite confusing and make the job of secretary
a nightmare. Also, the state of proposals should always be known even if the
secretary (and his/her subordinates) is away for a few days.
As required all discussion will take place on mailing lists. The idea is to
automate those aspects of getting proposals through the system that are easily
automated. In addition, a web page lists all current proposals with a link to
the old ones. The page for each proposal will make it clear at all times how
many proposers there are, what their names are, what the latest wording of
each proposal and its amendments are, and list all the other assorted
pieces of data that are a pain to keep track of (Q, K, number of required
seconders, supermajority, etc).
The only aspect that could possibly be interpreted as being in conflict with
the constitution is that I was planning on having developers send proposals,
seconds and amendments, etc directly to the system which would then make
the announcement for them if everything was in order.
Anyone interested in seeing details on how developers interact with the
system should look at http://www.easynet.on.ca/~treacy/
It's really quite simple.
Jay
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: