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
394
395
396
397
398
|
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Convention for heading levels in Open vSwitch documentation:
======= Heading 0 (reserved for the title in a document)
------- Heading 1
~~~~~~~ Heading 2
+++++++ Heading 3
''''''' Heading 4
Avoid deeper levels because they do not render well.
=====================================
OVS Committer Grant/Revocation Policy
=====================================
An OVS committer is a participant in the project with the ability to commit
code directly to the master repository. Commit access grants a broad ability to
affect the progress of the project as presented by its most important artifact,
the code and related resources that produce working binaries of Open vSwitch.
As such it represents a significant level of trust in an individual's
commitment to working with other committers and the community at large for the
benefit of the project. It can not be granted lightly and, in the worst case,
must be revocable if the trust placed in an individual was inappropriate.
This document suggests guidelines for granting and revoking commit access. It
is intended to provide a framework for evaluation of such decisions without
specifying deterministic rules that wouldn't be sensitive to the nuance of
specific situations. In the end the decision to grant or revoke committer
privileges is a judgment call made by the existing set of committers.
Granting Commit Access
----------------------
Granting commit access should be considered when a candidate has demonstrated
the following in their interaction with the project:
- Contribution of significant new features through the patch submission
process where:
- Submissions are free of obvious critical defects
- Submissions do not typically require many iterations of improvement
to be accepted
- Consistent participation in code review of other's patches, including
existing committers, with comments consistent with the overall project
standards
- Assistance to those in the community who are less knowledgeable through
active participation in project forums such as the ovs-discuss mailing list.
- Plans for sustained contribution to the project compatible with the project's
direction as viewed by current committers.
- Commitment to meet the expectations described in the "Expectations of
Developer's with Open vSwitch Access"
The process to grant commit access to a candidate is simple:
- An existing committer nominates the candidate by sending an email to all
existing committers with information substantiating the contributions of the
candidate in the areas described above.
- All existing committers discuss the pros and cons of granting commit
access to the candidate in the email thread.
- When the discussion has converged or a reasonable time has elapsed without
discussion developing (e.g. a few business days) the nominator calls for a
final decision on the candidate with a followup email to the thread.
- Each committer may vote yes, no, or abstain by replying to the email thread.
A failure to reply is an implicit abstention.
- After votes from all existing committers have been collected or a reasonable
time has elapsed for them to be provided (e.g. a couple of business days) the
votes are evaluated. To be granted commit access the candidate must receive
yes votes from a majority of the existing committers and zero no votes. Since
a no vote is effectively a veto of the candidate it should be accompanied by
a reason for the vote.
- The nominator summarizes the result of the vote in an email to all existing
committers.
- If the vote to grant commit access passed, the candidate is contacted with an
invitation to become a committer to the project which asks them to agree to
the committer expectations documented on the project web site.
- If the candidate agrees access is granted by setting up commit access to the
repos on github.
Revoking Commit Access
----------------------
There are two situations in which commit access might be revoked.
The straightforward situation is a committer who is no longer active in the
project and has no plans to become active in the near future. The process in
this case is:
- Any time after a committer has been inactive for more than 6 months any other
committer to the project may identify that committer as a candidate for
revocation of commit access due to inactivity.
- The plans of revocation should be sent in a private email to the candidate.
- If the candidate for removal states plans to continue participating no action
is taken and this process terminates.
- If the candidate replies they no longer require commit access then commit
access is removed and a notification is sent to the candidate and all
existing committers.
- If the candidate can not be reached within 1 week of the first attempting to
contact this process continues.
- A message proposing removal of commit access is sent to the candidate and all
other committers.
- If the candidate for removal states plans to continue participating no
action is taken.
- If the candidate replies they no longer require commit access then their
access is removed.
- If the candidate can not be reached within 2 months of the second
attempting to contact them, access is removed.
- In any case, where access is removed, this fact is published through an email
to all existing committers (including the candidate for removal).
The more difficult situation is a committer who is behaving in a manner that is
viewed as detrimental to the future of the project by other committers. This is
a delicate situation with the potential for the creation of division within the
greater community and should be handled with care. The process in this case is:
- Discuss the behavior of concern with the individual privately and explain why
you believe it is detrimental to the project. Stick to the facts and keep the
email professional. Avoid personal attacks and the temptation to hypothesize
about unknowable information such as the other's motivations. Make it clear
that you would prefer not to discuss the behavior more widely but will have
to raise it with other contributors if it does not change. Ideally the
behavior is eliminated and no further action is required. If not,
- Start an email thread with all committers, including the source of the
behavior, describing the behavior and the reason it is detrimental to the
project. The message should have the same tone as the private discussion and
should generally repeat the same points covered in that discussion. The
person whose behavior is being questioned should not be surprised by anything
presented in this discussion. Ideally the wider discussion provides more
perspective to all participants and the issue is resolved. If not,
- Start an email thread with all committers except the source of the
detrimental behavior requesting a vote on revocation of commit
rights. Cite the discussion among all committers and describe all the
reasons why it was not resolved satisfactorily. This email should be
carefully written with the knowledge that the reasoning it contains
may be published to the larger community to justify the decision.
- Each committer may vote yes, no, or abstain by replying to the email
thread. A failure to reply is an implicit abstention.
- After all votes have been collected or a reasonable time has elapsed
for them to be provided (e.g. a couple of business days) the votes
are evaluated. For the request to revoke commit access for the
candidate to pass it must receive yes votes from two thirds of the
existing committers.
- anyone that votes no must provide their reasoning, and
- if the proposal passes then counter-arguments for the reasoning in no
votes should also be documented along with the initial reasons the
revocation was proposed. Ideally there should be no new
counter-arguments supplied in a no vote as all concerns should have
surfaced in the discussion before the vote.
- The original person to propose revocation summarizes the result of
the vote in an email to all existing committers excepting the
candidate for removal.
- If the vote to revoke commit access passes, access is removed and the
candidate for revocation is informed of that fact and the reasons for
it as documented in the email requesting the revocation vote.
- Ideally the revoked committer peacefully leaves the community and no
further action is required. However, there is a distinct possibility
that he/she will try to generate support for his/her point of view
within the larger community. In this case the reasoning for removing
commit access as described in the request for a vote will be
published to the community.
Changing the Policy
-------------------
The process for changing the policy is:
- Propose the changes to the policy in an email to all current committers and
request discussion.
- After an appropriate period of discussion (a few days) update the proposal
based on feedback if required and resend it to all current committers with a
request for a formal vote.
- After all votes have been collected or a reasonable time has elapsed for them
to be provided (e.g. a couple of business days) the votes are evaluated. For
the request to modify the policy to pass it must receive yes votes from two
thirds of the existing committers.
Template Emails
===============
Nomination to Grant Commit Access
---------------------------------
::
I would like to nominate *[candidate]* for commit access. I believe
*[he/she]* has met the conditions for commit access described in the
committer grant policy on the project web site in the following ways:
*[list of requirements & evidence]*
Please reply to all in this message thread with your comments and
questions. If that discussion concludes favorably I will request a formal
vote on the nomination in a few days.
Vote to Grant Commit Access
---------------------------
::
I nominated *[candidate]* for commit access on *[date]*. Having allowed
sufficient time for discussion it's now time to formally vote on the
proposal.
Please reply to all in this thread with your vote of: YES, NO, or ABSTAIN.
A failure to reply will be counted as an abstention. If you vote NO, by our
policy you must include the reasons for that vote in your reply. The
deadline for votes is *[date and time]*.
If a majority of committers vote YES and there are zero NO votes commit
access will be granted.
Vote Results for Grant of Commit Access
---------------------------------------
::
The voting period for granting to commit access to *[candidate]* initiated
at *[date and time]* is now closed with the following results:
YES: *[count of yes votes]* (*[% of voters]*)
NO: *[count of no votes]* (*[% of voters]*)
ABSTAIN: *[count of abstentions]* (*[% of voters]*)
Based on these results commit access *[is/is NOT]* granted.
Invitation to Accepted Committer
--------------------------------
::
Due to your sustained contributions to the Open vSwitch (OVS) project we
would like to provide you with commit access to the project repository.
Developers with commit access must agree to fulfill specific
responsibilities described in the source repository:
/Documentation/committer-responsibilities.rst
Please let us know if you would like to accept commit access and if so that
you agree to fulfill these responsibilities. Once we receive your response
we'll set up access. We're looking forward continuing to work together to
advance the Open vSwitch project.
Proposal to Remove Commit Access for Inactivity
-----------------------------------------------
::
Committer *[candidate]* has been inactive for *[duration]*. I have
attempted to privately contacted *[him/her]* and *[he/she]* could not be
reached.
Based on this I would like to formally propose removal of commit access.
If a response to this message documenting the reasons to retain commit
access is not received by *[date]* access will be removed.
Notification of Commit Removal for Inactivity
---------------------------------------------
::
Committer *[candidate]* has been inactive for *[duration]*. *[He/she]*
*[stated no commit access is required/failed to respond]* to the formal
proposal to remove access on *[date]*. Commit access has now been removed.
Proposal to Revoke Commit Access for Detrimental Behavior
---------------------------------------------------------
::
I regret that I feel compelled to propose revocation of commit access for
*[candidate]*. I have privately discussed with *[him/her]* the following
reasons I believe *[his/her]* actions are detrimental to the project and we
have failed to come to a mutual understanding:
*[List of reasons and supporting evidence]*
Please reply to all in this thread with your thoughts on this proposal. I
plan to formally propose a vote on the proposal on or after *[date and
time]*.
It is important to get all discussion points both for and against the
proposal on the table during the discussion period prior to the vote.
Please make it a high priority to respond to this proposal with your
thoughts.
Vote to Revoke Commit Access
----------------------------
::
I nominated *[candidate]* for revocation of commit access on *[date]*.
Having allowed sufficient time for discussion it's now time to formally
vote on the proposal.
Please reply to all in this thread with your vote of: YES, NO, or ABSTAIN.
A failure to reply will be counted as an abstention. If you vote NO, by our
policy you must include the reasons for that vote in your reply. The
deadline for votes is *[date and time]*.
If 2/3rds of committers vote YES commit access will be revoked.
The following reasons for revocation have been given in the original
proposal or during discussion:
*[list of reasons to remove access]*
The following reasons for retaining access were discussed:
*[list of reasons to retain access]*
The counter-argument for each reason for retaining access is:
*[list of counter-arguments for retaining access]*
Vote Results for Revocation of Commit Access
--------------------------------------------
::
The voting period for revoking the commit access of *[candidate]* initiated
at *[date and time]* is now closed with the following results:
- YES: *[count of yes votes]* (*[% of voters]*)
- NO: *[count of no votes]* (*[% of voters]*)
- ABSTAIN: *[count of abstentions]* (*[% of voters]*)
Based on these results commit access *[is/is NOT]* revoked. The following
reasons for retaining commit access were proposed in NO votes:
*[list of reasons]*
The counter-arguments for each of these reasons are:
*[list of counter-arguments]*
Notification of Commit Revocation for Detrimental Behavior
----------------------------------------------------------
::
After private discussion with you and careful consideration of the
situation, the other committers to the Open vSwitch (OVS) project have
concluded that it is in the best interest of the project that your commit
access to the project repositories be revoked and this has now occurred.
The reasons for this decision are:
*[list of reasons for removing access]*
While your goals and those of the project no longer appear to be aligned we
greatly appreciate all the work you have done for the project and wish you
continued success in your future work.
|