Political policymaking
I said in my election manifesto that I would formulate a set of rules
for making political decisions. This has generated a certain amount
of debate, and I think I need to explain in more detail the kind of
thing I'm thinking of.
Before I start I want to head off a couple of possible
misapprehensions.
Firstly, I don't propose to apply a voting procedure like this to
technical decisions. Technical decisions are made very poorly by
electorates - ideally they need to be taken by the key technical
people who are familiar with the issue in question. The kind of issue
I see this being used for is decisions relevant to the _goals_ of the
project. For example, about what kind of `freeness' our software
should be required to have, or whether we should aim to make our
software buildable on non-Debian or non-Linux systems.
Secondly, this is only one part of my manifesto. In particular I
consider the creation of a new mechanism for solving technical
disputes important too - you'll note my manifesto's content about a
technical committee. (Just to reiterate: the technical committee
would not be doing design - it would merely act as an arbiter for
certain kinds of disputes.)
Thirdly, the set of rules I propose below are just a starting point,
which I'm posting to make more clear what kind of things I'm
proposing. I haven't yet made the rules as clear and unambigious as
might be ideal. There will be a debate about them and discussion, but
I don't think the leadership campaign is the right place for it. This
leadership campaign is about whether you want (at all) something like
this and like the other changes in my manifesto.
Fourthly, I don't plan to _impose_ any new decisionmaking procedures
on the project. When discussions have stabilised the developers will
get the opportunity to vote on the rules for political decisionmaking
and for the technical committee, and the opportunity to vote on
important questions that arose out of the discussion. I plan to take
things slowly, and make sure that every decision about the
decisionmaking procedures themselves takes as many of the developers
along as possible - I think this is essential for things that will
form major planks of Debian's infrastructure.
Now, for the rough details of the political policy process:
There would be a mailing list for discussing this kind of issue;
debian-devel may not be appropriate for such extended discussions.
(This question is related to the one of whether we want more or fewer
different mailing lists - upon which we also need to form a coherent
strategy.)
When (or before) the discussion has started going round in circles
someone who is fed up with it can write up a concrete draft. When the
draft is proposed and has received some number of seconders (to be
determined) it will be put through the formal voting procedure, below.
If it doesn't receive enough seconders then the proposer should
consider why this happened and either withdraw or fix the problem.
The discussion can continue. During this phase people can suggest
improvements in wording or meaning to the proponent, who can
incorporate them into the draft.
If the proponent rejects someone's suggested improvement or the
proponent accepts an improvement that someone disagrees with, and the
question cannot be resolved to everyone's satisfaction, then the
person who disagrees with the proponent can propose an amendment (ie,
a set of changes to the wording). When this too has received the
required number of seconders it is incorporated into the draft as an
alternative possibility.
When in the chairman's view the consensus is that the discussion has
reached futility - nothing new is being said, and all the issues are
resolved or intractable - the chairman (probably the project leader)
calls for a vote on one or more of the amendments, or on all of the
amendments and the proposal itself.
At this point each developer casts a separate vote on each amendment
being voted on, and (if the proposal itself is to be voted on)
indicates approval or lack of approval of each possible resulting
resolution. It's the job of the chairman, probably the project
leader, to ensure that the number of possible resulting motions is
small, by helping to build consensus in the discussion, or failing
that by getting contentious or complicated amendments out of the way
first.
If the proposal itself wasn't voted on the process continues using the
results of the votes on the amendments which have been dealt with;
otherwise the whole resolution in whatever final version was reached
is either passed or rejected.
If amendments interact with each other then the different plausible
alternatives are put to the vote together using Single Transferrable
Vote.
Normally `integration' is done by the proponent - they integrate
mutually unrelated changes into the draft proposal and/or the various
amendements which have been proposed so far. Disagreements about
whether changes are related, and about whether the proponent has
integrated unrelated changes into amendments in a reasonable way, are
to be resolved by the chairman.
There are a number of special cases not well-covered by the wording
above - the wording is still only informal. If I'm elected and when
we've decided on the overall mechanism we can get more specific.
Ian.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: