forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject How to become a Forrest committer
Date Tue, 26 Jul 2005 15:12:09 GMT
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:

    one must interact with others, and share vision and knowledge

    a clear vision and consensus are needed

    without it, the stuff remains only in the minds of
    the authors

    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:

                           /   \
                          /     \
                       /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.

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 

When we have a final document it would be worth taking this to the user 
list as well.


View raw message