In response to the current march to the Bastille, IPMC-wise, I wanted to try to organize a set of thoughts about the existing incubator's purpose, warts, and possible future directions. This is organized by the major responsibilities of the PMC. The first section here is a brief summary of a vision of a 'less incubator' alternative to the 'no incubator' proposal. This is followed by sections examining particular areas of the Incubator's work.

Summary of Alternative Proposal

1. The IPMC shrinks, it does not die. While podling mentors need to be approved by the IPMC (usually by accepting the podling into the incubator) they are not required to be IPMC members.
   
2. The IPMC evaluates and approves new projects.
   
3. The IPMC contains projects until they clear IP and demonstrate a stable core group by
   1. including three experienced ASF participants, or
   2. successfully completing the release process along with a recommendation from their mentors.
      
4. Podlings graduate from the incubator to probationary status at that point, and leave probation at the board's discretion.
   
5. The IPMC works with ComDev to improve the Foundations' documentation on releases and such.
   
6. The IPMC serves as a group of willing volunteer resources to *assist* projects with IP and release management.
   
   

Groom & Evaluate Proposals for new Podlings

The IPMC is the go-to place for incoming projects. Its web site provides a clear target. It has 'brand presence' in the outside world, and positive brand presence, at that. Angry email exchanges (and other more material problems) has not (yet) translated into the outside world seeing the Incubator as some sort of a crocodile-infested moat around the ASF.

The IPMC is a resource here. It has a public mailing list, and that list reaches people who have useful experience.

The IPMC already has experience with this. Transferring this responsibility to another PMC accomplishes very little for no obvious purpose other than to eliminate the committee currently performing this task.

Evaluating proposals has not been a big topic of controversy. One may wonder if we'd have fewer problem podlings if we had, well, fewer podlings. In fact, that is obviously true, but it doesn't make it a great idea. In any case, board members reacting to Chris' proposal have asked for someone else than them to evaluate. Using 'members@' for this purpose is laughable as it has no public mailing list, no leadership, no track record in making decisions. If the IPMC is torn down as we know it, *something* else will have to be invented if only for this job.

IP Clearance

The IPMC is the official home of IP clearance. It's a somewhat complex topic that the TLPs don't deal with all of the time, and new projects do the most of it. As with evaluating proposals, the IPMC currently helps perform this function and there is no need to shift the responsibility elsewhere.

IP/Release Supervision

This has been listed separately because it is a problem area. No one enjoys watching a podling struggle though seven release candidates as IPMC members randomly identify problems one at a time. Anger at this process has fueled much recent discussion. It is not clear to me that demolishing the incubator cures this. It is also a concern that the current problem will be replaced by the opposite problem.

The underlying problem with the current process is not an oversupply of control freaks or petty despots, pacé Bill, but rather an undersupply of clear documentation. Pacé Leo, it's not necessarily lengthy, detailed, picky documentation. If podlings and mentors knew where to go to find a clear, concise, statement of the requirements, they would be well on the way to avoiding gauntlets.

That's not the only issue. There's also little to like about the 'throw a rock in the @general pond and see who crawls out to review the release' process. It would be better if any given release were to be reviewed by a small, known, group. For example, the mentors of the project. This, in turn, would require the mentors to include at least one person who understands the policies and is ready and willing to do the detailed reading. Alternatively, people with special talents or interests in this area could make themselves available. Critically, once some*one* signed up a release reviewer, they would see the process through, so we would drastically reduce the situation in which each candidate attracts a new reviewer who finds new things to poke at.

Overall Project Supervision

The board needs to supervise projects, and the board has been discontented with the quality of the IPMC's work on its behalf. On the other hand, we think that it has been demonstrated that a few volunteers within the IPMC can step up and improve this. A proposal has been made to eliminate the intermediate layer altogether. (Later in this document, I'm going to propose an intermediate alternative.) We have many new projects and are likely to have many more. Is flattening the structure really the right way to go? At the board level, there has been some sporadic discussion about how to scale the board's supervision across all the TLPs. Even in this discussion, Bill Rowe pointed to the need for members to actively serve as the board's eyes and ears. This could argue either way. If the Foundation got better at scaling supervision, that could be applied to new projects as well. If it does not, a flood of new TLPs on training wheels could be a problem.

Self-Governance Trajectory and Begging for Votes

My initial positive reaction to Chris' proposal resulted from a gut reaction, 'here's the solution to the problems that have led to endless hostile email between Joe and Bill.'

When a podling graduates, it's self-governing. When it starts, not so much. How do we get it from here to there? Begging for votes, in my opinion, is a symptom of our lack of a process for this.

Joe's proposals and experiments have a common theme: delegate progressively more authority into the podlings. The arguments aren't about whether this is a good idea, but rather about how to do it. Given a conventional PMC structure for the IPMC, the only way to really delegate authority is to make more people IPMC members. This, in turn, gives them a role in broader governance that some people find objectionable.

Chris' solves this, absolutely. Constitute a project with a few people the board trusts, and delegate to them.

I ask, however, 'Does this have to happen at inception?' We could construct a lifecycle for projects with three instars: podling, probation, and TLP. New projects could live in an IPMC until they complete IP clearance and show an understanding of basic governance. Then they could become probationary projects, as in Chris' proposal.

The natural size of an IPMC in this scheme is smaller, since there will be fewer projects in it. This would alleviate the 'if 100 people are in charge no one is in charge' problem.

Should a probationary project still have 'incubator' slapped all over its mailing lists, release bundles, and website, like a leper carrying a bell? I don't know.

The chart below shows a way to do this that still uses the standard Apache governance model; releases and committers are always voted by a PMC. For the (brief) inception of a podling, this would be the IPMC. Thereafter, it would be the project itself, just as in Chris' proposal.

There are other ways that the board could structure the IPMC to allow progressive self-governance that would cut through the dispute about 'IPMC membership'. Really, this is about release voting. What's wanted here is a way for 'evolved' podling personnel to have binding votes on their podling releases without (necessarily) granting them other less-earned status. Reflecting a remark of Roy's in an email, the IPMC could be charged by the board as supervising the initial function of self-governing podlings. The podlings would still do all the voting, but each vote would be 'acked' by the IPMC, giving it a brief period of time to stop the train and wade into the process. In either case, there's no need for the mentors to be IPMC members.

I think that the board process in this area deserves another moment's thought. If a brand-new project elects its first new PMC member, does the board really want to rubber-stamp it with the usual ACK process? I hope not. I hope that the board wants at least one member to see some evidence to support the nomination. Does the board really want to be taking this time? Or would the board prefer a small IPMC to persist for this purpose?

Areas of responsibility as part of this proposal

Notes

Note 1: It's hard to see why a project in this scheme would end up releasing more than once before moving out of the incubator's supervision.

Note 2: As above, an option is for this to change to 'the project with oversight of the IPMC'.

Note 3: I would expect that the typical process would be to leave the incubator before adding any new people, but this allows for the possibility. Also see note 2.

Are We Barking Up The Right Organizational Tree Here?

One of Bill Rowe's email messages emphasized the fact that this is all about a proposal to the board to change how the foundation adopts new projects. This could lead to a further thought: Assuming continued success, how will the Board supervise 100 projects? And would there be a natural variation on one proposal or the other that fits into a scaled supervision structure?