forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: Simple committership
Date Sat, 06 Aug 2005 13:59:18 GMT
On Fri, 2005-07-29 at 15:30 +0200, Nicola Ken Barozzi wrote:
<snip valuable background information/>
> 
> If we want to include "simple committership" as a role, I would like to
> hear someone explain how simple committership will solve more
> issues than it may cause, especially given the above. In particular, I
> would like to have some real-life examples that show how simple
> committership would have been useful.
> 

Like David and Nicola stated the Forrest project normally votes all
committer directly into the PMC as well. I personally see special
occasions (besides GSoC) where I would like to see a "simple
committership" or like I would call it "PMC incubation". It should
follow the basic idea of the Apache Incubator [1] which is for new
projects at Apache.

"A large part of the Incubator's effort will be devoted to providing
documentation on how the Foundation works, and how to get things done
within its framework. As a consequence, it is expected that the
Incubator will also become a reference for new contributors to any of
the Apache projects."

My reasoning is that we can ensure that this "newbies" can learn the
apache way to it fullest (which is one of the most important point in
the process to become a PMC member) without the "pressure" to be an
official PMC member.

New committers have to learn
a) "how the Foundation works"
b) "how the Project works"

One can argue that this should be learned before becoming a committer on
the mls but I see a certain process behind it which takes time (some
times too much). Now it was asked for a "real-life example". 

That could be myself. ;-)

I have been a Wyona CMS committer before it became an official Apache
Incubator project. The company Wyona donated then the code base to the
ASF as cocoon subproject in incubation called Apache Lenya. I had
"general" experience in how a open source project and community is
working but that have been quite different from the ASF way that I had
to learn. 

Within the one year where Apache Lenya has been in the incubator I
learned the basics (IMO learning) on "how the Foundation works" (a)
(never stops). As Apache Lenya committer we were given not only
committing rights to lenya but as well to cocoon, forrest and xml.

I started to use them here on forrest when getting into the
documentation for lenya. In lenya we are using forrest to create our
documentation and website. We had a custom skin and heaps problems with
maintaining it because forrest is developing very rapid. 

The lenya skin was nearly all div based. At the time I started here in
forrest there was an issue about an "all div based" skin. The result is
called "pelt". While I was developing the skin I had "simple
committership" to forrest. I am happy that I could concentrate on
developing the skin and meanwhile learning all the new responsibilities
of a PMC member. After a while I was invited to join the PMC and helping
on the long run of forrest. 

I could fully participate in the project as committer. I just did not
had a counting vote but normally forrest consider every concern. 

One thing that helped me is that the PMC normally watch the committs of
new committer more careful to ensure that e.g. all legal issues are
meet. 

PMC membersnot only have to help new committers to learn the duty of a
PMC member in the specific project (b) but also like the incubator teach
the values of an ASF project and its duties (a). There have been a
thread on all PMC lists about the duties (around 10 points) of a PMC
member by Davanum Srinivas. 

I was given committership to apply my own patches for cocoon, forrest
and xml. That leveraged this project (faster process) because other PMC
members do not had to do that. Then especially David taught me as well
the PMC duties and I became a PMC member. 

The important point is that new committer are generally
overwhelmed by the information and infrastructure of the project and the
ASF. Some learn better step by step understanding what is ASF all about
and what a PMC member have to do (I consider myself as such a
somebody). 

I was lucky and made my experience in the incubator *and* here but the
committers we vote in normally do not have this "incubator" experience
which I consider most valuable. 

> 
> In essence, Jakarta became a small Apache, creating sub-roles where
> the
> PMC members were like Apache members, and committers were like PMC
> members. In Jakarta it's usual that committers vote, but in fact their
> vote is not legally valid, and they *cannot* release code without a
> PMC
> vote.
> This also created a big disconnect between the Board of Directors and
> Jakarta, and most projects were having little or no oversight, and the
> number of Jakarta committers that was an Apache member was extremely
> low.

The point you are maybe up to is that we can create a closed group that
new committer are not able to enter. We limit the PMC membership to a
certain group of people for whatever particular reason.

The downside is that committers cannot be responsible for the projects
because they are not in the "management" PMC. That will slow down the
progress of this project(s) because it slow down their processes.

I guess it happened because many projects emerged from Jarkata (e.g.
tomcat, struts,...) and people felt better in having a good working team
then to better leverage their pmc duties in teaching new committer this
duties. 

One sentence of [2] seems very interesting at this point:
"Section 6.3. Project Management Committees.
...
Each Project Management Committee shall be responsible for the active
management of one or more projects identified by resolution of the Board
of Directors which may include, without limitation, the creation or
maintenance of "open-source" software for distribution to the public at
no charge."

Now *one or more projects* means that is thought of leveraging not only
e.g. jarkata but all sub projects that may emerge. That needs a good
working PMC team that can trust each other (most important on legal
issues etc.). 

Why are we not adding to the committer role the 'PMC-incubation' label
and apply similar rules (we have in the incubator for exiting the
incubator cp [3]) to become a PMC member. That will as well make sure
that new members will *definitely* enter after "incubation" and overcome
the jarkata phenomenon.

In another thread you wrote about becoming PMC/committer:
> "...But we should not try to measure this with an absolute metric:
> merit does not earn membership, it earns trust of others members. If
> other members trust him based on the contributions, then IMHO there is
> all there is to it."

I develop trust with time. ...but I can trust somebody to make chances
(contributions) and I can trust someone making decisions. 

That is a different level of trust we are talking. I consider a clean
process of learning about the ASF as better. I started in incubator
(with lenya) to learn about the ASF and I still learn everyday.

Going from dev to committer and after "PMC-incubation" into the PMC is
IMO the best way to develop trust in someone. I think it is better as
limited committership or directly enter in the PMC (which normally takes
a good amount of time).

I hope this "real life" use case shows, that there are persons that will
welcome a guided process that as well contain a simple committership
"PMC-incubation" role.

[1] http://incubator.apache.org/
[2] http://www.apache.org/foundation/bylaws.html
[3]
http://incubator.apache.org/incubation/Incubation_Policy.html#Exitting
+the+Incubator
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message