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 "AlternativeIncubatorAnalysis" by BensonMargulies
Date Sat, 04 Feb 2012 18:55:09 GMT
Dear Wiki user,

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

The "AlternativeIncubatorAnalysis" page has been changed by BensonMargulies:
http://wiki.apache.org/incubator/AlternativeIncubatorAnalysis?action=diff&rev1=10&rev2=11

  
  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.
  
- 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. Chris'
proposal is clearly the simplest and clearest way to accomplish that, but, I'm arguing here,
may have a problematic ratio of baby to bathwater.
+ 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 =
  ||<tablewidth="962px" tableheight="187px"style="font-weight:bold;">Task ||<style="font-weight:bold;">Current
Responsibility ||<style="font-weight:bold;">Revised Responsibility ||
  ||IP Clearance Supervision||IPMC||IPMC ||
- ||Binding VOTEs on podling releases (note 1)||IPMC||IPMC||
+ ||Binding VOTEs on podling releases (note 1)||IPMC||IPMC (note 2)||
  ||Binding VOTEs on probationary project releases ||IPMC||PMC ||
- ||Binding VOTEs on podling new committers (note 2)||IPMC||IPMC ||
+ ||Binding VOTEs on podling new committers (note 3)||IPMC||IPMC ||
  ||Binding VOTEs on probationary project new committers ||IPMC||PMC ||
  ||Binding VOTEs on incoming projects ||IPMC||IPMC||
  ||Production and dissemination of Incubator documentation ||IPMC||IPMC ||
@@ -80, +82 @@

  
  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 2: I would expect that the typical process would be to leave the incubator before adding
any new people, but this allows for the possibility.
+ 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? =
  

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


Mime
View raw message