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 tra
