I agree with much of the criticism of the outgoing Secretary's actions
in the Lenny GR vote. But I think we need to look to see how this
came to pass.
In my view the mistake came when the project voted to entrench the
Foundation Documents by requiring a 3:1 supermajority to change them.
This isn't because I don't support the Foundation Documents. I do
generally support thier spirit. (Although they postdate my
involvement in Debian and I do have some reservations about some
aspects.)
However, I do have very strong reservations about trying to use the
text of the current Foundation Documents as if they were binding legal
documents. They are just too vague and woolly. Entrenching them has
made it seem to some people that they ought to be binding, because if
they are not supposed to be binding, why would it be necessary to
entrench them ? This is inferred even though it isn't explicitly
stated in the Constitution and perhaps wishful thinking amongst what
we might call `hardliners' has done the rest.
Another way of looking at this is that the original Constitution as I
wrote it says not _what_ decisions should be made. It specifies only
_who_ should make the decision and the process by which it should be
made. There is little attempt to bind anyone's discretion. This
makes our processes depend on having the right people doing the right
jobs - just like anything else in the project.
But a set of binding entrenched documents with substantial
sociopolitical content is something quite different: it attempts to
say not who should make a decision but what the decision should be.
The role of the Secretary as interpreter of the constitution changes
utterly as well: originally, the Secretary would be required to
arbitrate essentially procedural matters. But with a set of vague but
binding foundation documents with real and controversial content, they
are suddenly put in the position of arguably being required to
interpret those documents - and also because of the ambiguity being
required to decide whether they have the authority to interpret them!
This is far too much for a single person.
This leaves us with really four options:
A. Explicitly de-entrench the Foundation Documents by repealing
Constitution 4.1(5) 1..3 and establishing the Social Contract
and DFSG as simple Position Statements according to 4.1(5).
B. Explicitly state that the Foundation Documents are to be
interpreted by each Developer (and everyone else) for themselves
in the context of their own work, eg by inserting
2. including interpreting the Foundation Documents
as necessary;
in Constitution 3.1.
C. Rewrite the foundation documents so that they are clearly
comprehensible (rather than vague) and establish an independent
legally-minded body to make these decisions.
D. Establish (or empower) some kind of interpretation committee,
which would have to be elected.
Of these:
A. De-entrenchment: this is very unlikely to achieve the required
supermajority. But it should be on the ballot anyway when
we put this mess to a vote after lenny.
B. Developers are to interpret: this is I think the only workable
option and given that we have several times now had a GR whose
outcome was essential identical to that of the Developers in
question, I think we might be able to get a supermajority.
In case it doesn't, this ballot option should explicitly state
that this is the Project's view of the corrent interpretation of
the existing constitutional text and that this resolution is
intended merely to clarify the constitution.
C. Rewrite the documents to be clear.
Those of you who remember my term as DPL will remember an enormous
flamewar that ensued when I tried to replace the DFSG with a clear
statement about what licence conditions were acceptable. At that
time they were't entrenched but even so it became clear that
getting a consensus would be impossible because it would involve
arguing about every stupid licence condition ever invented.
So I think this is a non-starter.
D. Establish an interpretation committee: Please god no what a
nightmare. How do you defend the committee from a majority of
voters anyway ? Or are you going to entrench it the way the TC is
entrenched ? That's all very well for technical decisions but
it would be quite wrong for political ones to do with the
project's goals.
While we're at it I have a few pet problems:
GR process
- The Secretary should have a duty to help formulate clear
resolutions. Eg, add to
5. Has a duty to assist drafters of General Resolutions
to clearly and effectively express their intent;
this duty extends to suggesting alternative wording(s)
which the proposer may (but need not) make into
a formal amendment and accept according to A.1(1) and (2).
I think this will ensure that the GRs - particularly ones which
amend the Constitution - are interpreted the way the proposers
intended.
- The Secretary should explicitly have the power to delay a GR
vote by up to (say) two weeks for the purposes of
- running related votes concurrently
- assisting drafters as above
unless the DPL objects, and may delay it by a further two weeks
if given explicit permission by the DPL.
- To help voters choose, the following people should be able to
require the Secretary to quote on each GR ballot form a URL
of their choice, to be used by them for disseminating their vews on
the vote:
The Proposer of each resolution or amendment
The Project Leader
Each Delegate or group of Delegate(s) named or overruled
A nominee of the Technical Committee
A nominee of each Trusted organisation designated according to 9.3
Technical Committee
- Specify who decides whether a decision is technical. Currently
this is semi-implicitly left to the Secretary but in the past these
questions have generated a great deal of useless side chatter in TC
discussions, sometimes in cases where there was a mix of technical
and nontechnical content.
I would suggest writing that the TC itself may decide this. If the
TC gets it wrong and does something outrageous the Developers
should be able to get a 2:3 to overrule that decision so they can
overrule the actual decision too.
In mixed cases given the TC's lack of willingness to touch
political hot potatoes we can probably trust the TC to only rule on
technical issues.
- Fix the TC supermajority requirement (which was broken -
accidentally changed from >=3:1 to >3:1 ie usually >=4:1) when the
voting system was redone)
- Increase the TC maximum size.
Ian.
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
