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
----8-<----------8-<----------8-<----------8-<---
Prolog ================
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
[EMAIL PROTECTED]
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
committers/audits/
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
