Merge pull request #5 from nunit/decisions

New Decisions doc; miscellaneous other changes

decisions.md

@@ -0,0 +1,32 @@
+# NUnit Community Decision Making Process
+
+Major 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 Core Team member. All non-sensitive project management discussion takes place on the project contributors’ mailing list. Occasionally, sensitive discussion occurs on a private list or through email.
+
+## Decisions in Individual Software Projects
+
+Most decisions that need to be made arise out of requests made of the individual software projects. For example, a user may request a particular feature to be added to the console runner by creating a GitHub issue. Such decisions are normally handled within the project by consensus of the committers, using input provided by users.
+
+In order to ensure that the project is not bogged down by endless discussion and continual voting, we usually follow a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote. 
+
+In general, as long as nobody explicitly opposes a proposal, it is recognised as having the support of the community. Those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal.
+
+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, we try to allow at least 72 hours before assuming that there are no objections to the proposal. This ensures that everyone is given enough time to read, digest and respond, regardless of their location and time commitments.
+
+It may not always be possible to reach a consensus. In that case, the project leader will usually make the final decision. In some cases, however, there may be major issues involved. It may even be a question of the overall direction of the entire NUnit Project. In such a situation, the project leader could either refer the decision to the Core Team or simply make an interim decision and ask the Core Team to review it.
+
+## Core Team Decisions
+
+Ultimately, the final decision on major questions is made by the Core Team. Within the Core Team, we use both consensus and voting to make decisions.
+
+Consensus is usually explicit within the Core Team, as opposed to lazy. For the kind of issues we expect the Core Team to resolve, it's important to hear from each member. The Chair is responsible for getting each member's view and determining whether there is a consensus.
+
+When a consensus cannot be reached, voting is used. Additionally, issues such as those affecting the strategic direction or legal standing of the project always require a vote. The Chair is responsible for determining the necessity of a vote as well as conducting the vote.
+
+Where a vote is used, all votes, including that of the Chair are tallied. With certain exceptions noted below, a simple majority of members must vote for a proposal in order for it to pass. Note that this applies to all current members, not just those who actually vote, and therefore eliminates the need for a quorum. It is the responsibility of the Chair to collect the votes from the members, in case some of them do not respond immediately.
+
+Certain actions require a vote of two thirds of the members, rather than a simple majority.
+
+* Removal of a Core Team member
+* Removal of the Core Team Chair

governance.md

@@ -8,7 +8,7 @@ Anyone with an interest in one of our **Software Projects** can join the communi
 
 ## Software Projects
 
-The NUnit Community maintains a inventory of software projects, with the precise list potentially varying over time. Projects are grouped in a number of categories. See the separate [Projects](./projects.md) document for a full list of projects in each category.
+The NUnit Community maintains an inventory of software projects, with the precise list varying over time. Projects are grouped in a number of categories. See the separate [Projects](./projects.md) document for a full list of projects in each category.
 
 1. Core Projects
 
@@ -73,11 +73,11 @@ This does not mean that a committer is free to do what they want. Each project m
 
 Becoming a committer does not imply any obligation on your part. We understand that an individuals ability to give time to the project can vary over time.
 
-Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player. Typically, a potential committer will need to show that they have an understanding of the project, its objectives and its strategy. They will also have provided valuable contributions to the project over a period of time.
+Anyone may become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player. Typically, a potential committer will need to show that they have an understanding of the project, its objectives and its strategy. They will also have provided valuable contributions to the project over a period of time.
 
-New committers can be nominated by any existing committer and must be appointed by the individual project lead and approved by the Core Team. Removal of committer authority requires approval of the Core Team but may be instituted by the project lead subject to later approval in case of necessity.
+New committers may be nominated by any existing committer and must be appointed by the individual project lead and approved by the Core Team. Removal of committer authority requires approval of the Core Team but may be instituted by the project lead subject to later approval in case of necessity.
 
-Committers on one software project can request committership on any other project and, if accepted, may be directly appointed by the project lead for the second project, without further approval of the Core Team.
+Committers on one software project may request committership on any other project and, if accepted, may be directly appointed by the project lead for the second project, without further approval of the Core Team.
 
 A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term health, may be nominated to become a member of the Core Team.
 
@@ -111,11 +111,11 @@ The initial composition of the Core Team is
 * Chris Maddock
 * Terje Sandstrom
 
-### Core Team Lead
+### Core Team Chair
 
-The Core Team Lead is a single individual, voted for by the Core Team members. Once someone has been appointed Lead, they remain in that role until they choose to retire, or the Core Team casts a two-thirds majority vote to remove them.
+The Core Team Chair is a single individual, voted for by the Core Team members. Once someone has been appointed Chair, they remain in that role until they choose to retire, or the Core Team casts a two-thirds majority vote to remove them.
 
-The Lead has no additional authority over other members of the Core Team: the role is that of a coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to, and has the casting vote when the project fails to reach consensus.
+The Chair has no additional authority over other members of the Core Team: the role is that of a coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to, and has the deciding vote in case of ties. 
 
 ### Original Contributor
 

projects.md

@@ -1,6 +1,6 @@
 ## NUnit Software Projects
 
-The NUnit Community maintains a inventory of software projects, with the precise list potentially varying over time. Projects are grouped in a number of categories.
+The NUnit Community maintains an inventory of software projects, with the precise list varying over time. Projects are grouped in a number of categories.
 
 ### Core Projects