Author: mseidel
Date: Sun Jan 21 10:24:22 2018
New Revision: 1821776
URL: http://svn.apache.org/viewvc?rev=1821776&view=rev
Log:
Small update to links
Modified:
openoffice/site/trunk/content/orientation/decision-making.mdtext
Modified: openoffice/site/trunk/content/orientation/decision-making.mdtext
URL:
http://svn.apache.org/viewvc/openoffice/site/trunk/content/orientation/decision-making.mdtext?rev=1821776&r1=1821775&r2=1821776&view=diff
==============================================================================
--- openoffice/site/trunk/content/orientation/decision-making.mdtext (original)
+++ openoffice/site/trunk/content/orientation/decision-making.mdtext Sun Jan 21
10:24:22 2018
@@ -22,12 +22,12 @@ In the previous Module we read about col
1. Commit-Then-Review (CTR) and Review-Then-Commit (RTC).
- The two primary ways of managing product changes go by the names
Commit-Then-Review (CTR) and Review-Then-Commit (RTC). For most cases we
operate in a CTR mode, meaning that our
[Committers](http://www.apache.org/foundation/how-it-works.html#committers) are
able to check in changes as they desire, with no advance approval or review.
+ The two primary ways of managing product changes go by the names
Commit-Then-Review (CTR) and Review-Then-Commit (RTC). For most cases we
operate in a CTR mode, meaning that our
[Committers](https://www.apache.org/foundation/how-it-works.html#committers)
are able to check in changes as they desire, with no advance approval or review.
We trust our Committers to do the right thing. By default Committers don't
ask permission before acting. They avoid unnecessary discussion and email
traffic. This is not because they are anti-social. This is because they realize
that in a project of this size it is impossible to discuss every small change
in advance. Discussing too much is both
unnecessary and unproductive. We have a "time machine" called Subversion
that allows us to undo any changes to the product or website. So if a Committer
believes that a change would be uncontroversial, and the change is
reversible, then the default approach is to go ahead make the change.
- Terms that you might need to know related to the above are:
[JFDI](http://www.urbandictionary.com/define.php?term=JFDI) and ["assuming lazy
consensus"](https://www.apache.org/foundation/glossary.html#LazyConsensus).
+ Terms that you might need to know related to the above are:
[JFDI](https://www.urbandictionary.com/define.php?term=JFDI) and ["assuming
lazy consensus"](https://www.apache.org/foundation/glossary.html#LazyConsensus).
2. When is RTC, Review-Then-Commit Used?
@@ -66,7 +66,7 @@ In the previous Module we read about col
Because the Volunteers are spread out all across the globe, in
various time zones, and many have day jobs or other committments, the
convention is to wait *at least* 72 hours for feedback on a proposal.
- In cases where the proposer wants to act on their proposal, if there
are no objections, they should state this in the proposal. For example, "If
there are no objections voiced within 72 hours, I'll go ahead and make these
changes". This is called "stating lazy consensus". You can read more about lazy
consensus
[here](http://openoffice.apache.org/docs/governance/lazyConsensus.html).
+ In cases where the proposer wants to act on their proposal, if there
are no objections, they should state this in the proposal. For example, "If
there are no objections voiced within 72 hours, I'll go ahead and make these
changes". This is called "stating lazy consensus". You can read more about lazy
consensus
[here](https://openoffice.apache.org/docs/governance/lazyConsensus.html).
4. Voting, Consensus, and Vetoes
