Governance document

share/governance.md

@@ -0,0 +1,76 @@
+
+VoxPupuli Governance
+====================
+
+
+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
+-----
+
+
+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):
+
+* 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 board
+
+
+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*: Use a VoxPupuli project
+
+
+Collaborators
+-------------
+
+
+Collaborators 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.
+
+*How to become one*: Submit a pull request to a VoxPupuli project
+
+
+Contributors
+------------
+
+
+Contributors are contributors who have shown wide dedication to the VoxPupuli project in general or deep dedication to one project in particular, and the ability to work well with collaborators and users. The contributors have responsibilities beyond the collaborators. In particular, contributors formally decide on whether a pull request is merged or a release is cut. A contributor will use lazy consensus to decide on whether to merge a pull request from a collaborator. If the discussion is no longer moving towards a consensus, the PMC must vote via lazy consensus on whether the patch should be applied.
+
+*How to become one*: Be a collaborator and be nominated to the PMC as a contributor. Nominations should be sent to <email address for nominations>. You may nominate yourself.
+
+
+Project Management Committee (PMC)
+----------------------------------
+
+
+The project management committee has responsibilities beyond contributors that include participating in strategic planning, release planning, and approving changes to the governance model. They also have the duty of upholding the community code of conduct and ensuring its values. The PMC is also responsible for updating the community code of conduct. It also makes decisions when community consensus cannot be reached. 
+
+The PMC 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.
+
+Membership of the PMC is by election. Condorcet voting is held once a year. A non-running election official is appointed by the PMC and runs the election. There are 5 members of the PMC.
+
+*How to become one*: Win in the yearly election.
+
+
+
+Lazy Consensus
+--------------
+
+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.
+
+
+
+Transparency
+------------
+
+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.
+