CGAL Open Source Project Rules and Procedures

• Preamble
• Groups
• Developers
• Editorial Board
• Board Manager
• Review Manager
• Release Manager
• Decision Procedures
• Change of Rules and Procedures

Preamble

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.

Groups

The CGAL Open Source Project consists of four groups of people based on technical criteria and relation to CGAL.

• Users   are using CGAL and, for example, are active on the cgal-discuss user mailing list including bug reports.
• Contributors   are users of CGAL that contribute to CGAL with patches to fix bugs or to improve CGAL. Contributors shall be listed in acknowledgements.
• Developers   are working on CGAL packages, have access to the member resources, and write access to the CGAL SCM server for their packages.
• Editors   are experienced developers that take long term responsibility for the project. See the corresponding Editorial Board Section for more details.

(Financing the people, the project, or other types of resources is not discussed in this document, but see here, and the current list of people can be found here.)

Developers

A developer 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).

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; absolute majority is required for the candidate to become a developer.

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 absolute majority.

Editorial Board

Responsibilities

• Review submitted packages (see the Submission and Review rules).
• Take long term responsibilities for the CGAL project.
• Represent the project towards its partners, external organizations and other software projects.
• Suggest medium or long term directions for the CGAL project.
• Promote CGAL.
• Discuss any issue regarding the interests of the project.
• Attract new contributors.
• Act as a Board Manager when called upon.
• Vote on proposals, which is compulsory.
• Communicate to the rest of the board their availability, especially if absent for more than a week.

Becoming an Editor

A candidate is considered for becoming an editor upon recommendation by an existing editor. The criteria for selection are:

• Candidates have successfully developed or maintained a CGAL package for at least a year.
• Candidates have been active participants in CGAL developer meetings.
• Candidates have shown interest in at least two areas within CGAL.
• Candidates have contributed to the service tasks in CGAL, such as: development of tools, maintenance, testing, porting to other platforms.
• Candidates have an appropriate educational/technical qualification, such as an academic degree at the level of an M.S. or equivalent.

In addition to above criteria, the editorial board considers also the following criteria:

• The CGAL areas covered by the members of the existing editorial board.
• The size of the editorial board.
• The representation of the developing sites/groups in the editorial board.

The criteria described above are guidelines. The editorial board discusses the candidacy and makes the final decision by an anonymous vote; a two-thirds majority is needed for a candidate to become an editor

Leaving the Editorial Board

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 two-thirds majority. Such a proposal may for example be motivated by the repeated failure of an editor to fill his duties.

Dedicated Positions in the Editorial Board

Editors might hold special task-related positions in the editorial board, such as:

• Board Manager, detailed below
• Review Manager, detailed below
• Release Manager, detailed below
• Editor(s) for special issues of journals etc.
• Public relations communication with the users, up-to-date representation/poster for CGAL, CGAL newsletter, etc.
• Legal issues licenses, compatibility between licenses, contributions by multiple sites, etc.
• Answer requests from cgal-info.

Appointment for the position of board manager is done for a period of six months following a round-robin process.

Appointments for the positions of review manager and release manager are done for a period of 2 years. The board manager 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.

A decision for these positions requires absolute majority. If absolute majority 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 relative majority. This round can be skipped if the candidate with less votes in round one accepts this result on the basis of relative majority.

Board Manager

Responsibilities

• Acting towards reaching decisions.
• Organizing elections and votes: calling for votes, appointing an editor for collecting anonymous votes, and giving a time frame.
• Appointing representatives for arising tasks.
• Finding a replacement board manager when absent.
• Sending acknowledgements for messages sent to the editorial board mailing list by external people.

Review Manager

Responsibilities

• Supervizing the reviewing process.
• Acknowledging the reception of submissions towards the authors.
• Finding primary reviewers, assigning time periods for reviews.
• Making sure the reviews are done in a timely fashion, and propose counter action otherwise.
• Maintaining a summary of the current status of the reviews (web page, wiki or tracker...).
• Making sure that the outcome of the reviews is properly communicated.

Release Manager

Responsibilities

• Supervizing the releasing process.
• Proposing release schedules.
• Making sure that releases are issued in a timely fashion.
• Communicating regularly on the developers mailing-list the upcoming deadlines of the release schedule, and sending status updates for the upcoming releases.
• Discussing an integration path and schedule with developers of new packages once they have been accepted by the reviewing process.
• Watching for ongoing developments, e.g. through the test-suites, and communicating with their developers, in order to avoid missing the deadlines.
• Ensuring that deadlines are met, and propose actions to reach this goal.

Decision Procedures

Votes for a decision are initiated with a proposal by an editor. Decisions that are not specifically covered elsewhere in this document need an absolute majority.

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 Board Manager 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.

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.

Let N be the cardinality of the current editorial board. We distinguish the following definitions of majorities:

• Relative majority:   the number of votes for a decision is strictly larger than the number of votes for any other choice.
• Absolute majority:   the number of votes for a decision is strictly larger than N/2.
• Two-thirds majority:   the number of votes for a decision is larger or equal than 2*N/3.

Change of Rules and Procedures

A two-thirds majority is needed to change any part of this document.