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>
