Add: governance draft

1 files changed, 125 insertions, 0 deletions

diff --git a/governance.mdwn b/governance.mdwn
new file mode 100644
index 0000000..04e4e57
--- /dev/null
+++ b/governance.mdwn
@@ -0,0 +1,125 @@
+[[!meta title="Ick—governance"]]
+
+
+> **THIS IS A DRAFT. IT IS NOT OFFICIAL YET.**
+
+
+Ick constitution
+=============================================================================
+
+Introduction
+-----------------------------------------------------------------------------
+
+This constitution is the formal rules of the Ick project. The Ick
+project develops the Ick software, for continuous integration. 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.
+
+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 Ick 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.
+
+This constitution and formal decisions are binding to voting members,
+but do not impose an obligation to do any work for the project.
+
+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 the
+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.
+
+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. 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.
+
+Time and term limitations
+-----------------------------------------------------------------------------
+
+Voting membership and the position of secretary and team delegations
+are **time limited**, and **expire automatically** with no further
+action. The excpetion is that if a voting member's membership will not
+expire if they are the only voting member.
+
+The **terms end on the following dates**, the next time that date
+comes after three months after the term starts:
+
+- 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 happens. The
+point of the automatic expiration is to avoid having inactive former
+contributors as voting members indefinitely.
+
+It is the duty of the secretary to arrange new votes to renew terms in
+time before the terms end.
+
+
+Other Ick governance
+=============================================================================
+
+* Technical policy: how the software gets developed, programming
+  languages, version control, issue tracking, website maintenance,
+  etc. This will be decided by the project following procedures
+  specified by the constitution.
+
+* Code of conduct: This will be a formal project decision. A delegated
+  team may be given responsibility of enforcement. I'm personally in
+  favour of something like what Gitano uses.