Project Roles¶
Project Owner¶
The Stormrose project and all child projects (i. e. including xobox) are owned by its founder, Jesco Freund (aka daemotron). The project owner has the final say in all matters, and can veto all core team decisions. Furthermore, the project owner is admonished to arbitrate in any dispute among core team members.
Note
This role may be subject to review, change or replacement in the future. Relieving the owner of any pecuniary and non-pecuniary engagement is considered as conditio sine qua non for this to happen.
Core Team¶
The core team is the group of people managing the project, and steering in which direction it goes. Core team members are expected to act as role models for the community and custodians of the project, on behalf of the community and all those who rely on Stormrose or any of its child projects.
Prerogatives¶
Core team members are formally entitled to exercise certain privileges, but are also asked to comply with requirements. Both are listed here:
- Core team members may participate in formal votes, typically to rule on matters (e. g. feature requests) or decide about new developers.
- In return, they are asked to avail themselves as mentors for new developers.
- Core team members are authorised to accept or reject pull requests for protected branches.
- Administrative privileges for other parts of the project’s infrastructure (e. g. the GitHub project group, tracker, servers, etc.) is granted as needed to core team members, based on assigned tasks. This means being a core team member does not automatically include receiving these privileges, but is sine qua non for receiving them if needed.
- In return, the core team is in charge of supporting operation of the Stormrose infrastructure.
Membership¶
Core team members are appointed by the project owner. For becoming a core team member candidate, a person needs to be nominated by a proponent already being a member of the core team, advocating in favour of this candidate becoming a core team member.
There is no time limit on core team membership. However, in order to provide the wider project stakeholders with a reasonable idea of who is maintaining the Stormrose applications, core team members who have stopped contributing are encouraged to declare themselves as “past team members”. Those who haven’t made any non-trivial contribution in two years may be asked to move themselves to this category, and moved there if they don’t respond. Past team members lose their privileges such as voting rights and commit access.
Core team membership can be revoked either directly by the project owner, or by a two thirds majority of votes cast in a core team vote and no veto by the project owner.
Developers¶
Developers contribute to the Stormrose code base and documentation. Their main focus is the development, improvement and maintenance of Stormrose applications.
Prerogatives¶
- Developers are authorised to commit on feature branches
- They may create pull requests
- Access to necessary resources (e. g. tracker, kanban board, etc.) is granted to all developers
Membership¶
Prior to becoming a developer, candidates usually will pass through a mentoring phase, supervised by a core team member. During that time, they may receive already limited privileges (e. g. read-only access to the blessed repository, or commit privileges for a dedicated feature branch) if the core team endorses this.
Everyone interested in becoming a developer candidate may address to a core team member. Having contributed already previously without having a formal developer status, or providing references proving the candidate’s programming skills usually facilitates and accelerates the process of assigning a mentor.
Full developer privileges are then granted by a two thirds majority of votes cast in a core team vote and no veto by the project owner. Nominees may be proposed by their respective core team mentor.
There is no time limit on being a developer. However, in order to provide the wider project stakeholders with a reasonable idea of who is developing the Stormrose applications, developers who have stopped contributing are encouraged to declare themselves as “past team members”. Those who haven’t made any non-trivial contribution in two years may be asked to move themselves to this category, and moved there if they don’t respond. Past developers lose their privileges such as commit access.
Developer privileges can be revoked either directly by the project owner, or by a two thirds majority of votes cast in a core team vote and no veto by the project owner.
Changing the Roles¶
Changes to this document require a quorum of two thirds majority of votes cast in a core team vote and no veto by the project owner.