forked from CGAL/cgal-web
-
Notifications
You must be signed in to change notification settings - Fork 0
/
project_rules.html
315 lines (266 loc) · 12.2 KB
/
project_rules.html
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
---
layout: page
title: CGAL Open Source Project Rules and Procedures
header: CGAL Open Source Project Rules and Procedures</h1>
group: navigation
---
{% include JB/setup %}
<ul>
<li><a href="#preamble">Preamble</a></li>
<li><a href="#groups">Groups</a></li>
<li><a href="#developers">Developers</a></li>
<li><a href="#editors">Editorial Board</a></li>
<li><a href="#boardmanager">Board Manager</a>
<li><a href="#reviewmanager">Review Manager</a></li>
<li><a href="#releasemanager">Release Manager</a></li>
<li><a href="#voting">Decision Procedures</a></li>
<li><a href="#change">Change of Rules and Procedures</a></li>
</ul>
<p><hr><p>
<!-- -->
<h3 id="preamble">Preamble</h3>
<p>With this document, the CGAL Open Source Project sets forth its own
rules and procedures. The rules and procedures define the different
groups of persons involved in CGAL, how to become one of them, and how
decisions are made. This document regulates how important and final
decisions are made by the editorial board. It does not cover the less
formal way how many decisions are actually made among developers, and
it is not the intention to regulate those. There is no precise
definition, but some examples of decisions that should be handled by
the editorial board are given throughout this document.</p>
<p><hr><p>
<!-- -->
<h3 id="groups">Groups</h3>
<p>The CGAL Open Source Project consists of four groups of people
based on technical criteria and relation to CGAL.</p>
<ul>
<li><b>Users</b> are using CGAL and, for example, are
active on the <tt>cgal-discuss</tt> user mailing list
including bug reports.</li>
<li><b>Contributors</b> are users of CGAL that contribute
to CGAL with patches to fix bugs or to improve CGAL. Contributors
shall be listed in acknowledgements.</li>
<li><b>Developers</b> are working on CGAL packages, have
access to the member resources, and write access to
the CGAL SCM server for their packages.</li>
<li><b>Editors</b> are experienced developers that take
long term responsibility for the project. See the corresponding
<a href="#editors">Editorial Board Section</a> for more details.</li>
</ul>
<p>
(Financing the people, the project, or other types of resources is not
discussed in this document, but see <a href="partners.html">here</a>, and the
current list of people can be found <a href="people.html">here</a>.)
</p>
<p><hr><p>
<!-- -->
<h3 id="developers">Developers</h3>
<p>A <em>developer</em> is a person that develops at least one CGAL
package. He/she has access to the member resources of the CGAL
project. He/she has write access on the CGAL SCM server for
his/her package(s).</p>
<p>A candidate becomes a developer after a proposal (short description
of the project the candidate developer is working on) from an
editorial board member and no objection by any editor within fifteen
days. If an objection is raised, the matter is to be discussed in the
editorial board and the decision is made by an anonymous vote; <a
href="#absolute">absolute majority</a> is required for the candidate
to become a developer.</p>
<p>A person seizes to be a developer after either his/her personal
request or upon proposal of an editorial board member and a subsequent
anonymous vote with an <a href="#absolute">absolute majority</a>.</p>
<p><hr><p>
<!-- -->
<h3 id="editors">Editorial Board</h3>
<h4>Responsibilities</h4>
<ul>
<li>Review submitted packages (see the <a href="./review_process_rules.html">Submission and Review Rules</a>).</li>
<li>Take long term responsibilities for the CGAL project.</li>
<li>Represent the project towards its <a href="partners.html">partners</a>, external organizations and other software projects.</li>
<li>Suggest medium or long term directions for the CGAL project.</li>
<li>Promote CGAL.</li>
<li>Discuss any issue regarding the interests of the project.</li>
<li>Attract new contributors.</li>
<li>Act as a Board Manager when called upon.</li>
<li>Vote on proposals, which is compulsory.</li>
<li>Communicate to the rest of the board their availability,
especially if absent for more than a week.</li>
</ul>
<h4>Becoming an Editor</h4>
<p>A candidate is considered for becoming an editor upon recommendation
by an existing editor. The criteria for selection are:</p>
<ul>
<li>Candidates have successfully developed or
maintained a CGAL package for at least a year.</li>
<li>Candidates have been active participants in CGAL
developer meetings.</li>
<li>Candidates have shown interest in at least two areas
within CGAL.</li>
<li>Candidates have contributed to the service tasks in CGAL,
such as: development of tools, maintenance, testing, porting
to other platforms.</li>
<li>Candidates have an appropriate educational/technical
qualification, such as an academic degree at the level of an M.S.
or equivalent.</li>
</ul>
<p>In addition to above criteria, the editorial board considers also
the following criteria:</p>
<ul>
<li>The CGAL areas covered by the members of the existing
editorial board.</li>
<li>The size of the editorial board.</li>
<li>The representation of the developing sites/groups in the
editorial board.</li>
</ul>
<p>The criteria described above are guidelines. The editorial board
discusses the candidacy and makes the final decision by an anonymous
vote; a <a href="#twothirds">two-thirds majority</a> is needed for a
candidate to become an editor</p>
<h4>Leaving the Editorial Board</h4>
<p>An editor leaves the editorial board after either his/her personal
request or upon proposal of an editorial board member and a subsequent
anonymous vote with a <a href="#twothirds">two-thirds majority</a>.
Such a proposal may for example be motivated by the repeated failure of an
editor to fill his duties.</p>
<h4>Dedicated Positions in the Editorial Board</h4>
<p>Editors might hold special task-related positions in the editorial
board, such as:</p>
<ul>
<li><em>Board Manager</em>, detailed <a href="#boardmanager">below</a></li>
<li><em>Review Manager</em>, detailed <a href="#reviewmanager">below</a></li>
<li><em>Release Manager</em>, detailed <a href="#releasemanager">below</a></li>
<li><em>Editor(s)</em> for special issues of journals etc.</li>
<li><em>Public relations</em> communication with
the users, up-to-date representation/poster for CGAL,
CGAL newsletter, etc.</li>
<li><em>Legal issues</em> licenses, compatibility between
licenses, contributions by multiple sites, etc.</li>
<li><em>Answer requests</em> from <tt>cgal-info</tt>.</li>
</ul>
<p>Appointment for the position of <a href="#boardmanager">board
manager</a> is done for a period of six months following a round-robin
process.</p>
<p>Appointments for the positions of <a href="#reviewmanager">review
manager</a> and <a href="#releasemanager">release manager</a> are done
for a period of 2 years. The <a href="#boardmanager">board
manager</a> organizes elections for these two
positions. In a two weeks period new candidates announce their
candidacy and an editor for organizing the election and collecting the
votes is determined.</p>
<p>A decision for these positions requires <a href="#absolute">absolute
majority</a>. If <a href="#absolute">absolute majority</a> was not
reached in the first election round and we have more than one
candidate, more election rounds are held. If we have more than two
candidates, all candidates with less votes than the two highest
ranking candidates are excluded and we repeat the first election
round. If we have two candidates, a decision in a
second election round requires only <a href="#relative">relative
majority</a>. This round can be skipped if the candidate with less
votes in round one accepts this result on the basis of <a
href="#relative">relative majority</a>.</p>
<p><hr><p>
<!-- -->
<h3 id="boardmanager">Board Manager</h3>
<h4>Responsibilities</h4>
<ul>
<li>Acting towards reaching decisions.
<li>Organizing elections and votes: calling for votes,
appointing an editor for collecting anonymous votes, and
giving a time frame.
<li>Appointing representatives for arising tasks.
<li>Finding a replacement board manager when absent.
<li>Sending acknowledgements for messages sent to the editorial board
mailing list by external people.
</ul>
<p><hr><p>
<!-- -->
<h3 id="reviewmanager">Review Manager</h3>
<h4>Responsibilities</h4>
<ul>
<li>Supervizing the reviewing process.
<li>Acknowledging the reception of submissions towards the authors.
<li>Finding primary reviewers, assigning time periods for reviews.
<li>Making sure the reviews are done in a timely fashion, and
propose counter action otherwise.
<li>Maintaining a summary of the current status of the reviews
(web page, wiki or tracker...).
<li>Making sure that the outcome of the reviews is properly
communicated.
</ul>
<p><hr><p>
<!-- -->
<h3 id="releasemanager">Release Manager</h3>
<h4>Responsibilities</h4>
<ul>
<li>Supervizing the releasing process.
<li>Proposing release schedules.
<li>Making sure that releases are issued in a timely fashion.
<li>Communicating regularly on the developers mailing-list the
upcoming deadlines of the release schedule, and sending
status updates for the upcoming releases.
<li>Discussing an integration path and schedule with
developers of new packages once they have been accepted by
the reviewing process.
<li>Watching for ongoing developments, e.g. through the
test-suites, and communicating with their developers, in
order to avoid missing the deadlines.
<li>Ensuring that deadlines are met, and propose actions to
reach this goal.
</ul>
<p><hr><p>
<!-- -->
<h3 id="voting">Decision Procedures</h3>
<p>Votes for a decision are initiated with a proposal by an
editor. Decisions that are not specifically covered elsewhere in this
document need an <a href="#absolute">absolute majority</a>.</p>
<p>Votes on personnel decisions are anonymous. An editor is appointed
to collect such votes (and systematically confirms them to avoid mails
getting lost) and announce the result, see also the role of
the <a href="#boardmanager">Board Manager</a>
in these matters. Proposals specify a deadline for voting, usually two
weeks and respecting usual vacation and holiday times and editors that
announced their absence. Votes that are not casted within the time
frame are counted as abstention. The editor appointed to collect
anonymous votes will also provide the names of the editors who did not
vote.</p>
<p>The voting choices in a proposals need to be phrased in a manner
that abstention has no influence, in particular, abstention does not
support a change of an existing status.</p>
<p>Let <i>N</i> be the cardinality of the current editorial
board. We distinguish the following definitions of majorities:</p>
<ul>
<li id="relative">
<b>Relative majority:</b> the number of votes for a
decision is strictly larger than the number of votes for any
other choice.</li>
<li id="absolute">
<b>Absolute majority:</b> the number of votes for a
decision is strictly larger than <i>N/2</i>.</li>
<li id="twothirds">
<b>Two-thirds majority:</b> the number of votes for a
decision is larger or equal than <i>2*N/3</i>.</li>
</ul>
<p><hr><p>
<!-- -->
<h3 id="change">Change of Rules and Procedures</h3>
<p>A <a href="#twothirds">two-thirds majority</a> is needed to change
any part of this document.</p>
<hr>
<div style="font-style: italic;">
<h3>Note</h3>
<p>
This document was started at the SoCG meeting 2004 in New York and
refined subsequently under the guiding principle of not to
over-specify our procedures but rather to refine them when the need
arises. After a period of internal evaluation, including an election
for a new editor and an election for a new chair, the editors approved
this document in an unanimous vote on October 28,
2005.
<br>On March 5, 2009, the roles of Editor-in-Chief and Release Manager
were created after an unanimous vote.
<br> During the 30th Developer Meeting, on June 4, 2010, in Sophia
Antipolis, the Editorial Board decided by two-thirds majority to
remodel the position of Chair, and to rename the positions of Chair
and Editor-in-chief to Board Manager and Review Manager, respectively.
</p>
</div>