incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Add 'practice' PMC structure to projects in incubation
Date Sun, 23 Nov 2003 15:10:31 GMT

Roy T. Fielding wrote:
> The ability to make ASF decisions starts with the board and is
> delegated to officers and their associated committees.  Anyone casting
> binding votes (meaning votes that are counted toward making a decision)
> must be listed as a member of the committee on which they are voting,
> even if their votes are limited to a subcommittee.  Therefore, my
> preference is for a fluid structure of incubating subprojects wherein
> every voter is listed as being in one or more core groups and the
> entire set of voters is listed as the incubator pmc.

Having had basically all opinions about this in the past years, and 
having been on diverse projects, I have come to the conclusion that I 
basically agree.

In particular, the Incubator PMC has been since the start an "umbrella 
PMC", similar to what Jakarta and XML, mainly because it cannot easily 
be made in a different way. This has made me see the shortcoming of the 
approach in clearer detail.

These months of incubations have showed us in clear evidence some basic 
facts that cannot be forgotten. The funny thing is that it's what we all 
know, but applied to the incubator it was hard to understand.

  1 - oversight must be done by the as many people as possible, just
      like more eyes see more bugs -> more mentors
  2 - the "management" of a project must be done by those that run
      the project day by day -> PMC==committers
  3 - it's ok to create "subprojects" in a project as long as the
      project remains united as one in decision making -> core groups

Let's make for example Cocoon, which can IMHO take advantage right now 
of this way of doing things.

Cocoon has already a set of committers that are all on the PMC.
There are two projects with close ties to Cocoon, that are Forrest and 
Lenya, Forrest under XML and Lenya in Incubation. Let's assume that 
Forrest goes under Cocoon and that Lenya exits incubation.

Cocoon as a project could as well consist of all long-stating committers 
of these codebases, and take all decisions together. This is already in 
part a fact, as the Cocoon PMC has started to vote a Lenya release as 
they feel part of the project, and Cocoon committers have access to Forrest.

Then there would be three core groups, one for Cocoon, one for Lenya and 
one for Forrest. There would this be a single project, a single PMC, and 
just a partitioning of competence on parts of code.

There is only one thing that would *really* change and that has not been 
done till now.

Committers could be given commit access long before having project 
member status, and would thus be able to commit but not vote. This makes 
it possible to keep a high bar for membership of the project but a lower 
bar for committing.

Is this possible/wanted?

> I am aware that this would mean incubating projects would be able to
> vote themselves out of incubation.  I think that if such a project had
> their shit together to the extent that they could run such a vote and
> get it past the majority of incubator members, then they no longer
> need to be incubated.

This is a possibility, that is ok for me.

Another possibility would be to define in the rules that the incubating 
project cannot voe itself out.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message