Typically, the benevolent dictator, or project lead, is self-appointed. However, because the community always has the ability to fork, this person is fully answerable to the community. The project lead's role is a difficult one: they ultimately set the strategic vision of the project and communicate these clearly to the project maintainers and community at large. 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 benevolent dictator 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 lead. The lead's job is then to ensure that maintainers and committers (see below) make the right decisions on behalf of the project. Generally speaking, as long as the maintainers and committers are aligned with the project's strategy, the project lead will allow them to proceed as they desire.
Check out this read on some of the qualifications we expect in a good BD.
Maintainers are committers who also make decisions for the overall direction of the project including but not limited to:
- Helping set the strategic vision
- Assigning or removing roles and responsibilites
- Maintaining these contribution docs
- Planning sprints and milestones
- Determining release dates and cycles
- Delegating to committers when and where appropriate
Decisions are made by consensus with the Benevolent Dictator serving as final authority when consensus cannot be reached. Ideally, all decision making for the project is made by the maintainers and by concensus.
Committers 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 committer 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 maintainers. The role of committer is an official one and it is generally a position that influential members of the community will find themselves in as the project maintainers looks to them for guidance and support. Some more popular areas of focus for committers are:
- DevOps (Test, Build, Deploy)
- Specific Lando Plugins, Recipes or Services
- Core Lando Code
- Writing Tests
Committers have no authority over the overall direction of the project. However, they do have the ear of the project maintainers. It is a committer's job to ensure that the maintainers are aware of the community's needs and collective objectives, and to help develop or elicit appropriate contributions to the project. Often, committers 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 committers do not have explicit decision-making authority, they will often find that their actions are synonymous with the decisions made by the maintainers.
Committers that acquire more project breadth and high level insight around the projects vision may find that the project maintainers start relying on them more and more. When this begins to happen, they gradually adopt the role of maintainer, as described above.
Contributors are community members who either have no desire to become committers, or have not yet been given the opportunity by the project maintainers. 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 primarily through the #contributors Slack and 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
- Writing Code
- Assisting with project infrastructure
- Writing documentation
- Fixing bugs
- Adding features
- Triaging issues
- Atttempting to replicate bugs
As contributors gain experience and familiarity with the project, they may find that the project maintainers start relying on them more and more. When this begins to happen, they gradually adopt the role of committer, 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):
- Evangelising 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.