Ick constitution v1.0

Introduction

This constitution is the formal rules of the Ick project: it defines how we govern the 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.

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.

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.

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.

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)
  • Daniel Silverstone (expires 2019-09-01)

See also: