The TUNES Charter
This document will outline a set of rules
to facilitate the parallel development of interrelated projects.
(Last content modification Thursday 1996-04-04 01:20 MET)
(Last facelift Sunday 2003-01-19 03:53 PST)
- The project may be divided into a number of more specific subprojects.
- These subproject may be partially ordered,
so that some subprojects are subject to others.
- There is one and only one subproject that is above all others,
which is the main project, also called root project or project.
- The project founders can be members of the project as they wish.
- Any human can become a member of any existing subproject,
including the main project,
by just volunteering and publishing his wish.
He will actually become a member if no other member opposes,
or a decision is taken to grant him membership.
- A member of a project is automatically granted membership to all
subproject below it, unless he refuses.
- Members have the right to be informed
of any decision taken or ballot organized
concerning the subproject,
as well as to vote (with the same weight as the other ones)
during those ballots.
- A procedure exists to avoid lack of decision from democratic means
- Each subproject, including the root project, has got a coordinator,
also called maintainer.
- The coordinator of the root project is also called general coordinator.
- A project maintainer has the responsibility
to maintain all documents
and make them available to everyone in the project.
- In those documents, he must take into account
the arguments of other members,
even though he may not agree,
by at least quoting them,
at their demand.
- A project coordinator also has the responsibility
to organize any ballot related to the project.
- A project's first coordinator will arbitrarily be
the one who proposed the project.
- In case of vacancy, a post of coordinator will be given
to the first volunteer,
unless a decision is otherwise taken.
- A decision can be
any modification of any document in the project,
the appointment of a new coordinator,
or the creation or removal of a subproject.
- It is possible for a project coordinator,
as a quick decision prodecure,
to take any decision concerning his project or a subproject below it,
by simply publishing it,
unless someone opposes to that decision before one week.
- In case anyone proposes or opposes some decision,
and no agreement is found with the coordinator,
a ballot must be organized by the coordinator before one week,
to vote about that decision.
- In case no majority opinion is obtained after two ballots,
a referee will be chosen,
whose decision will prevail.
- The referee will be, among those who accept,
the coordinator of the highest subproject above the one involved.
- If a referee was called,
the coordinator of the project (perhaps himself the referee),
must state in the documents
that the decision was taken without majority.
- A coordinator may not undo a vote using a quick decision procedure,
if no one opposes within one month,
and three other members are found to support him
(assuming that many members exist).
Special Decision Procedure
- A special decision can be
any other decision concerning the project,
including financial decisions,
modification of the Charter,
choice of copyright policies.
- The general coordinator,
or three agreeing project members,
can propose a special decision.
- When a special decision is to be taken,
the coordinator of the main project must organize a vote
about the special decision.
- A ballot is then organized,
and two third of expressed votes at least must agree
so the special decision passes;
a quorum of three members, if there are that much members,
is required for the ballot to be valid.
- In case no special decision passes,
and no previous special decision was taken,
the general coordinator's opinion will prevail,
but he must state in the documents
the lack of majority for the special decision.
- Under no circumstance shall a coordinator,
including the general coordinator,
undo a special decision taken by vote;
however, a successful ballot may well
alter a previous special decision.
This section is still optional; I'd like members to state their
mind about it. It is meant to prevent the project from being wormed
by any outside interest group.
- To ensure the continuity of the project,
and the persistence of its original spirit,
there is a way in which older members
can veto decisions made by newer members.
- At any moment,
a member of a subproject
can ask all members who joined before him (including himself)
to veto a decision or a special decision.
- A ballot will then be organized among those members,
by the coordinator of the according subproject.
- The same majority as required by the vetoed decision
must be found to put the veto on it;
that is, majority plus one vote for normal decisions,
or two-thirds majority in case of a special decision.
- If the veto is put, the vetoed decision is cancelled.
- The veto can itself be cancelled by another veto,
organized by a member who joined earlier
than the one who organized the veto to be cancelled.
- To avoid project sclerosis,
veto duration is limited to one year
minus one week per year spent in the project
by the member who asked the veto.
- After a veto is ended,
or if the one who asked the veto removes it,
the same cancelled decision can be voted again,
but another veto can be asked for,
just not by the same member or any older one.
- Submit the modified version to the mailing list
(older versions are on the list's archive).
To clarify the spirit of the Charter:
in each subproject, the maintainer is a benevolent dictator
who chooses the default direction.
e-votes are just too slow for decision-making.
They might be used to impeach and/or replace the dictator,
when he's not doing his job correctly,
or has opinions too divergent from the rest of the projects
(however, see the project continuity addendum).
And the ultimate dictator should be -- Running Code.
If some voters are not satisfied,
let them just implement (then use) their view of the Right Thing instead!
Surely, if the majority is for some code, rather than another, they'll use it.
And if the founders or maintainers are blockheads
that will oppose to good changes (well, in some people's opinion),
then it's time (for these people) to spawn another project;
the charter requires that this spawn be clearly distinguished
and considered as a new project, so as not to betray the spirit
of those who got the project up and running to the point of divergence;
but of course, the software license allows the new project
to reuse all of the code from the original one,
so nothing is lost.
And maybe the projects can merge back someday.
Providing free software and letting people use it is the ultimate democracy!