Differences between revisions 5 and 6
Revision 5 as of 2012-02-04 04:06:59
Size: 5030
Comment: use case for documentation request for Incubator docs.
Revision 6 as of 2013-04-02 00:58:53
Size: 5041
Comment: - update revised responsibility - voting takes place on general@ still
Deletions are marked like this. Additions are marked like this.
Line 34: Line 34:
||IPMC ||[VOTE] thread for incoming project ||Now takes place on members@, with recommendation tallied and sent to board@ by incoming project VP and/or ASF member on incoming PMC. || ||IPMC ||[VOTE] thread for incoming project ||Still takes place on general@incubator, with recommendation tallied and sent to board@ by incoming project VP and/or ASF member on incoming PMC. ||

There's been a lot of discussion about how best to improve the Incubator's current situation. I present my proposal for how below (this is based on the discussion largely around this thread: http://s.apache.org/S0i)

Steps

  1. Move the Incubator process/policy/documentation, etc., to ComDev - I agree with gstein on this. I think it could be maintained by the ASF community folks there, and updated over time. But it's not vastly or rapidly changing really anymore.

  2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on the back, go have a beer, watch the big game together, whatever. Call it a success, not a failure.
  3. Suggest at the board level that an Incubation "process" still exists at Apache, in the same way that it exists today. New projects write a proposal, the proposal is VOTEd on by the board at the board's next monthly meeting, and those that cannot be are QUEUED for the next meeting, or VOTEd on during out of board inbetween time on board@. Refer those wanting to "Incubate" at Apache to the existing Incubator documentation maintained by the ComDev community. Tell them to ask questions there, about the process, about what to do, or if ideas make sense. But not to VOTE on whether they are accepted or not.

  4. Require every podling to have at least 3 ASF members on it, similar to the current Incubator process.
  5. Operate podlings exactly the same as a TLP. There is a chair. There is a committee. Committee members have binding VOTEs on releases.

I present above what I feel are concrete steps that could be actioned upon that I believe would improve the overall process and bring to light what is already occuring.

Podlings are themselves distinct communities

Each will interpret our human laws and Apache doctrine the same as any other human when you put 10 of them in a room -- in 10 different ways.

Podlings are more and more able to pick up on the basic principles of the Incubator documentation; its legal oversight and its processes

They aren't perfect, but neither are any of us. It's pretty good and we've got plenty of RMs (as evidenced by other discussions) that can produce an Apache release that hasn't gotten us sued yet.

Mentors encourage their podlings to operate autonomously

general@ is often labeled "the wild west" and for good reason. If I went over to HTTPD and started spewing my OODT nonsense, many of you would scream foul and blasphemy just like I'd do if you guys came over into OODT and started flexing "your specific interpretations" of our commonly agreed upon mantra. That's what general@ is like. I don't think it makes sense, and I think those mentors who are doing a good job on their projects and those projects that are doing well would do well the same as TLPs. Many of the other side conversations around this issue are suggesting that -- why nominate folks for the IPMC when we could simply graduate the podlings?

Use Cases for Future Incubator Documentation Requests to ComDev

  1. We rename http://incubator.apache.org/ to http://incubation.apache.org/

  2. We direct all incoming projects to ComDev (dev@community.a.o) or some other list under ComDev's perview) to ask questions about Incubator documentation there.

  3. ComDev list gets question: directs folks to http://incubation.apache.org/ (maybe specific page, maybe just the main splash landing page).

Shifts in responsibility as part of this proposal

Committee

Previous Responsibility

Revised Responsibility

IPMC

Binding VOTEs on podling releases

Now in the hands of all incoming projects.

IPMC

Binding VOTEs on podling new committers

Now in the hands of all incoming projects

IPMC

Binding VOTEs on incoming projects

Discharged.

ASF membership

Binding VOTEs on incoming projects

Normal Apache VOTE'ing procedures.

IPMC

Production and dissemination of Incubator documentation

Now in the hands of ComDev

IPMC

[DISCUSS] and [PROPOSAL] for new incoming projects

general@incubator remains for this

IPMC

[VOTE] thread for incoming project

Still takes place on general@incubator, with recommendation tallied and sent to board@ by incoming project VP and/or ASF member on incoming PMC.

IPMC

Spots problems in the mentoring process

The project's PMC. And if not, the project's VP. And if not that, the board during the board report. Just like the current way it works for existing TLPs.

IPMC

Fixes problems with the mentoring process

The project's PMC. And if not, the project's VP. And if not that, the board or the membership. Just like the current way it works for existing TLPs.

IPMC/Legal PMC/Others?

Maintaining the standards with respect to IP management?

Arguably, legal and the Legal Committee have a hand in this, no? So, maybe just legal, combined with the existing documentation?

IncubatorDeconstructionProposal (last edited 2013-04-02 00:58:53 by ChrisMattmann)