This document is a work in progress and hasn't been accepted by every registered developer yet.
There are a number of roles in the project management of EdgeBSD.
The EdgeBSD leader dictates the tentative vision and orientation of the project. He has the final word in case of conflicts. The leader is also in charge of reviewing and accepting applications for developer status.
The leader is elected by the project developers, with the one collecting the most votes being appointed. Developers must have been part of the project for a year (365 days) before being allowed to vote. All votes are public. Votes can be cast during a voting period of one week (7 days).
The project leader may choose to step out at any time, and is free to choose an interim leader before new elections can be organized. New elections must be organized within three months (90 days).
The current leader is Pierre Pronchery <firstname.lastname@example.org>.
The masters are in charge of the current development effort around the project (the "master" branches). A lead master is appointed by the project leader (possibly assuming both positions), and will choose at least one other master for support.
Together, the masters are responsible for both:
- importing the latest versions for third-party software;
- mergeing work from the various branches hosted by EdgeBSD.
Masters should not import their own work into the current branches (except for the lead master). Masters must be developers of the project.
Releasers are responsible for the continuous release status of the stable branches. Their main task is to import fixes to the branches (when appropriate), as requested by users and developers of the project. Releasers can be added and removed at any time by both the project leader and the lead master, with the project leader having the final word in case of any disagreement. A lead releaser has to be named, and will likewise act as the reference in case of any conflict.
It is up to the releasers' team to elect their lead; this election can be invalidated by either the lead master or the project leader. All votes are public.
Releasers should not import their own work into the stable branches (except for the lead releaser). Releasers must be developers of the project.
Developers are users with the care and ability to actively help the project in any way. Anyone can apply to become a developer. Applications have to be sent to the project's official address <email@example.com> or to the project leader (possibly by means of a mailing-list).
Developers are listed publicly, and are identified by a full name, login and SSH public key. Only human beings are currently accepted as official developers, although other conscious living species may apply (if they are able to cater for their own, private SSH key).
Users are the most important members of the project. Membership is informal and can be considered granted by subscribing to the website, or to any mailing-list hosted by the project. Each member has to act sincerely, respectfully and willingly, considering the needs and desires of fellow members just as much as their own. Membership can be revoked at any point by the project leader, without requiring any public justification.
Aspiring developers have to be members to apply.
Last but not least, the project leader should nominate a security officer whenever resources allow it. The security officer is in charge of choosing up to three other developers to participate to the security team.
The security team is in charge of collecting, researching and addressing security concerns, pressuring the other teams or developers to act on potential and confirmed issues. Subsequently fixed issues must be communicated publicly and formally in the format of an advisory. Communication to and within the team should however be confidential and encrypted whenever feasible. The official address to reach the team is <firstname.lastname@example.org>.