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
|
[[!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.
|
