forrest-svn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ferdin...@apache.org
Subject svn commit: r627780 - /forrest/branches/UpdateFOPto094/site-author/content/xdocs/committed.xml
Date Thu, 14 Feb 2008 15:34:03 GMT
Author: ferdinand
Date: Thu Feb 14 07:34:01 2008
New Revision: 627780

URL: http://svn.apache.org/viewvc?rev=627780&view=rev
Log:
restore original version from head

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

Modified: forrest/branches/UpdateFOPto094/site-author/content/xdocs/committed.xml
URL: http://svn.apache.org/viewvc/forrest/branches/UpdateFOPto094/site-author/content/xdocs/committed.xml?rev=627780&r1=627779&r2=627780&view=diff
==============================================================================
--- forrest/branches/UpdateFOPto094/site-author/content/xdocs/committed.xml (original)
+++ forrest/branches/UpdateFOPto094/site-author/content/xdocs/committed.xml Thu Feb 14 07:34:01
2008
@@ -1,173 +1,173 @@
 <?xml version="1.0"?>
 <!--
-  Licensed to the Apache Software Foundation (ASF) under one or more
-  contributor license agreements.  See the NOTICE file distributed with
-  this work for additional information regarding copyright ownership.
-  The ASF licenses this file to You under the Apache License, Version 2.0
-  (the "License"); you may not use this file except in compliance with
-  the License.  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
+    Licensed to the Apache Software Foundation (ASF) under one or more
+    contributor license agreements.  See the NOTICE file distributed with
+    this work for additional information regarding copyright ownership.
+    The ASF licenses this file to You under the Apache License, Version 2.0
+    (the "License"); you may not use this file except in compliance with
+    the License.  You may obtain a copy of the License at
+    
+    http://www.apache.org/licenses/LICENSE-2.0
+    
+    Unless required by applicable law or agreed to in writing, software
+    distributed under the License is distributed on an "AS IS" BASIS,
+    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+    See the License for the specific language governing permissions and
+    limitations under the License.
 -->
 <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" 
   "http://forrest.apache.org/dtd/document-v20.dtd">
 <document>
-  <header>
-    <title>Becoming an Apache Forrest committer</title>
-    <abstract>
-      This is a discussion of how users can become committers within the Apache
-      Forrest project.
-    </abstract>
-  </header>
-  <body>
-    <section id="committers">
-      <title>What is a committer?</title>
-      <warning>
-        This document is under development and does not yet represent the view
-        of our community.
-      </warning>
-      <note>
-        Content is being gleaned from various current and past discussions on
-        the Forrest dev mailing list, in particular
-        <a href="http://marc.theaimsgroup.com/?l=forrest-dev&amp;m=112239074108858">this</a>.
-        Further editing of this page is needed and would be greatly appreciated.
-      </note>
-      <p>
-        Committer is an term used at the ASF 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).
-      </p>
-      <p>
-        One thing that is sometimes hard to understand when you are new to the
-        open development<sup>1</sup> process used at the ASF, is that we value
-        the community more than the code. A strong and healthy community will be
-        respectful and be a fun and rewarding place. Strong code will evolve.
-      </p>
-    </section>
-    <section id="copdoc">
-      <title>Contributing to the Project - CoPDoC</title>
-      <p>
-        The foundation of a project and how the community contributes to it is
-        known by the acronym CoPDoC:
-      </p>
-      <ul>
-        <li>(Co)mmunity - one must interact with others, and share vision 
-      and knowledge</li>
-        <li>(P)roject - a clear vision and consensus are needed</li>
-        <li>(Do)cumentation - without it, the stuff remains only in the 
-      minds of the authors</li>
-        <li>(C)ode - discussion goes nowhere without code</li>
-      </ul>
-    </section>
-    <section id="becoming">
-      <title>Becoming a Committer</title>
-      <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.
-      </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.
-      </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 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
-        committer/mentor.
-      </p>
-      <p>
-          <img alt="committer path" src="/committed-1.png"/>
-      </p>
-      <p>
-        Meritocracy progresses this way <code>------------>
+    <header>
+        <title>Becoming an Apache Forrest committer</title>
+        <abstract>
+            This is a discussion of how users can become committers within the Apache
+            Forrest project.
+        </abstract>
+    </header>
+    <body>
+        <section id="committers">
+            <title>What is a committer?</title>
+            <warning>
+                This document is under development and does not yet represent the view
+                of our community.
+            </warning>
+            <note>
+                Content is being gleaned from various current and past discussions on
+                the Forrest dev mailing list, in particular
+                <a href="http://marc.theaimsgroup.com/?l=forrest-dev&amp;m=112239074108858">this</a>.
+                Further editing of this page is needed and would be greatly appreciated.
+            </note>
+            <p>
+                Committer is an term used at the ASF 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).
+            </p>
+            <p>
+                One thing that is sometimes hard to understand when you are new to the
+                open development<sup>1</sup> process used at the ASF, is that
we value
+                the community more than the code. A strong and healthy community will be
+                respectful and be a fun and rewarding place. Strong code will evolve.
+            </p>
+        </section>
+        <section id="copdoc">
+            <title>Contributing to the Project - CoPDoC</title>
+            <p>
+                The foundation of a project and how the community contributes to it is
+                known by the acronym CoPDoC:
+            </p>
+            <ul>
+                <li>(Co)mmunity - one must interact with others, and share vision 
+                    and knowledge</li>
+                <li>(P)roject - a clear vision and consensus are needed</li>
+                <li>(Do)cumentation - without it, the stuff remains only in the 
+                    minds of the authors</li>
+                <li>(C)ode - discussion goes nowhere without code</li>
+            </ul>
+        </section>
+        <section id="becoming">
+            <title>Becoming a Committer</title>
+            <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.
+            </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.
+            </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 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
+                committer/mentor.
+            </p>
+            <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 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 these developers
-        are those who take on additional roles of mentoring and more fully
-        commit themselves to the project.
-      </p>
-    </section>
-    <section id="responsibility">
-      <title>Responsibilities</title>
-      <p>
-        The additional responsibilities of the PMC as a whole are outlined in
-        the Apache Forrest project guidelines<sup>2</sup>. It should be noted
-        though that Apache projects should be fun, not pressure. As a PMC
-        member, just as a developer, you do as much work as you feel like doing.
-        You do not need to participate in every discussion, just because it
-        concerns the PMC. Neither do you need to participate in every vote or in
-        every development issue. We like people to be involved and we reward
-        contributions (meritocracy), but we do not punish a lack of
-        contributions. People come and go as their needs change and we adapt to
-        those changes.
-      </p>
-    </section>
-    <section id="discussion">
-      <title>Adding to the discussions and contributing code</title>
-      <p>
-        Discussion leads to a clearer community understanding of the 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, 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 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).
-      </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
-        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 docs) your code is next to useless -
-        nobody knows it is there and nobody knows how it works.
-      </p>
-      <p>
-        Online discussion is important for community building. Offline
-        discussion and one-to-one conversations deny the community the chance to
-        become involved and lead to solutions that are not ideal. So please do
-        as much discussion as possible on the dev or user mailing list.
-      </p>
-    </section>
-    <section id="references">
-      <title>References</title>
-      <p>
-        <sup>1</sup> <a href="site:guidelines/way">Open development</a>
at
-        Apache Forrest.
-      </p>
-      <p>
-        <sup>2</sup> Apache Forrest <a href="site:guidelines">project
-        guidelines</a>.
-      </p>
-    </section>
-  </body>
+            </p>
+            <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 these developers
+                are those who take on additional roles of mentoring and more fully
+                commit themselves to the project.
+            </p>
+        </section>
+        <section id="responsibility">
+            <title>Responsibilities</title>
+            <p>
+                The additional responsibilities of the PMC as a whole are outlined in
+                the Apache Forrest project guidelines<sup>2</sup>. It should
be noted
+                though that Apache projects should be fun, not pressure. As a PMC
+                member, just as a developer, you do as much work as you feel like doing.
+                You do not need to participate in every discussion, just because it
+                concerns the PMC. Neither do you need to participate in every vote or in
+                every development issue. We like people to be involved and we reward
+                contributions (meritocracy), but we do not punish a lack of
+                contributions. People come and go as their needs change and we adapt to
+                those changes.
+            </p>
+        </section>
+        <section id="discussion">
+            <title>Adding to the discussions and contributing code</title>
+            <p>
+                Discussion leads to a clearer community understanding of the 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, 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 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).
+            </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
+                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 docs) your code is next to useless -
+                nobody knows it is there and nobody knows how it works.
+            </p>
+            <p>
+                Online discussion is important for community building. Offline
+                discussion and one-to-one conversations deny the community the chance to
+                become involved and lead to solutions that are not ideal. So please do
+                as much discussion as possible on the dev or user mailing list.
+            </p>
+        </section>
+        <section id="references">
+            <title>References</title>
+            <p>
+                <sup>1</sup> <a href="site:guidelines/way">Open development</a>
at
+                Apache Forrest.
+            </p>
+            <p>
+                <sup>2</sup> Apache Forrest <a href="site:guidelines">project
+                    guidelines</a>.
+            </p>
+        </section>
+    </body>
 </document>



Mime
View raw message