This is a meritocratic, consensus-based community project. Anyone with an interest in Content Management Systems can join the community, contribute to the project design and participate in the decision making process. This document describes how that participation takes place and how to set about earning merit within the project community.
Roles And Responsibilities
End-users are the users of the Content Management System. They are the most important members of the community and without them the project would have no purpose. Anyone can be a user; there are no special requirements.
Users are community members who have a need for a Content Management System to server their websites. They download and install the software and their plugins.
The project asks both users as end-users to participate in the project and community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user contributions include (but are not limited to):
- evangelising about the project (e.g. a link on a website and word-of-mouth awareness raising)
- informing developers of strengths and weaknesses from a new user perspective
- providing moral support (a ‘thank you’ goes a long way)
- providing financial support (the software is open source, but its developers need to eat)
Users who continue to engage with the project and its community will often become more and more involved. Such users may find themselves becoming contributors, as described in the next section.
Contributors are community members who contribute in concrete ways to the project. Anyone can become a contributor, and contributions can take many forms, as detailed in a separate document. There is no expectation of commitment to the project, no specific skill requirements and no selection process.
In addition to their actions as users, contributors may also find themselves doing one or more of the following:
- supporting new users (existing users are often the best people to support new users)
- reporting bugs
- identifying requirements
- providing graphics and web design
- assisting with project infrastructure
- writing documentation
- fixing bugs
- adding features
Contributors engage with the project through the issue tracker and mailing list, or by writing or editing documentation. They submit changes to the project itself via patches, which will be considered for inclusion in the project by existing committers (see next section). The developer mailing list is the most appropriate place to ask for help when making that first contribution.
As contributors gain experience and familiarity with the project, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for be part of the Technical Board.
Fork CMS Technical Board
The Fork CMS Technical Board is responsible for the technical direction that Fork CMS takes. It makes decisions on feature integrations, merges code contributions, etc. It also makes decisions when community consensus cannot be reached.
The board meets every month in Ghent, Belgium. If a member can't participate because of traveling distance or other unpractical circumstances, he can join with a video conference connection. Membership of the technical board is by invitation from the existing members.
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 recognise 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 community member. 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.
Decision Making Process
Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced contributor. All non-sensitive project management discussion takes place on the project contributors’ mailing list. Occasionally, sensitive discussion occurs on a private list.
In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.
Decision making typically involves the following steps:
- Vote (if consensus is not reached through discussion)
Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should send an email to the project contributors’ list or submit a patch implementing the idea to the issue tracker. This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion in order to reach consensus.
In general, as long as nobody explicitly opposes a proposal or patch, it is recognised as having the support of the community. This is called lazy consensus - that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal.
Lazy consensus is a very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone with no objections to a proposal need not spend time stating their position, and others need not spend time reading such mails.
For lazy consensus to be effective, it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.
Not all decisions can be made using lazy consensus. Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. Every member of the community is encouraged to express their opinions in all discussion and all votes. However, only Technical Board members (as defined above) have binding votes for the purposes of decision making.
- [Testing](docs/02. testing.md)
- [Features](docs/03. features.md)
- [Translations](docs/04. translations.md)
- [User Interface](docs/05. user_interface.md)
- [Documentation](docs/06. documentation.md)
- [Spreading the word](docs/07. spreading_the_word.md)
This document is based on the Template For A Meritocratic Governance Document of OSS Watch