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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
|
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<!--
This file is autogenerated from governance.html.in
Do not edit this file. Changes will be lost.
-->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="SHORTCUT ICON" href="32favicon.png" />
<title>libvirt: Project governance</title>
<meta name="description" content="libvirt, virtualization, virtualization API" />
</head>
<body>
<div id="header">
<div id="headerLogo"></div>
<div id="headerSearch">
<form action="search.php" enctype="application/x-www-form-urlencoded" method="get"><div>
<input id="query" name="query" type="text" size="12" value="" />
<input id="submit" name="submit" type="submit" value="Search" />
</div></form>
</div>
</div>
<div id="body">
<div id="menu">
<ul class="l0"><li>
<div>
<a title="Front page of the libvirt website" class="inactive" href="index.html">Home</a>
</div>
</li><li>
<div>
<a title="Details of new features and bugs fixed in each release" class="inactive" href="news.html">News</a>
</div>
</li><li>
<div>
<a title="Applications known to use libvirt" class="inactive" href="apps.html">Applications</a>
</div>
</li><li>
<div>
<a title="Get the latest source releases, binary builds and get access to the source repository" class="inactive" href="downloads.html">Downloads</a>
</div>
</li><li>
<div>
<a title="Information for users, administrators and developers" class="active" href="docs.html">Documentation</a>
<ul class="l1"><li>
<div>
<a title="How to compile libvirt" class="inactive" href="compiling.html">Compiling</a>
</div>
</li><li>
<div>
<a title="Information about deploying and using libvirt" class="inactive" href="deployment.html">Deployment</a>
</div>
</li><li>
<div>
<a title="Overview of the logical subsystems in the libvirt API" class="inactive" href="intro.html">Architecture</a>
</div>
</li><li>
<div>
<a title="Description of the XML formats used in libvirt" class="inactive" href="format.html">XML format</a>
</div>
</li><li>
<div>
<a title="Hypervisor specific driver information" class="inactive" href="drivers.html">Drivers</a>
</div>
</li><li>
<div>
<a title="Reference manual for the C public API" class="inactive" href="html/index.html">API reference</a>
</div>
</li><li>
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li><li>
<div>
<a title="A guide and reference for developing with libvirt" class="inactive" href="devguide.html">Development Guide</a>
</div>
</li><li>
<div>
<a title="Command reference for virsh" class="inactive" href="virshcmdref.html">Virsh Commands</a>
</div>
</li><li>
<div>
<span class="active">Governance</span>
</div>
</li></ul>
</div>
</li><li>
<div>
<a title="User contributed content" class="inactive" href="http://wiki.libvirt.org">Wiki</a>
</div>
</li><li>
<div>
<a title="Frequently asked questions" class="inactive" href="http://wiki.libvirt.org/page/FAQ">FAQ</a>
</div>
</li><li>
<div>
<a title="How and where to report bugs and request features" class="inactive" href="bugs.html">Bug reports</a>
</div>
</li><li>
<div>
<a title="How to contact the developers via email and IRC" class="inactive" href="contact.html">Contact</a>
</div>
</li><li>
<div>
<a title="Available test suites for libvirt" class="inactive" href="testsuites.html">Test suites</a>
</div>
</li><li>
<div>
<a title="Miscellaneous links of interest related to libvirt" class="inactive" href="relatedlinks.html">Related Links</a>
</div>
</li><li>
<div>
<a title="Overview of all content on the website" class="inactive" href="sitemap.html">Sitemap</a>
</div>
</li></ul>
</div>
<div id="content">
<h1>Project governance</h1>
<ul><li>
<a href="#codeofconduct">Code of conduct</a>
</li><li>
<a href="#roles">Roles and responsibilities</a>
<ul><li>
<a href="#">Users</a>
</li><li>
<a href="#contributors">Contributors</a>
</li><li>
<a href="#committers">Committers</a>
</li><li>
<a href="#secteam">Security team</a>
</li></ul>
</li><li>
<a href="#roughconsensus">Rough consensus</a>
</li></ul>
<p>
The libvirt project operates as a meritocratic, consensus-based community.
Anyone with an interest in the project can join the community, contributing
to the ongoing development of the project's work. This pages describes how
that participation takes place and how contributors earn merit, and thus
influence, within the community.
</p>
<h2>
<a name="codeofconduct" shape="rect" id="codeofconduct">Code of conduct</a>
<a class="headerlink" href="#codeofconduct" title="Permalink to this headline">¶</a>
</h2>
<p>
The libvirt project community covers people from a wide variety of
countries, backgrounds and positions. This global diversity is a great
strength of the project, but can also lead to communication issues,
which may in turn cause unhappiness. To maximise happiness of the
project community taken as a whole, all members (whether users,
contributors or committers) are expected to abide by the project's
code of conduct. At a high level the code can be summarized as
<em>"be excellent to each other"</em>. Expanding on this:
</p>
<ul><li><strong>Be respectful:</strong> disagreements between people are to
be expected and are usually the sign of healthy debate and engagement.
Disagreements can lead to frustration and even anger for some members.
Turning to personal insults, intimidation or threatening behaviour does
not improve the situation though. Participants should thus take care to
ensure all communications / interactions stay professional at all times.</li><li><strong>Be considerate:</strong> remember that the community has members
with a diverse background many of whom have English as a second language.
What might appear impolite, may simply be a result of a lack of knowledge
of the English language. Bear in mind that actions will have an impact
on other community members and the project as a whole, so take potential
consequences into account before pursuing a course of action.</li><li><strong>Be forgiving:</strong> humans are fallible and as such prone
to make mistakes and inexplicably change their positions at times. Don't
assume that other members are acting with malicious intent. Be prepared
to forgive people who make mistakes and assist each other in learning
from them. Playing a blame game doesn't help anyone.</li></ul>
<h2>
<a name="roles" shape="rect" id="roles">Roles and responsibilities</a>
<a class="headerlink" href="#roles" title="Permalink to this headline">¶</a>
</h2>
<h3>
<a href="users" shape="rect">Users</a>
</h3>
<p>
The users are anyone who has a need for the output of the project.
There are no rules or requirements to become a user of libvirt. Even
if the software does not yet work on their OS platform, a person can
be considered a potential future user and welcomed to participate.
</p>
<p>
Participation by users is key to ensuring the project moves in the
right direction, satisfying their real world needs. Users are
encouraged to participate in the broader libvirt community in any
number of ways:
</p>
<ul><li>Evangelism: spread the word about what libvirt is doing, how it
helps solve your problems. This can be via blog articles, social
media postings, video blogs, user group / conference presentations
and any other method of disseminating information</li><li>Feedback: let the developers know about what does and does not
work with the project. Talk to developers on the project's
IRC channel and mailing list, or find them at conferences. Tell
them what gaps the project has or where they should look for
future development</li><li>Moral support: developers live for recognition of the positive
impact their work has on users' lives. Give thanks to the developers
when evangelising the project, or when meeting them at user groups,
conferences, etc.</li></ul>
<p>
The above is not an exhaustive list of things users can do to
participate in the project. Further ideas and suggestions are
welcome. Users are encouraged to take their participation
further and become contributors to the project in any of the
ways listed in the next section.
</p>
<h3>
<a name="contributors" shape="rect" id="contributors">Contributors</a>
<a class="headerlink" href="#contributors" title="Permalink to this headline">¶</a>
</h3>
<p>
The contributors are community members who have some concrete impact
to the ongoing development of the project. There are many ways in which
members can contribute, with no requirement to be a software engineer.
Many users can in fact consider themselves contributors merely by
engaging in evangelism for the project.
</p>
<ul><li>Bug reporting: improve the quality of the project by reporting
any problems found either to the project's own bug tracker, or to
that of the OS vendor shipping the libvirt code.</li><li>User help: join the <a href="contact.html" shape="rect">IRC channel or mailing list</a>
to assist or advice other users in troubleshooting the problems they face.</li><li>Feature requests: help set the direction for future work by
reporting details of features which are missing to the project's
own bug tracker or mailing lists.</li><li>Graphical design: contribute to the development of the project's
websites / wiki brand with improved graphics, styling or layout.</li><li>Code development: write and submit patches to address bugs or implement
new features</li><li>Architectural design: improve the usefulness of the project
by providing feedback on the design of proposed features, to
ensure they satisfy the broadest applicable needs and survive
the long term</li><li>Code review: look at patches which are submitted and critique
the code to identify bugs, potential design problems or other
issues which should be addressed before the code is accepted</li><li>Documentation: contribute to content on personal blogs, the
website, wiki, code comments, or any of the formal documentation
efforts.</li><li>Translation: join the Fedora transifex community to improve the
quality of translations needed by the libvirt project.</li><li>Testing: try proposed patches or release candidates and report
whether the build passes and the changes work as expected.</li></ul>
<p>
The above is not an exhaustive list of things members can do to
contribute to the project. Further ideas and suggestions are
welcome.
</p>
<p>
There are no special requirements to becoming a contributor other
than having the interest and ability to provide a contribution. The
libvirt project <strong>does not require</strong> any
<em>"Contributor License Agreement"</em>
to be signed prior to engagement with the community.
</p>
<p>
In making a contribution to the project, the community member is
implicitly stating that they accept the terms of the license under
which the work they are contributing to is distributed. They are
also implicitly stating that they have the legal right to make the
contribution, if doing so on behalf of a broader organization /
company. Most of the project's code is distributed under the GNU
Lesser General Public License, version 2 or later. Details of the
exact license under which contributions will be presumed to be
covered are found in the source repositories, or website in question.
</p>
<h3>
<a name="committers" shape="rect" id="committers">Committers</a>
<a class="headerlink" href="#committers" title="Permalink to this headline">¶</a>
</h3>
<p>
The committers are the subset of contributors who have direct access
to commit code to the project's primary source code repositories, which
are currently using the GIT software. The committers are chosen based
on the quality of their contributions over a period of time. This includes
both the quality of code they submit, as well as the quality of reviews
they provide on other contributors' submissions and a demonstration that
they understand day-to-day operation of the project and its goals. There
is no minimum level of contribution required in order to become a committer,
though 2-3 months worth of quality contribution would be a rough guide.
</p>
<p>
There are no special requirements to becoming a committer other than to
have shown a willingness and ability to contribute to the project over
an extended period of time. Proposals for elevating contributors to
committers are typically made by existing committers, though contributors
are also welcome to make proposals. The decision to approve the elevation
of a contributor to a committer is made through "rough consensus" between
the existing committers.
</p>
<p>
The aim in elevating contributors to committers is to ensure that there
is a broad base of experience and expertize across all areas of the
project's work. Committers are not required to have knowledge across
all areas of the project's work. While an approved committer has the
technical ability to commit code to any area of the project, by convention
they will only commit to areas they feel themselves to be qualified to
evaluate the contribution. If in doubt, committers will defer to the
opinion of other committers with greater expertize in an area.
</p>
<p>
The committers hold the ultimate control over what contributions are
accepted by the project, however, this does not mean they have the
right to do whatever they want. Where there is debate and disagreement
between contributors, committers are expected to look at the issues with
an unbiased point of view and help achieve a "rough consensus". If the
committer has a conflict of interest in the discussion, for example due
to their position of employment, they are expected to put the needs of
the community project first. If they cannot put the community project
first, they must declare their conflict of interest, and allow other
non-conflicted committers to make any final decision.
</p>
<p>
The committers are expected to monitor contributions to areas of the
project where they have expertize and ensure that either some form of
feedback is provided to the contributor, or to accept their contribution.
There is no formal minimum level of approval required to accept a
contribution. Positive review by any committer experienced in the area
of work is considered to be enough to justify acceptance in normal
circumstances. Where one committer explicitly rejects a contribution,
however, other committers should not override that rejection without
first establishing a "rough consensus" amongst the broader group of
committers.
</p>
<p>
Being a committer is a privilege, not a right. In exceptional
circumstances, the privilege may be removed from an active
contributor. Such decisions will be taken based on "rough
consensus" amongst other committers. In the event that a committer
is no longer able to participate in the project, after some period
of inactivity passes, they may be asked to confirm that they wish
to retain their role as a committer.
</p>
<h3>
<a name="secteam" shape="rect" id="secteam">Security team</a>
<a class="headerlink" href="#secteam" title="Permalink to this headline">¶</a>
</h3>
<p>
The security team consists of a subset of the project committers
along with representatives from vendors shipping the project's
software. The subset of project committers is chosen to be the
minimal size necessary to provide expertise spanning most of
the project's work. Further project committers may be requested
to engage in resolving specific security issues on a case by
case basis. Any vendor who is shipping the project's software
may submit a request for one or more of their representatives
to join the security team. Such requests must by approved by
existing members of the team vouching for the integrity of
the nominated person or organization.
</p>
<p>
Members of the security team are responsible for triaging and
resolving any security issues that are reported to the project.
They are expected to abide by the project's documented
<a href="securityprocess.html" shape="rect">security process</a>. In particular
they must respect any embargo period agreed amongst the team
before disclosing a private issue.
</p>
<h2>
<a name="roughconsensus" shape="rect" id="roughconsensus">Rough consensus</a>
<a class="headerlink" href="#roughconsensus" title="Permalink to this headline">¶</a>
</h2>
<p>
A core concept for governance of the project described above is
that of "rough consensus". To expand on this, it is a process
of decision making that involves the following steps
</p>
<ul><li>Proposal</li><li>Discussion</li><li>Vote (exceptional circumstances only)</li><li>Decision</li></ul>
<p>
To put this into words, any contributor is welcome to make a proposal
for consideration. Any contributor may participate in the discussions
around the proposal. The discussion will usually result in agreement
between the interested parties, or at least agreement between the
committers. Only in the very exceptional circumstance where there
is disagreement between committers, would a vote be considered.
Even in these exceptional circumstances, it is usually found to be
obvious what the majority opinion of the committers is. In the event
that even a formal vote is tied, the committers will have to hold
ongoing discussions until the stalemate is resolved or the proposal
withdrawn.
</p>
<p>
The overall goal of the "rough consensus" process is to ensure that
decisions can be made within the project, with a minimum level of
bureaucracy and process. Implicit in this is that any person who does
not explicitly reject to a proposal is assumed to be supportive, or
at least agnostic.
</p>
</div>
</div>
<div id="footer">
<p id="sponsor">
Sponsored by:<br /><a href="http://et.redhat.com/"><img src="et.png" alt="Project sponsored by Red Hat Emerging Technology" /></a></p>
</div>
</body>
</html>
|
