You are viewing a plain text version of this content. The canonical link for it is here.
Posted to svn@forrest.apache.org by fe...@apache.org on 2008/02/14 16:34:03 UTC
svn commit: r627780 -
/forrest/branches/UpdateFOPto094/site-author/content/xdocs/committed.xml
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&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&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>