Roles and Responsibilities
In order to have a smoothly running project, formal roles with corresponding responsibilities are established. A member of the community may have multiple roles.
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
- advocating for use of 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)
- writing documentation and tutorials
- filing bug reports and feature requests
- participating on the discussion boards or forums and email lists
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 below.
How to become one: Install and use Nearforums
Contributors are community members who submit patches to the project. These patches may be a one-time occurrence or occur over time. Expectations are that contributors will submit patches that are small at first and will only grow larger once the contributor
has built confidence in the quality of their patches.
NOTE: before a contributor’s first legally significant patch is put into the repository they must sign a Contributor License Agreement or assignment agreement. The patch can be submitted and discussed but it can’t actually be committed to the repository without
How to become one: Submit a patch as a fork. To do so, you can
create a fork
in the source code tab of the project (see
how to create forks / pull requests on Codeplex
). You should read the
for further info.
Committers are contributors who have shown dedication to Nearforums, high technical prowess and the ability to work well with contributors and users. The committers have responsibilities beyond the contributors. In particular, committers formally decide on
whether patches are entered into the main code repository and add those requests. Additionally they verify with Outercurve Foundation staff that a potential contributor has a signed CLA before committing a patch to the repository. A committer will use lazy
consensus to decide on whether to commit a patch from a contributor. If the discussion is no longer moving towards a consensus, the Management Committee (see next section) will decide on the patches inclusion via lazy consensus.
Beyond the responsibility of merging contributions, committers as a group (called the Management Committee) participate in strategic planning, release planning, and approving changes to the governance model. The management committee also makes decisions on
patches when community consensus cannot be reached. The management committee has final say over who can become a committer and will use lazy consensus for approval. Discussion over committer nominations will be done in private.
How to become one: Be a contributor and be nominated as a committer.
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.
When a member is convinced of knowing what the community would like to see happen, it can be assumed that there is already a consensus about it and get on with the work. Members just assume that they have the communities support unless someone says otherwise.
When a member of the community believes a specific action is the correct one for the community but is not sure enough to proceed with the work, a proposal is made and state that they will start implementing it in 72 hours unless someone objects. 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.
Building community trust in the governance of an open-source project is vital to its success. To that end, decision making must be done in a transparent, open fashion. No decisions about the project’s direction, bug fixes or features may be done without community
involvement and participation. Discussions must begin at the earliest possible point on a topic; the community’s participation is vital during the entire decision-making process.
This work is licensed under a
Creative Commons Attribution-ShareAlike 2.0 UK: England & Wales License
This work is based upon "Meritocratic Governance Model
" by University of Oxford.