diff options
author | Lars Wirzenius <liw@liw.fi> | 2018-09-08 13:05:17 +0300 |
---|---|---|
committer | Lars Wirzenius <liw@liw.fi> | 2018-09-08 13:05:17 +0300 |
commit | 5d33aa0122816ab8eaae95c0a8c49d3c75c42614 (patch) | |
tree | 5cab9e5a5084725e090ac25ac94da1dfaf3f13e2 /governance.mdwn | |
parent | d56088dd3ef4b1899012dab7c456c1286b7e9eb9 (diff) | |
download | vmdb2.liw.fi-5d33aa0122816ab8eaae95c0a8c49d3c75c42614.tar.gz |
Add: more content
Diffstat (limited to 'governance.mdwn')
-rw-r--r-- | governance.mdwn | 160 |
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]]. |