incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Roles: user, committer, member, etc.
Date Wed, 14 Sep 2005 06:04:30 GMT
Leo Simons wrote:
> David Crossley wrote:
> > One thing that is bothering at the ASF is not having a
> > clear definition of the various roles.
> Hmmm. I think there's a lot of people not bothered though.
> Not being clear may even serve a purpose.
> > We seem to be having endless discussions at some
> > projects about what it means to be a committer and
> > a PMC member and an ASF member.
> Indeed. I have a hunch that "re-inventing the collaboration wheel"
> is a significant part of "the apache way". An organisational
> structure that is completely patching itself at every level has a lot 
> of appeal.

I partially agree. However when that re-invention occurs
because of poor documentation, then we have a sad state
of affairs.

It is interesting to look at the following woeful document
and its svn history (i.e. no changes since initial minor doc):
In particular see the last section. It encourages
new incubating projects to follow the "Jakarta way".
Not blaming Jakarta, but it seems silly to point to
an umbrella project as "the" way to do things.

> Other projects *never* discuss any of this. They just write code.

I wonder if these projects are bringing on new committers
and explaining the intricacies to them.

> > It seems that over the years too much distinction
> > has been made and some the roles have become confused.
> > For example [4] says that "committers" have the
> > right to vote on community-related decisions
> > and [5] has that as the PMC member.
> As the ASF has grown, it has also grown more formal. If you look back (for example) to
> beginnings of and later you'll see that there wasn't
a whole lot 
> of design to the seperation between these roles. Heh. was a  rather sizeable

> trademark violation. Can you imagine something like that happening now?
> If you go a little further back in time, eg
> there is no definition of "committer" or "member" or "pmc", just "Apache Group members",
which is 
> not further defined.
> As Jakarta people "moved up the ranks" the process documentation written (I think by
Jon Stevens 
> initially) moved up with them. When that happened people disagreed with that process
and it got 
> patched. Some patches found their way back into the processes of various TLPs. Which
bits hasn't 
> been overly co-ordinated.

The mismatch has probably arisen because of the old
experiment with such "umbrella" projects.

> Compare
> ...
> TCL talks of a "project maintainership committee". HTTPD still refers to "Apache Group"
every now 
> and then. Maven, SpamAssassin and Geronimo don't describe their processes at all on their
> XML says "The Chairman or any member may be removed from the PMC by a 3/4 vote of the
PMC" which is 
> false (the chairman is a board-appointed officer and cannot be removed by the PMC at
all). Gump defines 
> "committer" but doesn't actually really keep track of them (when gump went TLP there
was really no 
> initial list of people that might be considered PMC members) because all of Apache is
allowed to 
> mess around with the code. Beehive has 0 pages devoted to saying something like "get
involved!", the 
> only thing that comes close is a news blurb on their front page. SpamAssassin has a list
of PMC 
> members at the top of their CREDITS file with links to Amazon wishlists. That's smart
innit! :-)
> There are only a few truly authoritive references:
>  *
>  *
>  *
> I think none of these ever talk of "committers" formally.
> Also note that the second one specifically tasks new PMCs with defining their own bylaws,
>        RESOLVED, that the initial XXX PMC be and hereby is
>        tasked with the creation of a set of bylaws intended to
>        encourage open development and increased participation in the
>        XXX Project.

That is one reason that i am raising it. This job falls through
the gaps and seems to be why our communities are not functioning

> yet there are loads of projects that don't have anything marked as "bylaws". So we have
a project 
> going through two years of incubation and community building, then they are tasked with
only a few 
> things (oversight, project growth, establish bylaws) and they often fail 1/3 of that
> We have *loads* of inconsistencies, and a lot of the stuff on the main foundation site
is not 
> consistent with stuff on the pages of many TLPs. I don't think we're going to be able
to solve that
> completely, and I think the incubator shouldn't task itself with that either.

So if not Incubator, then who? And if not, then we had
better remove the second paragraph of the Incubator
home page.

I wonder if it might be better to simply remove a stack
of that top-level documentation, particluarly this "Roles"
section of the "How it Works" document. Then simply say
"go see each project for their own guidelines".

However that puts a big load on each project to revisit
such definitions, particularly if they do not have active
mentors who have some insight into the rest of the ASF.

Ah. Going to board_minutes_2002_10_16.txt where the Incubator
was established ...
"educating new developers in the philosophy and guidelines
for collaborative development as defined by the members
of the Foundation".

That probably puts the ball back in the court of
the Incubator, because i don't see such guidelines
being developed elsewhere, other than Infrastructure
trying to dig themselves out of the hole.

> > I think that the first two sentences of the PMC
> > role in [5] need to move back into the Committer role.
> Hmm. That page does seem a little out-of-sync with common practice.

As i showed, it developed that way with influence
of Jakarta and my efforts to fine-tune the docs
may have exacerbated the situation.

> > The PMC role should then stress that it is up to
> > each project to define the composition of its PMC.
> Actually I think that is up to the VP for the project, formally,
> which was established through board resolution.

Yes, that is what i meant to say. Hopefully the chair
also has the support of the project.

> > If no-one says otherwise, then i will change that.
> I'm not saying otherwise :-)
> > I presume that even though committers can vote on
> > project decisions, it is still its PMC that has
> > the binding votes.
> Officially, "committer" does not exist, so, officially,
> a "committer" cannot do anything "binding" on behalf of the ASF.
> If someone uploads a release somewhere without a PMC vote,
> then that action is > not on behalf of the ASF. Etc.
> > Are there any other clarifications that are needed?
> I dunno. I don't know where you're coming from,
> eg I'm not too sure what problem you're solving.

My main issue is that the developer communities which
we are trying to encourage, are totally confused
about what it means to be a committer and PMC member.

The problem is exacerbated when we have an existing
committer from another project. They bring their
ways to the other project, and we go through another
endless discussion.

We are now seeing a new thing happening as a result
of the Google Summer of Code and other situations at
the Cocoon-based projects, which are introducing
concepts which might lead to classes of committers.

> Hope this helped a little, regardless :-)

It did. Said many of the things that i had left unsaid
and shows that confusion reigns. No wonder we have
a hard time incubating new projects, and then having
them run smoothly and understand what it means to be
a committer or a PMC member.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message