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 13:47:21 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=4&rev2=5

- 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. There are contrasts to the 'no
more incubator' proposal in here. I think that the upshot of this proposal is to offer 'less
incubator' as an alternative to 'no incubator.' You might also read this as offering some
ideas about details of a no-incubator universe.
+ 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 =
  
@@ -8, +8 @@

  
   1. The IPMC evaluates and approves new projects.
  
-  1. The IPMC contains projects until they clear IP and demonstrate a stable core group including
three experience ASF participants.
+  1. The IPMC contains projects until they clear IP and demonstrate a stable core group including
three experienced ASF participants. Exceptions are possible by board approval.
  
   1. Podlings graduate from the incubator to probationary status at that point, and leave
probation at the board's discretion.
  
+  1. The IPMC works with ComDev to improve the Foundations' documentation on releases and
such.
  
+  1. 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 work, and positive brand presence, at that. Just because
we've tired of 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 the go-to place for incoming projects. Its web site provides a clear target.
It has 'brand presence' in the outside work, 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. 
  
@@ -33, +35 @@

  
  = IP/Release Supervision =
  
- I have listed this separately because it is a problem area. No one, I think, 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. However, I perceive
a box on Chris' proposal's blackboard drawing labelled 'a miracle happens here.' 
+ I have listed this separately because it is a problem area. No one, I think, 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; or, perhaps, I'm concerned 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 problem. 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, know, group. Like, 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 someone
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.
+ 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 project, and the board has been discontent with the quality
of the IPMC's work on its behalf. On the other hand, I think that we've demonstrated that
a few volunteers within the IPMC can step up and improve this. Chris' proposal is 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 TLP's. 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 TLP's on training wheels
could be a problem.
+ The board needs to supervise project, and the board has been discontented with the quality
of the IPMC's work on its behalf. On the other hand, I think that we've demonstrated that
a few volunteers within the IPMC can step up and improve this. Chris' proposal is 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, Begging for Votes, and Podling Lifetime =
+ = 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.'
  
@@ -53, +55 @@

  
  Chris' proposal 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.
+ 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 less 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?
+ 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.
+ 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.
  
  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?
  

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


Mime
View raw message