openoffice-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From msei...@apache.org
Subject svn commit: r1852798 - /openoffice/site/trunk/content/orientation/decision-making.mdtext
Date Sat, 02 Feb 2019 14:40:44 GMT
Author: mseidel
Date: Sat Feb  2 14:40:43 2019
New Revision: 1852798

URL: http://svn.apache.org/viewvc?rev=1852798&view=rev
Log:
Removed whitespace, fixed typo

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=1852798&r1=1852797&r2=1852798&view=diff
==============================================================================
--- openoffice/site/trunk/content/orientation/decision-making.mdtext (original)
+++ openoffice/site/trunk/content/orientation/decision-making.mdtext Sat Feb  2 14:40:43 2019
@@ -22,18 +22,18 @@ 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](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.
+	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.
+	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](https://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?
 
-    There are times where CTR is not appropriate and RTC is used. This happens, for example,
at the end of a release cycle, when we want to carefully review changes made to the product,
in order to control the final quality before the release. When we're in RTC mode, no changes
are made to the code unless first discussed and approved on the mailing list.
+	There are times where CTR is not appropriate and RTC is used. This happens, for example,
at the end of a release cycle, when we want to carefully review changes made to the product,
in order to control the final quality before the release. When we're in RTC mode, no changes
are made to the code unless first discussed and approved on the mailing list.
 
-    Other situations when RTC is used instead of CTR might include:
+	Other situations when RTC is used instead of CTR might include:
 
 	1. A Committer is unsure of the technical merits of what they want to do. They want
 	an extra pair of eyes to review the proposal point out weaknesses, alternatives, etc.
@@ -62,11 +62,11 @@ In the previous Module we read about col
 
   3. Proposals
 
-	  The convention is to send all proposals in their own new thread. (Don't hide a proposal
10 posts deep in an existing thread). Put "[PROPOSAL]" in the subject line or make it obvious
that you are making a proposal.
+	The convention is to send all proposals in their own new thread. (Don't hide a proposal
10 posts deep in an existing thread). Put "[PROPOSAL]" in the subject line or make it obvious
that you are making a proposal.
 
-	  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.
+	Because the Volunteers are spread out all across the globe, in various time zones, and many
have day jobs or other commitments, 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](https://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
 



Mime
View raw message