1 files changed, 160 insertions, 0 deletions
diff --git a/governance.mdwn b/governance.mdwn
new file mode 100644
index 0000000..b2700ab
--- /dev/null
+++ b/governance.mdwn
@@ -0,0 +1,160 @@
+[[!meta title="Governance"]]
+
+vmdb2 constitution v1.0
+=============================================================================
+
+Introduction
+-----------------------------------------------------------------------------
+
+This constitution is the formal rules of the vmdb2 project: it defines
+how we govern the project. The vmdb2 project develops the vmdb2 software,
+for Debian image building. The project governance structure is
+informally based on the principle of **do-ocracy**: those who do,
+decide. This constitution formalises the principle, to help the
+project grow, to make it easier for new contributors to join the
+project, and to avoid misunderstandings.
+
+This is the first version of the constitution. It is expected to grow
+as the project gets more contributors. A probable change is to start
+using a [Debian-style Condorcet][] voting method. It is overkill with
+only a handful of contributors, but will become more important later
+on.
+
+[Debian-style Condorcet]: https://www.debian.org/vote/
+
+
+Levels of membership
+-----------------------------------------------------------------------------
+
+There are two levels of membership in the project: **contributors**
+and **voting members**. Contributors are all those who work to the
+project in order to make the vmdb2 software, its website, documentation,
+other deliverables, or the project itself better. Voting members have
+the power to collectively make any decision of the project by voting
+on it.
+
+**Voting members are chosen by voting.** Candidates are nominated by
+themselves or by voting members, with approval of candidate. Voting
+membership may not be inflicted upon anyone without their **explicit
+approval**.
+
+Voting membership may be revoked by a vote.
+
+No contributors or voting member is required to do work for the
+project, and the project cannot compel anyone to do anything. The
+project may, via a formal decision, forbid something from being done
+in the context of a project, or require that if a thing is done, it
+gets done in a particular way.
+
+
+Decision making
+-----------------------------------------------------------------------------
+
+Most decisions in the project are made by contributors as part of the
+work they do to contribute. These are called **mundane decisions**,
+and include things like how to structure a piece of code or
+documentation, how to name some component, etc. Mundane decisions do
+not normally need to be documented formally, but can be, if a
+contributor thinks it useful.
+
+If a mundane decision is challenged, the project aims to find a
+**rough consensus** on the matter via discussion. This is called a
+**consensus decision**. Consensus decisions are documented on a
+project website, and marked as such.
+
+To make rough consensus easier to achieve, the project follows the
+[lazy consensus][] approach. If you don't think a change is
+controversial, just do it. We use version control, changes are easy to
+revert. If you're not entirely sure, announce that you're going to
+make the change in three days, which gives everyone time to object.
+
+[lazy consensus]: https://rave.apache.org/docs/governance/lazyConsensus.html
+
+If consensus is not reached, or is challenged by a voting member, the
+project will **vote** on the matter. This is called a **formal
+decision**. Formal decisions are documented on a project website, and
+marked as such.
+
+
+Voting procedure
+-----------------------------------------------------------------------------
+
+The **project secretary** is chosen by voting by the voting members
+from among the voting members. The secretary must themselves be a
+voting member for the duration of their term. Candidates nominate
+themselves, or by other voting members with the candidate's approval.
+The secretary has the duty to conduct votes in a suitable manner.
+Votes are decided by **simple majority**, and voting members have an
+**equal vote**. In case of a tie, the project secretary casts the
+decisive vote.
+
+Voting members may suggest options for the ballot. The secretary
+decides what the ballot should be, announces the vote on a suitable
+project forum, and declares how a vote is to be cast. The **voting
+period is 7 days**. The secretary receives votes, counts them, and
+announces the result, and documents the decision on the project
+website. **Votes are made public** at that time, if not earlier.
+
+
+Team delegations
+-----------------------------------------------------------------------------
+
+Responsibility of making decisions about an area or aspect of the
+project may be **delegated to a team** by a vote among the voting
+members. The decision shall name all members of the team and the scope
+of the delegation. The team members may be any contributors, not just
+formal members. Decisions within the team are made in the same manner
+as by the project as a whole, with contributors voting as if they were
+voting members. The team's consensus and formal decisions shall be
+documented in the same way as project decisions. The project may
+override a team's decision via project vote.
+
+
+Time and term limitations
+-----------------------------------------------------------------------------
+
+Voting membership and the position of secretary and team delegations
+are **time limited**, and **expire automatically** with no further
+action. Memberships expire one by one in order of earliest membership
+first. The last membership does not expire, as that would leave the
+project without voters. If the project only has one voting member,
+that member is automatically also the secretary.
+
+The point of the automatic expiration is to avoid having inactive
+former contributors as voting members indefinitely.
+
+The **terms end on the following dates**, except terms do not end
+automatically within their first three months:
+
+- voting membership ends September 1
+- position of secretary ends March 1
+- team delegations ends June 1.
+
+On each date, the term ends at 23:59:59 in the UTC time zone.
+
+Voting membership, secretaryship, and team delegation may be renewed
+by a vote. There is no limit on how many times renewal may happen.
+
+Voting membership gets automatically renewed if the member has voted
+at least once in the preceding 12 months.
+
+It is the duty of the secretary to arrange new votes to renew terms in
+time before the terms end, and to maintain a list of voting
+memberships.
+
+
+Status
+-----------------------------------------------------------------------------
+
+The current project secretary is Lars Wirzenius.
+
+The complete list of voting members in the project (in order of
+joining):
+
+* Lars Wirzenius (expires 2019-09-01)
+
+See also:
+
+* list of [[consensus decisions|tag/consensus-decision]].
+* list of [[formal decisions|tag/formal-decision]].
+* list of [[votes|tag/vote]].