forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <>
Subject Re: Simple committership
Date Tue, 09 Aug 2005 03:52:53 GMT
On 8/6/05, Thorsten Scherler <> wrote:
> 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."

The analogy to the Incubator breaks down past a superficial level I
think.  I personally feel that everything (i.e. how Foundation works,
how to get things done, in general, the Apache Way) in the above
paragraph are, for an existing project, the responsibility of existing
committers/PMC members.  People *get* Apache because of other People,
not because of roles, responsibilities, or other stuff.  The Incubator
exists as a way to allow those People to connect, whereas, in an
existing project, that way to connect already exists.  "Being a PMC
member," much like being a developer in general, is a continuum rather
than a goal.  Meaning it's a learning process and picking out a point
an individual is on along the process is subjective.  My understanding
is that our way to resolve that "degree of understanding" issue is by
way "trust", meaning I don't know where exactly they are or if they
are far enough along the learning process, but I *trust* that they'll
get there.

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

I'm probably more laid back than most but I feel absolutely no
pressure.  Learning it to it's "fullest" is too subjective.  We have
to trust that the person is committed to learning it rather than
already knows it.  I guess I think of it the same way as when
interviewing to hire someone -- I don't care as much for what they've
*already* accomplished as much as I do for what I think their
*potential* for accomplishing things are.  In our case, through
patches and community discussion we've got a better idea for what that
potential might be than does a normal prospective employer.

> 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".

Again, I'd suggest that your a and b are the responsibilities of the
PMC and existing committers.  I think the way the project works will
probably already have been learned by the time someone feels ready to
vote a person in.  The way the foundation works is, again, a
continuum.  Because of the nature of the foundation, it's just not a
binary thing -- I'm comforted by the fact that there are some
experienced foundation folks still asking some tough questions on the
community list -- if the foundation was "knowable" in a binary sense
this likely wouldn't be happening.

> 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 personally wasn't overwhelmed.  The docs are fairly good except for
the pitiful email situation.  Again, I'm comforted knowing that there
are existing folks to ask and will be responsive to my questions.  I
can't imagine that I would be more overwhelmed or 'pressured' by
simply knowing that the +/- 1 that I would cast anyway is binding or
not -- I trust it would be considered seriously either way.

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

Not formally, but I think we *do* have our own little version of it by
way of the mentoring that goes on via existing PMC/committers.

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

While your path has clearly worked well for you, I don't think it's
necessary.  I personally think we're better off considering folks time
as developers/contributors as their implied "incubation" period.  If
you feel they've incubated then nominate them; otherwise, don't.  In
other words, we've either learned enough about contributors to trust
them completely or not. And by "trusting them," I mean we trust they
care enough to continue in earnest to learn the Apache Way.

On a side note, not that we should necessarily consider this... but
it's worth mentioning that there's a social factor to all this as
well, right?  I mean, let's be honest, it'd suck to be the new guy/gal
voted in as a committer-only to Forrest knowing that all before you
are PMC members as well.  I suppose I bring this up because whatever
course is taken, it should probably be all or nothing -- in other
words, we either say everyone goes through the commitership->pmc
incubation->pmc track or everyone goes directly to PMC as it is now;
there's not enough objective criteria to distinguish between the two
on an individual-by-individual basis.

View raw message