Proposed constitution for the Debian Project (v0.1)
The Debian Project is an association of individuals who have made
common cause to create a free operating system. This document
describes what decisions are made how in the Debian Project.
2. Decisionmaking bodies and individuals
Each decision in the Project is made by one or more of the following:
The remainder of this document will outline the powers of these
bodies, their composition and appointment, and the procedure for
their decisionmaking. The powers of a person or body may be
subject to review and/or limitation by others; in this case the
reviewing body or person's entry will state this.
- The individual developer working on a particular task;
- The developers, by way of General Resolution or an election;
- The Project Leader;
- The Technical Committee and/or its Chairman;
- The Project Secretary;
- Delegates appointed by the Project Leader for specific
3. Individual developers
An individual developer may
- make any technical or nontechnical decision with regard to their own work;
- propose or second draft General Resolutions;
- propose themselves as a Project Leader candidate in elections;
- vote on General Resolutions and in Leadership elections.
3.2. Composition and appointment
Developers are volunteers who agree to further the aims of the
Project insofar as they participate in it, and who maintain
package(s) for the Project or do other work which the Project
Leader's Delegate(s) consider worthwhile. The Project Leader's
Delegate(s) may vet developers, or choose to expel existing
Developers may make these decisions as they see fit.
4. The developers by way of General Resolution or election
Together, the developers may:
- Appoint or recall the Project Leader.
- Amend this constitution, provided they agree with a 2:1 majority.
- Override any decision by the Project Leader or a Delegate.
- Issue nontechnical policy documents and statements.
These include documents describing the goals of the project, its
relationship with other free software entities, and nontechnical
policies such as the free software licence terms that Debian
software must meet.
They may also include position statements about issues of the day.
- Together with the Project Leader and SPI, make decisions
about Debian's property. (See s.9.1.)
The developers follow the Standard Resolution Procedure, below. A
resolution or amendment is introduced if proposed by any developer
and seconded by at least Q other developers, or if proposed by the
Project Leader or the Technical Committee.
If a resolution to overrule a decision by the Project Leader or
their Delegate is seconded by at least 2Q developers (or Q
developers in the case of a resolution to overrule a decison to
vary a discussion period), or is proposed or seconded by the
Technical Committee, it will (if it so requests) stay the
relevant decision. In this case an immediate vote is held to
determine whether the decision will stand or its implementation
be delayed until the Standard Resolution Procedure is complete.
The Project Leader or Delegate (as appropriate) may prevent this
vote by withdrawing their decision.
Votes are secret and taken by the Project Secretary.
The minimum discussion period is 2 weeks, but may be varied by up to 1
week by the Project Leader. The Project Leader has only a casting
Q, above, is half of the square root of the number of current
5. Project Leader
The Project Leader may:
- Appoint Delegates or delegate decisions to the Technical Committee.
Once a decision has been delegated the Project Leader may not withdraw
that delegation; however, they may withdraw the appointment of a
person as a Delegate.
- Lend authority to other developers.
The Project Leader may make statements of support for points of view
or for other members of the project, when asked or otherwise; these
statements have force if and only if the Leader would be empowered to
make the decision in question.
- Make any decision which requires urgent action.
This does not apply to decisions which have only become
gradually urgent through lack of relevant action, unless
there is a fixed deadline.
- Make any decision for whom noone else has responsibility.
- Propose draft General Resolutions and amendments.
- Together with the Technical Committee, appoint new members
to the Committee. (See s.6.2.)
- Use a casting vote when Developers vote.
The Project Leader does not have a normal vote in such ballots.
- Vary the discussion period for developers' votes (as above).
- Lead discussions amongst developers.
The Project Leader should attempt to participate in discussions
amongst the developers in a helpful way which seeks to bring the
discussion to bear on the key issues at hand. The Project Leader
should not use the Leadership position to promote their own personal
- Together with SPI, make decisions affecting Debian's
property. (See s.9.1.)
The Project Leader is elected by the developers.
The election begins nine weeks before the leadership post becomes
vacant, or (if it is too late already) immediately.
For the following three weeks any developer may nominate themselves as
a candidate Project Leader.
For three weeks after that no more candidates may be nominated;
candidates should use this time for campaigning (to make their
identities and positions known). If there are no candidates
at the end of the nomination period then the nomination period
is extended for three further weeks, repeatedly if necessary.
The next three weeks are the polling period during which developers
may cast their votes.
The options on the ballot will be those candidates who have
nominated themselves and have not yet withdrawn, plus None Of
The Above. The decison will be made using the Concorde Vote
Counting. If None Of The Above wins the election then the
election procedure is repeated, many times if necessary.
The Project Leader serves for one year from their election.
The Project Leader should attempt to make decisions which are
consistent with the consensus of the opinions of the developers.
Where practical the Project Leader should informally solicit the views
of the developers.
The Project Leader should avoid overemphasizing their own point
of view when making decisions in their capacity as Leader.
6. Technical committee
The Technical Committee may:
- Decide on any matter of technical policy.
This includes the contents of the technical policy manuals,
developers' reference materials, example packages and the behaviour of
non-experimental package building tools.
- Decide any technical matter where developers' jurisdictions overlap.
In cases where developers need to implement compatible
technical policies or stances (for example, if they disagree
about the priorities of conflicting packages, or about
ownership of a command name, or about which package is
responsible for a bug that both maintainers agree is a bug,
or about who should be the maintainer for a package) the
technical committee may decide the matter.
- Make a decision when asked to do so.
Any person or body may delegate a decision of their own to
the Technical Committee.
- Overrule a developer (requires a 3:1 majority).
The Technical Committee may ask a developer to take a
particular technical course of action even if the developer
does not wish to; this requires a 3:1 majority. For
example, the Committee may determine that a complaint made
by the submitter of a bug is justified and that the
submitter's proposed solution should be implemented.
The Technical Committee may make formal or informal
announcements about its views on any matter.
- Together with the Project Leader, appoint new members to
itself. (See s.6.2.)
- Appoint the Chairman of the Technical Committee.
The Chairman is elected by the Committee from its members.
All members of the committee are automatically nominated;
the committee vote starting one week before the post will
become vacant (or immediately, if it is already too late).
The members may vote by public acclamation for any fellow
committee member, including themselves; there is no None Of
The Above option. The vote finishes when all the members
have voted or when the outcome is no longer in doubt. The
result is determined according to Concorde Vote Counting.
- The Chairman can stand in for the Leader, together with the Secretary
As detailed in s.7.1(2), the Chairman of the Technical
Committee and the Project Secretary may together stand in
for the Leader if there is no Leader.
The Technical Committee consists of up to 8 developers, and should
usually have at least 4 members.
When there are fewer than 8 members the Technical Committee may
recommend new member(s) to the Project Leader, who may choose
(individually) to appoint them or not.
When there are 5 members or fewer the Technical Committee may appoint
new member(s) until the number of members reaches 6.
When there have been 5 members or fewer for at least one week
the Project Leader may appoint new member(s) until the number of
members reaches 6, at intervals of at least one week per
- The Technical Committee uses the Standard Resolution Procedure.
A draft resolution or amendment may be proposed by any
member of the Technical Committee. There is no minimum
discussion period. The Chairman has only a casting vote.
- Public discussion and decisionmaking.
Discussion, draft resolutions and amendments, and votes by
members of the committee, are made public on the Technical
Committee public discussion list. There is no separate
secretary for the Committee.
Confidentiality of appointments.
The Technical Committee may hold confidential discussions
via private email or a private mailing list or other means
to discuss appointments to the Committee. However, votes on
appointments must be public.
No detailed design work.
Then Technical Committee does not engage in design of new proposals
and policies. Such design work should be carried out by individuals
privately or together and discussed in ordinary technical policy and
The Technical Committee restricts itself to choosing from
or adopting compromises between solutions and decisions which have
been proposed and reasonably thoroughly discussed elsewhere.
- Technical Committee makes decisions only as last resort.
The Technical Committee does not make a technical decision
until efforts to resolve it via consensus have been tried
7. The Project Secretary
Takes votes amongst the Developers when required.
Can stand in for the Leader, together with the Chairman of the
If there is no Project Leader then the Chairman of the
Technical Committee and the Project Secretary may by
joint agreement make decisions if they consider it
imperative to do so.
- Adjudicates any disputes about interpretation of the
The Project Secretary is appointed by the Project Leader and the
current Project Secretary (or, if there is no Project Secretary, the
Chairman of the Technical Committee).
If there is no current Secretary and the Leader and the Chairman of
the Technical Committee cannot agree on a new appointment and then
they must ask the board of SPI to appoint a Secretary.
8. The Project Leader's Delegates
The Project Leader's Delegates:
- have powers delegated to them by the Project Leader;
- may make certain decisions which the Leader may not make
directly, including vetting or expelling developers or
designating people as developers who do not maintain packages.
The Delegates are appointed by the Project Leader and may be
replaced by the Leader at their discretion. The Project Leader
may not make the position as a Delegate conditional on particular
decisons by the Delegate, nor may they override a decision made by
a Delegate once made.
Delegates may make decisions as they see fit, but should attempt
to implement good technical decisions and/or follow consensus
9. Software in the Public Interest
SPI and Debian are separate organisations who share some goals.
Debian is grateful for the legal support framework offered by SPI.
9.1. Management of Debian's property
SPI will hold Debian's money, trademarks and other tangible
and intangible property and manage other affairs requiring
legal personality, tax exempt status or the like.
Such property will be accounted for seperately and held in
trust for Debian.
SPI does not spend money or otherwise dispose of or use
Debian's property without permission from Debian, which may be
granted by the Project Leader or by General Resolution of the
SPI will consider spending money or disposing of Debian's
property when asked to do so by the Project Leader.
SPI will spend money or dispose of Debian's property when
asked to do so by a General Resolution of the Developers.
SPI has no authority regarding Debian's technical or
nontechnical decisions, except that no decision by Debian with
respect to Debian's property held by SPI shall require SPI to
act outside its legal authority, and that Debian may
occasionally use SPI as a decision body of last recourse.
Debian has authority over SPI other than that over Debian's
property, as described above.
A. Standard Resolution Procedure
These rules apply to communal decisonmaking by committees and
plebiscites, where stated above.
The formal procedure begins when a draft resolution is proposed and
seconded, as required.
A.1. Discussion and Amendment
Following the proposal, the resolution may be discussed.
Amendments may be made formal by being proposed and seconded
(requirements as for a new resolution).
A formal amendment may be accepted by the proposer, in which case
the formal resolution draft is immediately changed to match.
If a formal amendment is not accepted, or one of the seconders of the
resolution does not agree with the acceptance by the proposer of a
formal amendment, the amendment remains and will be voted on.
If an amendment accepted by the original proposer is not to
the liking of others, they may propose another amendment to
reverse the earlier change (again, they must meet the
requirements for proposer and seconder(s).)
A.2. Calling for a vote
The proposer of a motion or an amendment may call for a vote,
providing that the minimum discussion period (if any) has
The proposer of a motion may call for a vote on any
or all of the amendments individually or together; the
proposer of an amendment may call for a vote only on that
amendment and related amendments.
The minimum discussion period is counted from the time the
last formal amendment was accepted, or the last related formal
amendment was accepted if an amendment is being voted on, or
since the whole resolution was proposed if no amendments have
been proposed and accepted.
A.3. Voting procedure
Each independent set of related amendments is voted on in a
separate ballot. Each such ballot has as options all the
sensible combinations of amendments and options, and an option
Further Discussion. If Further Discussion wins then the
entire resolution procedure is set back to the start of the
When the final form of the resolution has been determined it
is voted on in a final ballot, in which the options are Yes,
No and Further Discussion. If Further Discussion wins then
the entire procedure is set back to the start of the
The vote taker (if there is one) or the voters (if voting is
done by public pronouncement) may arrange for these ballots to
be held simultaneously, even (for example) using a single
voting message. If amendment ballot(s) and the final ballot
are combined in this way then it must be possible for a voter
to vote differently in the final ballot for each of the
possible forms of the final draft resolution.
The votes are counted according to the Concorde Vote Counting.
In cases of doubt the Project Secretary shall decide on
matters of procedure (for example, whether particular
amendments should be considered independent or not).
A.3. Withdrawing resolutions or amendments
The proposer and/or seconder(s) of a resolution or amendment
(unless it has been accepted) may withdraw it. In this case new
proposer(s) and/or seconder(s) may come forward keep it alive, in
which case the first remaining seconder becomes the new proposer
(if the original proposer withdrew) and in any case the other
proposer(s) and/or seconder(s) become seconders.
If a proposed resolution has not been discussed, amended, voted on
or otherwise dealt with for 4 weeks then it is considered to have
A.5. Concorde Vote Counting
This is used to determine the winner amongst a list of
options. Each ballot paper gives a ranking of the voter's
preferred options. (The ranking need not be complete.)
Option A is said to Dominate option B if strictly more ballots
prefer A to B than prefer B to A.
All options which are Dominated by at least one other option
are discarded, and references to them in ballot papers will be
If there is any option which Dominates all others then that is
If there is now more than one option remaining Single
Transferrable Vote will be applied to choose amongst those
The number of first preferences for each option is
counted, and if any option has more than half it is the
Otherwise the option with the lowest number of first
preferences is eliminated and its votes redistributed
according to the second preferences.
This elimination procedure is repeated, moving down ballot
papers to 2nd, 3rd, 4th, etc. preferences as required,
until one option gets more than half of the `first'
In the case of ties the elector with a casting vote will
decide. That elector does not get a normal vote.
If a supermajority is required the number of Yes votes in the
final ballot is reduced by an appropriate factor. Strictly
speaking, for a supermajority of F:A, the number of ballots
which prefer Yes to X (when considering whether Yes Dominates
X or X Dominates Yes) or the number of ballots whose first
(remaining) preference is Yes (when doing STV comparisons for
winner and elimination purposes) is multiplied by a factor A/F
before the comparison is done.
B. Use of language
The present indicative (`is', for example) means that the
statement is a rule in this consitution. `May' or `can' indicates
that the person or body has discretion. `Should' means that it
would be considered a good thing if the sentence were obeyed, but
it is not binding.