incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Update of "IncubatorDeconstructionProposal" by ChrisMattmann
Date Fri, 03 Feb 2012 16:17:12 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The "IncubatorDeconstructionProposal" page has been changed by ChrisMattmann:
http://wiki.apache.org/incubator/IncubatorDeconstructionProposal?action=diff&rev1=1&rev2=2

Comment:
My proposal, formatted. Banter removed.

+ 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)
- 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.
+  1. 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.
+  1. 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.
+  1. Require every podling to have at least 3 ASF members on it, similar to the current Incubator
process.
+  1. 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.
- 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. 
  
+ = 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?
- 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'm sure folks will argue this is blasphemy or that it will just add to the board's
- work, or that .... I'm ugly ... whatever. The fact of the matter is we kick spinning
- around in circle's trying to fix process issues that have been band-aided for 
- years and that are now leaking like a sieve whenever we decide it's time to 
- shine a light on them. When things are going "well" in the Incubator, it's not 
- because they are well. It's because no one is asking questions and they've
- chosen to ignore some of the gaping holes on the poor wounded body that
- remains. And then when some folks go and point out the gaping holes, we 
- get these huge song and dances that don't amount to anything other than
- the old mantra "incremental change; don't rock the boat too much; XXX board
- member won't go for it; not here at Apache". Whatever.
- 
- I think the board knows there is an issue with the Incubator. A lot of IPMC
- members do too. Some of us have spoken up; others haven't. 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:
- 
- 1. podlings are themselves distinct communities and 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. 
- 
- 2. 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.
- 
- 3. 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?
- 

---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message