[comdev-site] branch master updated: Update decisionMaking.md

[rb...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

rbowen pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/comdev-site.git


The following commit(s) were added to refs/heads/master by this push:
     new daf2819  Update decisionMaking.md
     new 67112fe  Merge pull request #29 from cottage14/patch-14
daf2819 is described below

commit daf28199d5f8708c3601663916f66e9593960b31
Author: Andrew Wetmore <an...@cottage14.com>
AuthorDate: Wed Dec 2 11:27:28 2020 -0400

    Update decisionMaking.md
    
    Minor edits to improve readability. Note, there can be consensus to _reject_ a proposal, not just to approve it. The original text assumes that consensus == approval.
---
 source/committers/decisionMaking.md | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/source/committers/decisionMaking.md b/source/committers/decisionMaking.md
index 959a2dd..db023f9 100644
--- a/source/committers/decisionMaking.md
+++ b/source/committers/decisionMaking.md
@@ -1,22 +1,22 @@
 ---
-title: Decision Making
+title: Decision-Making
 ---
 
 The most important thing about engaging with any Apache project is that everyone
-is equal. All people with an opinion are entitled to express that opinion and, where 
-appropriate, have it considered by the community.
+is equal. All project participants with an opinion can express that opinion and, where 
+appropriate, have the community consider it.
 
-To some the idea of having to establish consensus in a large and distributed team 
-sounds inefficient and frustrating. Don't despair though, The Apache Way has a
+To some, the idea of having to establish consensus in a large and distributed team 
+sounds inefficient and frustrating. Don't despair, though: The Apache Way has a
 set of simple processes to ensure things proceed at a good pace.
 
 In ASF projects we don't like to vote. We reserve that for the few things that need 
-official approval for legal or process reasons (e.g. a release or a new committer). 
-Most of the time we work with the consensus building techniques documented below.
+official approval for legal or process reasons (e.g. approving a release or adding a new committer). 
+Most of the time we work with the consensus-building techniques documented below.
 
 ## Lazy Consensus
 
-[Lazy consensus][10] is the first, and possibly the most important, consensus building 
+[Lazy consensus][10] is the first, and possibly the most important, consensus-building 
 tool we have. Essentially lazy consensus means that you don't need to get explicit
 approval to proceed, but you need to be prepared to listen if someone objects.
 
@@ -25,16 +25,16 @@ approval to proceed, but you need to be prepared to listen if someone objects.
 Sometimes lazy consensus is not appropriate. In such cases it is necessary to
 make a proposal to the mailing list and discuss options. There are mechanisms
 for quickly showing your support or otherwise for a proposal and 
-[building consensus][11] amongst the community.
+[building consensus][11] within the community.
 
-Once there is a consensus people can proceed with the work under the [lazy 
+Once there is consensus to approve a proposal, people can proceed with the work under the [lazy 
 consensus][12] model.
 
 ## Voting
 
 Occasionally a "feel" for consensus is not enough. Sometimes we need to 
-have a measurable consensus. For example, when [voting][13] in new committers or 
-to approve a release. 
+have a measurable vote, as when we [voted][13] in new committers or 
+approve a release. 
 
   [10]: /committers/lazyConsensus.html
   [11]: /committers/consensusBuilding.html