This project is led by a project director and managed by the community. That is, the community actively contributes to the day-to-day maintenance of the project, but the general strategic line is drawn by the project director. In case of disagreement, they have the last word. It is the project director’s job to resolve disputes within the community and to ensure that the project is able to progress in a coordinated way. In turn, it is the community’s job to guide the decisions of the project director through active engagement and contribution.
Typically, the project director is self-appointed. However, because the community always has the ability to fork, this person is fully answerable to the community. The project director’s role is a difficult one: they set the strategic objectives of the project and communicate these clearly to the community. They also have to understand the community as a whole and strive to satisfy as many conflicting needs as possible, while ensuring that the project survives in the long term.
In many ways, the role of the project director is less about dictatorship and more about diplomacy. The key is to ensure that, as the project expands, the right people are given influence over it and the community rallies behind the vision of the project director. The director’s job is then to ensure that the maintainers (see below) make the right decisions on behalf of the project. Generally speaking, as long as the maintainers are aligned with the project’s strategy, the project director will allow them to proceed as they desire.
Maintainers are contributors who have made several valuable contributions to the project and are now relied upon to both write code directly to the repository and screen the contributions of others. In many cases they are programmers but it is also possible that they contribute in a different role. Typically, a maintainer will focus on a specific aspect of the project, and will bring a level of expertise and understanding that earns them the respect of the community and the project director. The role of maintainer is not an official one, it is simply a position that influential members of the community will find themselves in as the project director looks to them for guidance and support.
Maintainers have no authority over the overall direction of the project. However, they do have the ear of the project director. It is a maintainer’s job to ensure that the director is aware of the community’s needs and collective objectives, and to help develop or elicit appropriate contributions to the project. Often, maintainers are given informal control over their specific areas of responsibility, and are assigned rights to directly modify certain areas of the source code. That is, although maintainers do not have explicit decision-making authority, they will often find that their actions are synonymous with the decisions made by the director.
Contributors are community members who either have no desire to become maintainers, or have not yet been given the opportunity by the project director. They make valuable contributions, such as those outlined in the list below, but generally do not have the authority to make direct changes to the project code. Contributors engage with the project through communication tools, such as Slack, and via reports and patches attached to issues in the issue tracker.
Anyone can become a contributor. There is no expectation of commitment to the project, no specific skill requirements and no selection process. To become a contributor, a community member simply has to perform one or more actions that are beneficial to the project.
Some contributors will already be engaging with the project as users, but will also find themselves doing one or more of the following:
- Supporting new users (current users often provide the most effective new user support).
- Reporting bugs.
- Identifying requirements.
- Supplying graphics and web design.
- Programming.
- Assisting with project infrastructure.
- Writing documentation.
- Fixing bugs.
- Adding features.
As contributors gain experience and familiarity with the project, they may find that the project director starts relying on them more and more. When this begins to happen, they gradually adopt the role of maintainer, as described above.
Users are community members who have a need for the project. They are the most important members of the community: without them, the project would have no purpose. Anyone can be a user; there are no specific requirements.
Users should be encouraged to participate in the life of the project and the community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user activities include (but are not limited to):
- Evangelizing about the project.
- Informing developers of project strengths and weaknesses from a new user’s perspective.
- Providing moral support (a ‘thank you’ goes a long way).
- Providing financial support.
- Users who continue to engage with the project and its community will often find themselves becoming more and more involved.
- Such users may then go on to become contributors, as described above.
All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community. Those seeking support should recognize that all support activity within the project is voluntary and is therefore provided as and when time allows. A user requiring guaranteed response times or results should therefore seek to purchase a support contract from a vendor. (Of course, that vendor should be an active member of the community.) However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels are ideal.
Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. For instance, a contributor might be active on the project mailing list and issue tracker, or might supply patches. The various ways of contributing are described in more detail in our CONTRIBUTING document.
The Slack workspace is the most appropriate place for a contributor to ask for help when making their first contribution.
This governance model does not need a formal conflict resolution process, since the project director’s word is final. If the community chooses to question the wisdom of the actions of a maintainer, the project director can review their decisions by checking the email archives, and either uphold or reverse them.
There may be situations when a maintainer or the project director wants to step aside from the project, either temporarily or permanently.
In such case, the project director will ask each maintainer separately if they want to, temporarily, become the project director and who would they like to see as the new project director, except them. If at least one maintainer offers their help, the current project director will choose the new one. In case no one wants to temporarily become the project director, the current one will choose another person —either already involved in the project community or not.
If the project director leaves for more than 6 months, the case will be considered as "permanent leave" (see below), unless otherwise stated by the maintainers.
In such case, the project director will ask each maintainer separately if they want to, permanently, become the project director and who would they like to see as the new project director, except them. If at least one maintainer offers their help, the current project director will choose the new one. In case no one wants to permanently become the project director, the current one will choose another person —either already involved in the project community or not.
Only in the case the project director steps aside abruptly and without any intention to make their last decision of electing the new project director, it's the duty of the maintainers to elect a new candidate and how the election process will happen.
In such case, the project director will ask the maintainers how they want to proceed in taking care of the incomplete work the leaving maintainer has left, if any. If the maintainer leaves for more than 6 months, the case will be considered as "permanent leave" (see below), unless otherwise stated by the project director.
In such case, the project director will ask the maintainers how they want to proceed in taking care of the incomplete work the leaving maintainer has left, if any. The project director will seek consensus with the maintainers about whether to propose and elect a new maintainer, however, in case the conversation gets blocked, it's the project director's duty to decide how to continue.