You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2005/07/26 17:12:09 UTC
How to become a Forrest committer
As you know I met with many of the Forrest Devs for the first time at
Apachecon last week. One of the things discussed was how do we immerse
our Google Summer of Code participant and other new arrivals on the dev
list in the ways of the community. Here is my starter on how to do that,
it is my attempt to describe what *I* see as the "ideal" path from being
a "mere" user to being a leader within the community.
One thing that is sometimes hard to understand when you are new to the
Apache Way 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 of the Apache focus on community it is *more* important for
people here discuss and explore within the community. This discussion
leads to a clearer community understanding of the projects goals and
objectives and also of how the community works.
Of course, there has 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
introduce your idea to the community via an email 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, more elegant solution
(this is the benefit of many eyes on a solution).
In Apache 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 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.
This whole process is known as CoPDoC:
(Co)mmunity
one must interact with others, and share vision and knowledge
(P)roject
a clear vision and consensus are needed
(Do)cumentation
without it, the stuff remains only in the minds of
the authors
(C)ode
Discussion goes nowhere without code
(thanks Nicola for the recent reminder about this)
Being a Committer without Coding
--------------------------------
Notice that there are four parts to CoPDoC. Only one of them is code!
There is nothing within Apache 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 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 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.
Why is this so important? Consider this diagram from Danese Coopers
presentation at ApacheCon:
.
/ \
/ \
/Leaders\
/---------\
/Innovators \
/-------------\
/ Committers \
/-----------------\
/ Users \
/---------------------\
This diagram is intended to illustrate that an Open Source project
requires a very wide user base to generate an adequate number of
committers. In addition, many committers are needed to attract a
sufficient number of innovators to ensure the project continues to
progress with respect to its feature set. Finally, there needs to be a
number of Innovators in order to ensure there are a sufficient number of
Leaders to do the boring day to day jobs of managing the project and
keeping it lively and healthy.
----------------------------------------------------------------------
NOTE
----------------------------------------------------------------------
Although this looks like a hierarchical structure it is important to
realise that Apache is not a hierarchical organisation. We are a
meritocracy and once you have earned the right to be a committer you
have the same authority as anyone else. Even before being made a
committer the community will usually take your opinions very seriously,
after all it is by expressing your valued opinions and developing the
community understanding that you earn the right to become a committer.
----------------------------------------------------------------------
---------------------
No anyone wanting to help support this community can make a good stat by
providing a patch for our docs that describes the above (please be sure
to include any corrects/enhancements/clarifications that may come
afterwards).
When we have a final document it would be worth taking this to the user
list as well.
Ross
Re: How to become a Forrest committer
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>As you know I met with many of the Forrest Devs for the first time at
>>Apachecon last week. One of the things discussed was how do we immerse
>>our Google Summer of Code participant and other new arrivals on the dev
>>list in the ways of the community. Here is my starter on how to do that,
>>it is my attempt to describe what *I* see as the "ideal" path from being
>>a "mere" user to being a leader within the community.
>
>
> [ snip lots of good stuff for brevity's sake. ]
...
> I find that diagram to be very dangerous. Any shape that
> has pointy bits at the top is misleading. The label
> "Leaders" is particularly bad. Perhaps a better term
> would be "Mentors", i.e. those who help others to
> understand the way we do things at the ASF.
+1
> The ideal
> is to broaden and merge the layers so that everyone
> becomes a mentor and assists each other. That is what
> i look for when inviting new committers: their ability
> to be a mentor and to work cooperatively with their peers.
+1
> And i don't want to see "committers" treated as a separate
> layer. So i would like to redraw the diagram as below,
> with meritocracy [1] being the force which tends to merge
> the layers and cause the walls to become more vertical.
>
> _________
> / \
> / Mentors \
> / \
> / Developers \
> / \
> / Users \
> /_____________________\
>
> [1] http://www.apache.org/foundation/how-it-works.html
Or perhaps even better (since the purpose of the diagram is to show the
need for a large user base):
.-----------------------------------------------------------------.
| Users | Developers | Mentors |
`-----------------------------------------------------------------'
------> Meritocracy drives people in this direction
(reminder, it really would be great if someone could pull these ideas
into a document for our community)
Ross
Re: How to become a Forrest committer
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> As you know I met with many of the Forrest Devs for the first time at
> Apachecon last week. One of the things discussed was how do we immerse
> our Google Summer of Code participant and other new arrivals on the dev
> list in the ways of the community. Here is my starter on how to do that,
> it is my attempt to describe what *I* see as the "ideal" path from being
> a "mere" user to being a leader within the community.
[ snip lots of good stuff for brevity's sake. ]
> There is nothing within Apache 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 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 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.
>
> Why is this so important? Consider this diagram from Danese Coopers
> presentation at ApacheCon:
>
> .
> / \
> / \
> /Leaders\
> /---------\
> /Innovators \
> /-------------\
> / Committers \
> /-----------------\
> / Users \
> /---------------------\
>
> This diagram is intended to illustrate that an Open Source project
> requires a very wide user base to generate an adequate number of
> committers. In addition, many committers are needed to attract a
> sufficient number of innovators to ensure the project continues to
> progress with respect to its feature set. Finally, there needs to be a
> number of Innovators in order to ensure there are a sufficient number of
> Leaders to do the boring day to day jobs of managing the project and
> keeping it lively and healthy.
>
> ----------------------------------------------------------------------
> NOTE
> ----------------------------------------------------------------------
> Although this looks like a hierarchical structure it is important to
> realise that Apache is not a hierarchical organisation. We are a
> meritocracy and once you have earned the right to be a committer you
> have the same authority as anyone else. Even before being made a
> committer the community will usually take your opinions very seriously,
> after all it is by expressing your valued opinions and developing the
> community understanding that you earn the right to become a committer.
> ----------------------------------------------------------------------
A few comments to reinforce Ross' notes and qualifications:
I find that diagram to be very dangerous. Any shape that
has pointy bits at the top is misleading. The label
"Leaders" is particularly bad. Perhaps a better term
would be "Mentors", i.e. those who help others to
understand the way we do things at the ASF. The ideal
is to broaden and merge the layers so that everyone
becomes a mentor and assists each other. That is what
i look for when inviting new committers: their ability
to be a mentor and to work cooperatively with their peers.
And i don't want to see "committers" treated as a separate
layer. So i would like to redraw the diagram as below,
with meritocracy [1] being the force which tends to merge
the layers and cause the walls to become more vertical.
_________
/ \
/ Mentors \
/ \
/ Developers \
/ \
/ Users \
/_____________________\
[1] http://www.apache.org/foundation/how-it-works.html