forrest-svn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cross...@apache.org
Subject svn commit: r230622 - /forrest/trunk/site-author/content/xdocs/committed.xml
Date Sun, 07 Aug 2005 02:21:56 GMT
Author: crossley
Date: Sat Aug  6 19:21:52 2005
New Revision: 230622

URL: http://svn.apache.org/viewcvs?rev=230622&view=rev
Log:
Split long paragraphs to emphasise each topic.
Minor text tweaks.

Modified:
    forrest/trunk/site-author/content/xdocs/committed.xml

Modified: forrest/trunk/site-author/content/xdocs/committed.xml
URL: http://svn.apache.org/viewcvs/forrest/trunk/site-author/content/xdocs/committed.xml?rev=230622&r1=230621&r2=230622&view=diff
==============================================================================
--- forrest/trunk/site-author/content/xdocs/committed.xml (original)
+++ forrest/trunk/site-author/content/xdocs/committed.xml Sat Aug  6 19:21:52 2005
@@ -38,9 +38,10 @@
     <p>Committer is an Apache term used to signify someone who is 
       committed to a particular project and who is invited to be part of 
       the core group within the project that ensures the project's vitality 
-      (represented by the PMC, Project Management Committee).  One thing 
+      (represented by the PMC, Project Management Committee).</p>
+    <p>One thing 
       that is sometimes hard to understand when you are new to the
-      Apache Way<sup>1</sup>
+      Apache Way<sup><a href="#references">1</a></sup>
       is that we don't really care about code, it is the 
       community we care about. This is because a strong and healthy 
       community will usually generate strong and healthy code.  As a result 
@@ -62,16 +63,18 @@
     </section>
     <section id="becoming">
     <title>Becoming a Committer</title>
-    <p>There is nothing within Apache that says you must write code 
+    <p>There is nothing at The Apache Software Foundation that says you must write
code 
       in order to be a committer. Anyone who is supportive of the community 
       and works in any of the CoPDoC areas is a likely candidate for 
-      committership. Apache is a meritocracy. That is, once someone has 
-      contributed sufficiently to any area of  CoPDoC they can be voted in 
+      committership.</p>
+    <p>Apache is a meritocracy. That is, once someone has 
+      contributed sufficiently to any area of CoPDoC they can be voted in 
       as a committer. Being a committer does not mean you commit code, it 
-      means you are committed to the project.  One of the key contributions 
+      means you are committed to the project.</p>
+    <p>One of the key contributions 
       people can make to the community is through the support of a wide 
-      user base by assisting users on the user list,  writing user oriented 
-      docs and ensuring the user viewpoint is understood by all devs. A 
+      user base by assisting users on the user list, writing user oriented 
+      docs and ensuring the user viewpoint is understood by all developers. A 
       main idea behind being a committer is the ability to be a mentor and 
       to work cooperatively with your peers.</p>
     <p>The following diagram shows the progression of a user to a 
@@ -79,7 +82,7 @@
     <p><img alt="committer path" src="committed-1.png"/></p>
     <p>Meritocracy progresses this way
       <code>------------> ------------------------></code></p>
-    <p>Note that this is not a heirarchy, it is a progression from a 
+    <p>Note that this is not a hierarchy, it is a progression from a 
       broad user base from which those that wish to to contribute to the 
       ongoing development of the project (again, through any aspect of 
       CoPDoC, not just coding) can become involved as developers.  From 
@@ -89,22 +92,24 @@
     <section id="discussion">
     <title>Adding to the discussions</title>
     <p>Discussion leads to a clearer community understanding of the 
-      project's goals and objectives and also of how the community works.  
-      Of course, there has to be a balance between too much chat and not 
+      project's goals and objectives and also of how the community works.</p>
+    <p>  
+      Of course, there needs to be a balance between too much chat and not 
       enough code.  If something is easy to do in code and does not impact 
       the overall product (such as a bug fix) then just go ahead and do it. 
-      However, if something is to introduce a new feature it is best to 
+      However, if something is to introduce a new feature, then it is best to 
       introduce your idea to the community via an email to the dev mail 
       list first. In this introduction you should outline why you want to 
       do something, how you propose to do it (pseudo code is a good way of 
-      expressing this) and ask for comments. Any comments you receive will 
-      help you fine tune your design and, in many cases, produce a quicker, 
+      expressing this) and ask for comments. Any comments received will 
+      help to fine tune the design and, in many cases, produce a quicker, 
       more elegant solution (this is the benefit of many eyes on a 
-      solution). In Apache the absence of comments from others does not 
+      solution).</p>
+    <p>The absence of comments from others does not 
       mean it is not a good idea, in fact the reverse is true, it means 
       nobody has any objection or anything to add. It is only if people 
       respond that you need to discuss further. Once the discussion reaches 
-      consensus then coding can proceed. Once you have implicit or explicit 
+      consensus then coding can accelerate. Once you have implicit or explicit 
       approval for your contribution just go ahead and do it. Be sure to 
       document what you have done whilst you are at it. Without 
       documentation (comments in code, mailing list discussion and user 



Mime
View raw message