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 RalphGoers
Date Sat, 04 Feb 2012 16:31:36 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 RalphGoers:
http://wiki.apache.org/incubator/AlternativeIncubatorAnalysis?action=diff&rev1=6&rev2=7

  
  The IPMC is a resource here. It has a public mailing list, and that list reaches people
who have useful experience. 
  
- This leads to my first major qualm about Chris' proposal: everything good, useful, or necessary
about the existing PMC is dumped upon ComDev. There is, in my mind, some circularity to the
argument here. "The incubator is a cesspit, so we should dismantle it. Oh, *that* essential
function? ComDev can do it."
+ 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.
- Writing as a low-intensity ComDev participant, I think that this would be more accurate
to write, "IPMC members of good will can join ComDev." The result, I claim, is to recreate
a very substantial subset of the incubator as we know it under the (more confusing) name of
ComDev.
- 
- Evaluating proposals has not been a big topic of controversy. Still, I wonder if we'd have
fewer problem podlings if we had, well, fewer podlings. In fact, I'm sure that this is 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. Personally, I find the 'members@' suggestion
laughable. 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. Is ComDev to become the
IP Clearance department, too? 
+ 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. Is ComDev to become the
IP Clearance department, too? As with evaluating proposals, the IPMC currently helps perform
this function and there is no need to shift the responsibility elsewhere.
  
  = 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. 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.
+ 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 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.
  
@@ -43, +41 @@

  
  = Overall Project Supervision =
  
- 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.
+ 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 =
  
@@ -53, +51 @@

  
  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' proposal solves this, absolutely. Constitute a project with a few people the board
trusts, and delegate to them.
+ 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.
  

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


Mime
View raw message