summaryrefslogtreecommitdiff
path: root/governance.mdwn
blob: b2700ab93684ed67592ede1f75ca40678e0d99c6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
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]].