1 <?xml version=
"1.0" encoding=
"UTF-8"?>
3 <html xmlns=
"http://www.w3.org/1999/xhtml">
5 <h1>Project governance
</h1>
10 The libvirt project operates as a meritocratic, consensus-based community.
11 Anyone with an interest in the project can join the community, contributing
12 to the ongoing development of the project's work. This pages describes how
13 that participation takes place and how contributors earn merit, and thus
14 influence, within the community.
17 <h2><a id=
"codeofconduct">Code of conduct
</a></h2>
20 The libvirt project community covers people from a wide variety of
21 countries, backgrounds and positions. This global diversity is a great
22 strength of the project, but can also lead to communication issues,
23 which may in turn cause unhappiness. To maximise happiness of the
24 project community taken as a whole, all members (whether users,
25 contributors or committers) are expected to abide by the project's
26 code of conduct. At a high level the code can be summarized as
27 <em>"be excellent to each other"</em>. Expanding on this:
31 <li><strong>Be respectful:
</strong> disagreements between people are to
32 be expected and are usually the sign of healthy debate and engagement.
33 Disagreements can lead to frustration and even anger for some members.
34 Turning to personal insults, intimidation or threatening behaviour does
35 not improve the situation though. Participants should thus take care to
36 ensure all communications / interactions stay professional at all times.
</li>
38 <li><strong>Be considerate:
</strong> remember that the community has members
39 with a diverse background many of whom have English as a second language.
40 What might appear impolite, may simply be a result of a lack of knowledge
41 of the English language. Bear in mind that actions will have an impact
42 on other community members and the project as a whole, so take potential
43 consequences into account before pursuing a course of action.
</li>
45 <li><strong>Be forgiving:
</strong> humans are fallible and as such prone
46 to make mistakes and inexplicably change their positions at times. Don't
47 assume that other members are acting with malicious intent. Be prepared
48 to forgive people who make mistakes and assist each other in learning
49 from them. Playing a blame game doesn't help anyone.
</li>
52 <h2><a id=
"roles">Roles and responsibilities
</a></h2>
54 <h3><a href=
"users">Users
</a></h3>
57 The users are anyone who has a need for the output of the project.
58 There are no rules or requirements to become a user of libvirt. Even
59 if the software does not yet work on their OS platform, a person can
60 be considered a potential future user and welcomed to participate.
64 Participation by users is key to ensuring the project moves in the
65 right direction, satisfying their real world needs. Users are
66 encouraged to participate in the broader libvirt community in any
71 <li>Evangelism: spread the word about what libvirt is doing, how it
72 helps solve your problems. This can be via blog articles, social
73 media postings, video blogs, user group / conference presentations
74 and any other method of disseminating information
</li>
75 <li>Feedback: let the developers know about what does and does not
76 work with the project. Talk to developers on the project's
77 IRC channel and mailing list, or find them at conferences. Tell
78 them what gaps the project has or where they should look for
79 future development
</li>
80 <li>Moral support: developers live for recognition of the positive
81 impact their work has on users' lives. Give thanks to the developers
82 when evangelising the project, or when meeting them at user groups,
83 conferences, etc.
</li>
87 The above is not an exhaustive list of things users can do to
88 participate in the project. Further ideas and suggestions are
89 welcome. Users are encouraged to take their participation
90 further and become contributors to the project in any of the
91 ways listed in the next section.
94 <h3><a id=
"contributors">Contributors
</a></h3>
97 The contributors are community members who have some concrete impact
98 to the ongoing development of the project. There are many ways in which
99 members can contribute, with no requirement to be a software engineer.
100 Many users can in fact consider themselves contributors merely by
101 engaging in evangelism for the project.
105 <li>Bug reporting: improve the quality of the project by reporting
106 any problems found either to the project's own bug tracker, or to
107 that of the OS vendor shipping the libvirt code.
</li>
108 <li>User help: join the
<a href=
"contact.html">IRC channel or mailing list
</a>
109 to assist or advice other users in troubleshooting the problems they face.
</li>
110 <li>Feature requests: help set the direction for future work by
111 reporting details of features which are missing to the project's
112 own bug tracker or mailing lists.
</li>
113 <li>Graphical design: contribute to the development of the project's
114 websites / wiki brand with improved graphics, styling or layout.
</li>
115 <li>Code development: write and submit patches to address bugs or implement
117 <li>Architectural design: improve the usefulness of the project
118 by providing feedback on the design of proposed features, to
119 ensure they satisfy the broadest applicable needs and survive
121 <li>Code review: look at patches which are submitted and critique
122 the code to identify bugs, potential design problems or other
123 issues which should be addressed before the code is accepted
</li>
124 <li>Documentation: contribute to content on personal blogs, the
125 website, wiki, code comments, or any of the formal documentation
127 <li>Translation: join the Fedora transifex community to improve the
128 quality of translations needed by the libvirt project.
</li>
129 <li>Testing: try proposed patches or release candidates and report
130 whether the build passes and the changes work as expected.
</li>
134 The above is not an exhaustive list of things members can do to
135 contribute to the project. Further ideas and suggestions are
140 There are no special requirements to becoming a contributor other
141 than having the interest and ability to provide a contribution. The
142 libvirt project
<strong>does not require
</strong> any
143 <em>"Contributor License Agreement"</em>
144 to be signed prior to engagement with the community. However for
145 contributing patches, providing a 'Signed-off-by' line with the
146 author's legal name and e-mail address to demonstrate agreement
147 and compliance with the
<a href=
"https://developercertificate.org/">
148 Developer Certificate of Origin
</a> is required.
152 In making a non-patch contribution to the project, the community
153 member is implicitly stating that they accept the terms of the license
154 under which the work they are contributing to is distributed. They are
155 also implicitly stating that they have the legal right to make the
156 contribution, if doing so on behalf of a broader organization /
157 company. Most of the project's code is distributed under the GNU
158 Lesser General Public License, version
2.1 or later. Details of the
159 exact license under which contributions will be presumed to be
160 covered are found in the source repositories, or website in question.
163 <h3><a id=
"committers">Committers
</a></h3>
166 The committers are the subset of contributors who have direct access
167 to commit code to the project's primary source code repositories, which
168 are currently using the GIT software. The committers are chosen based
169 on the quality of their contributions over a period of time. This includes
170 both the quality of code they submit, as well as the quality of reviews
171 they provide on other contributors' submissions and a demonstration that
172 they understand day-to-day operation of the project and its goals. There
173 is no minimum level of contribution required in order to become a committer,
174 though
2-
3 months worth of quality contribution would be a rough guide.
178 There are no special requirements to becoming a committer other than to
179 have shown a willingness and ability to contribute to the project over
180 an extended period of time. Proposals for elevating contributors to
181 committers are typically made by existing committers, though contributors
182 are also welcome to make proposals. The decision to approve the elevation
183 of a contributor to a committer is made through
"rough consensus" between
184 the existing committers.
188 The aim in elevating contributors to committers is to ensure that there
189 is a broad base of experience and expertize across all areas of the
190 project's work. Committers are not required to have knowledge across
191 all areas of the project's work. While an approved committer has the
192 technical ability to commit code to any area of the project, by convention
193 they will only commit to areas they feel themselves to be qualified to
194 evaluate the contribution. If in doubt, committers will defer to the
195 opinion of other committers with greater expertize in an area.
199 The committers hold the ultimate control over what contributions are
200 accepted by the project, however, this does not mean they have the
201 right to do whatever they want. Where there is debate and disagreement
202 between contributors, committers are expected to look at the issues with
203 an unbiased point of view and help achieve a
"rough consensus". If the
204 committer has a conflict of interest in the discussion, for example due
205 to their position of employment, they are expected to put the needs of
206 the community project first. If they cannot put the community project
207 first, they must declare their conflict of interest, and allow other
208 non-conflicted committers to make any final decision.
212 The committers are expected to monitor contributions to areas of the
213 project where they have expertize and ensure that either some form of
214 feedback is provided to the contributor, or to accept their contribution.
215 There is no formal minimum level of approval required to accept a
216 contribution. Positive review by any committer experienced in the area
217 of work is considered to be enough to justify acceptance in normal
218 circumstances. Where one committer explicitly rejects a contribution,
219 however, other committers should not override that rejection without
220 first establishing a
"rough consensus" amongst the broader group of
225 Being a committer is a privilege, not a right. In exceptional
226 circumstances, the privilege may be removed from an active
227 contributor. Such decisions will be taken based on
"rough
228 consensus" amongst other committers. In the event that a committer
229 is no longer able to participate in the project, after some period
230 of inactivity passes, they may be asked to confirm that they wish
231 to retain their role as a committer.
234 <h3><a id=
"secteam">Security team
</a></h3>
237 The security team consists of a subset of the project committers
238 along with representatives from vendors shipping the project's
239 software. The subset of project committers is chosen to be the
240 minimal size necessary to provide expertise spanning most of
241 the project's work. Further project committers may be requested
242 to engage in resolving specific security issues on a case by
243 case basis. Any vendor who is shipping the project's software
244 may submit a request for one or more of their representatives
245 to join the security team. Such requests must by approved by
246 existing members of the team vouching for the integrity of
247 the nominated person or organization.
251 Members of the security team are responsible for triaging and
252 resolving any security issues that are reported to the project.
253 They are expected to abide by the project's documented
254 <a href=
"securityprocess.html">security process
</a>. In particular
255 they must respect any embargo period agreed amongst the team
256 before disclosing a private issue.
259 <h2><a id=
"roughconsensus">Rough consensus
</a></h2>
262 A core concept for governance of the project described above is
263 that of
"rough consensus". To expand on this, it is a process
264 of decision making that involves the following steps
270 <li>Vote (exceptional circumstances only)
</li>
275 To put this into words, any contributor is welcome to make a proposal
276 for consideration. Any contributor may participate in the discussions
277 around the proposal. The discussion will usually result in agreement
278 between the interested parties, or at least agreement between the
279 committers. Only in the very exceptional circumstance where there
280 is disagreement between committers, would a vote be considered.
281 Even in these exceptional circumstances, it is usually found to be
282 obvious what the majority opinion of the committers is. In the event
283 that even a formal vote is tied, the committers will have to hold
284 ongoing discussions until the stalemate is resolved or the proposal
289 The overall goal of the
"rough consensus" process is to ensure that
290 decisions can be made within the project, with a minimum level of
291 bureaucracy and process. Implicit in this is that any person who does
292 not explicitly reject to a proposal is assumed to be supportive, or