(note; due to the flat namespace of the wiki, you might think that this is something official. It's not. It's BensonMargulies drafting an idea for discussion.)
- The incubator usually works.
- The incubator sometimes fails. Not every podling failure is an incubator failure. The podlings that fail due to lack of supervision are incubator failures.
- The IPMC has trouble articulating how supervision is supposed to happen. Is it mentors? Is it shepherds? Is it random IPMC members spot-checking releases?
- The IPMC is too large to be an effective policy-making entity. That doesn't mean that it _never_ makes policy, just that the process is very unpleasant.
An Alternative: The Incubator Committee
TL;DR: 'podlings' inside an IPMC are replaced by 'probationary projects' (pTLPs)'. The board delegates supervision of these projects to an 'Incubator Committee' that replaces the IPMC; this allows them to receive extra scrutiny without swamping the board. The board retains ultimate responsibility.
Incubator Committee Mission
The mission of the incubator committee is to extend the reach of the board in the supervision of new projects. This includes the following specific areas of responsibility:
- Evaluating proposals for new projects
- Supervising probationary projects:
- * Reviewing reports
- * Reviewing releases
- * Recommending graduation from probation or retirement
- Providing assistance in working with the rest of the Apache organization
- Creation and maintenance of documents describing the incubation process.
Note, critically, that this is not a 'Project Management Committee'. It does not make releases. It may grant commit access to volunteers who wish to assist in the creation and maintenance of documentation and tools.
The board shall appoint a chair, vice-chair, and members of this committee. There will be a fixed number of members (15) who serve for fixed terms; the committee will not grow organically. It is likely that the committee will assist the board in identifying candidate members.
New Project Lifecycle
All proposals for new ASF projects must include an initial PMC chair and an initial set of PMC members. These people must be acceptable to the board. It is the responsibility of the Incubator Committee to vett these people. All of them must have experience on existing PMCs. These people are volunteering for the full responsibility of a PMC. They may work dilligently to put themselves out of jobs by mentoring and grooming new people, but the onus is upon them to convince the Incubator Committee that the project is ready to leave its project supervision. They may also not work themselves out of jobs. If a set of existing Apache contributors want to start a new project, that's fine.
Once the Incubator Committee recommends, and the board establishes a new project, it becomes a 'probationary project' (pTLP). The term 'podling' will be retired. Probationary projects, legally, are full ASF projects. The Incubator Committee assists the board to give them extra supervision, period.
After a reasonable period of time, a probationary project may request graduation to normal status. This, again, requires a recommendation from the Incubator Committee and a resolution by the board.
If a project fails to achieve critical mass (or hits an IP pothole or some other insurmountable impediment), its PMC should retire it to the attic.
If the Incubator Committee observes serious problems, it will recommend appropriate actions to the board, up to and including retirement.
The existing 'disclaimer' policies for markings and PR of podlings carry forward to apply to probationary projects. Probationary projects are 'undergoing incubation', so that much of the existing documentation could be adapted.
The IPMC podling scheme looks to new people to learn how Apache projects work by reading, watching, and asking mentors. It then asks those people to function as a PMC, and looks to their coaches to supervise them.
The scheme here is more conservative. It demands that the project begin with a set of people who already know what to do, and lets them get on with doing it. I submit that the ASF is now so large that this idea is practical; it might not have been so practical when the IPMC was designed.
I don't claim that this scheme is truth handed down on tablets; it's an alternative, and I claim that it addresses some people's stated discontents. It delegates new project policy to a group small enough to make decisions; it replaces a sometimes fuzzy path of responsibility with a much clearer one.
It does not guarantee success. If the people who sign up as initial PMC members don't do a good job, the new project will fail. The committee described here will have a difficult time vetting would-be members of new TLPs.
It also avoids the problem of deconstructing the existing scheme without a clear path to replacing it.
- A group of volunteers steps forward to serve as the initial membership.
- The board tentatively accepts this idea.
- The group would undertake the rather large project of producing an initial website of documentation laying out this new scheme.
- The group would offer up their work for board evaluation.
- When the board was satisfied that there was enough documentation for the scheme to operate, the board would establish the committee and off we would go.
Note that the new committee could operate in parallel to the IPMC for some period of working out the kinks, or, if you prefer, discovering if this idea works at all.