incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject [VOTE] New Incubator rules and scope definition (long)
Date Fri, 12 Dec 2003 17:20:04 GMT

The "Incubator Reorg" threads have brought the Incubator to the 
definition of a new set of rules, that aim to simplify, streamline and 
generally make the process of incubation more effective.

It's time to wrap it up. Hence I ask to vote on the acceptance of this 
scope definition, which is the start of our charter, and on the proposed 
line of action, specifically on the project spinoffs and on the creation 
of PPMCs.

My Vote: +1



There are no subprojects in Apache, only Projects that are usually
called Top Level Projects or TLP. Thus the Incubator works for 
incubating Projects.

Incubator Scope

The Incubator shall better define its scope as:

1 - incubation of Projects, intending incubation of external codebases
     and communities that wish to become Apache Projects (TLP)

2 - assistance of projects that are importing new codebases and new sets
     of committers that formed an outside community, when requested
     by the project doing the "import"

3 - definition of and maintainance of the policy projects should use
     when importing external codebases, therefore creating a clear
     audit trail for all donations

1 - Incubation of projects

= PPMC Proposal =

== Description ==

To make Incubating project learn to govern themselves and govern 
themselves at the same time, each project gets a PPMC, that is a Project 
PMC (is this right?) that works similarly to a PMC but refers to the 
Incubator PMC instead of the board.

== Who should be on each ppmc? ==

  * all members of the future PMC (committers + landing PMC members)
  * all Incubator PMC members

This means that the Mentors would be the only ones that must stay also 
on the other project mailing lists.

The PPMC would consist of *all* PMC members from both the landing PMC 
and the Incubator PMC, plus the committers. It's advised though that all 
committers be on the landing PMC.

The Mentors would be the ones required to participate on the -dev list.
The rest would have to "catch up" to the extent that PPMC discussion 
requires external context.  Otherwise, it won't scale.

Committers would be on the PPMC but not on the Incubator PMC.

Incubator PMC members not engaged in active discussion and development 
on a project are on the project PPMC in quality of observers. They 
should refrain from voting on PPMC decisions unless really necessary, 
thus acting as vetoers of last resort.

== Reporting the the main Incubator PMC ==

Development and discussions will still go on the dev lists, and only 
Mentors have to be there.

The status update issue would occur on the PPMC list, which *IS* the 
union of the Incubator PMC, the Cocoon PMC and the Lenya Committers. 
That is what the notion of reporting to the "main Incubator PMC" is a 
non-issue.  The correct issue is reporting to the PPMC.

The PPMC would be the means by which a project is governed.  The PPMC 
list is the private list for its use.  The PMC is for the Incubator, itself.

As I am envisioning this working, if there is an issue to be addressed 
by the PPMC, and that issue is to be discussed in public, the PPMC would 
have to subscribe to the public list for discussion.  There would be a 
summary posting to the PPMC list letting everyone know of the issue, 
with references to the archives.  That appears to balance providing 
oversight with being overwhelmed.

== What to do to start PPMCs ==

JFDI applies. Every PMC member and every ASF member that had something 
to say about the PPMC idea
was basically in favor. We have consensus on the broad plan; enough of a 
mandate to get things underway. Create
a PPMC battle plan and execute.

This entails the following:

1. ask infrastructure@ to create a new set of mailing lists


2. get a few moderators && incubator pmc members in
place for each, have them subscribe the appropriate people
to it, or at least send out the invitations

3. send out welcome messages on the newly created
mailing lists, explaining purpose and basic organisation,
with appropriate disclaimers

4. figure out what issues we can and cannot deal with
inside a PPMC as we go along**

** big design up front doesn't work well for software;
I think it works even less well for communities.

2 - Assistance of Projects that are importing new codebases

With new codebases, projects have to deal with new community integration
and code import IP issues. The Incubator would be a place where they can
find documentation about what to do and seek help on the lists.

3 - Code Audit Trail

All PMC Chairs can accept codebases on behalf of the ASF.
We shall create and maintain for them a simplified checklist to be placed in


that they can use to do IP clearance.
This is to create a trail that clearly shows what has been done in the 
import of the new codebase, all in a single place.

                               - 0 -

Project spinoffs

We have to reassess the status of all incubating projects WRT the new
rules, and add the needed PPMCs.

- AltRMI: decide where it wants to land
- FTPServer: decide where it wants to land
- Geronimo: make PPMC
- JaxMe: pass it on to the Webservices PMC
- Juddi: pass it on to the Webservices PMC
- Lenya: pass it on to the Cocoon PMC
- Pluto + Wsrp4j: pass it on to their sponsoring PMCs and suggest
                   them to form a TLP when possible
- XmlBeans: move to Xml PMC
- Directory: create PPMC
- Ruper: create PPMC

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