incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Incubator, or "Incubation"?
Date Thu, 02 Feb 2012 16:56:16 GMT
Hey Greg,

First off, thanks for commenting on this. My 
replies below:

On Feb 1, 2012, at 6:38 PM, Greg Stein wrote:

> On Wed, Feb 1, 2012 at 21:22, Mattmann, Chris A (388J)
> <chris.a.mattmann@jpl.nasa.gov> wrote:
>> Hi Bill,
>> 
>> On Feb 1, 2012, at 3:26 PM, William A. Rowe Jr. wrote:
>> ...
>>>  VP Project Incubation
>>> works with those Champions.  Much like the foundation-wide security@a.o team
>>> works with all the individual projects as a resource, but isn't responsible
>>> for the oversight of individual project security defects.
>> 
>> Yeah, I get what you're saying. You say the VP Incubator is a resource, but to me
>> the role is the head of a committee that just adds extra burden and overhead to
>> what should inherently be distributed and decentralized.
>> 
>>> 
>>> I don't see this working without an appointed coordinator.
>> 
>> 
>> I do :) just with the coordinating living within the project, just like TLPs,
>> and that's the Champion/VP of the podling.
> 
> This proposal creates a differentiation between "normal" TLPs and
> "incubating" TLPs.

I honestly didn't mean to do that, but I can see how it could be
interpreted that way. I don't want to distinguish between them. Let's 
just say that they are projects like any other projects, with the following
principles:

1. In the Incubator proposal used to run by the membership to 
create the project, at least 3 of the initial PMC members must be
ASF members.

2. A proposed VP (or Champion either name is fine with me) should
be identified as part of the submitted proposal. That is the PMC chair,
until otherwise changed by board resolution just like any other project.

> The incubating TLPs have extra restrictions on them
> (branding, releases, etc), and they need extra tracking to determine
> whether they are ready to graduate.

This is true, but in reality they aren't extra restrictions they are simply
specific brand guidance, given to any other TLP, along with the 
special Incubator stuff.

> I can easily see a small group of
> people maintaining that overall status and recommendation to graduate.
> I can see this group shepherding the initial incubating-TLP resolution
> to the Board. (a graduation resolution, if needed, could easily be
> handled by the TLP itself by graduation time)

I can see what you and Bill are saying too and it's not a blocker for me, 
but I'd urge you to consider the extra overhead that it would add, compared
to the benefit of simply saying, the incoming project is simply any other 
ASF project, has the notion that those 3 ASF members that MUST be 
on the incoming project's PMC as identified in their proposal. And that
those 3 ASF members could come from a collective set of what you guys
are saying is this special, reduced IPMC like entity. I'm guessing that
organically that's what would happen anyways. Only a small set of 
ASF members will volunteer to be on these incoming projects and help
shepherd them in just the way it works today.

> 
> Mailing lists need somebody to "own" them, too, or they end up in a
> weird state. This new-fangled Incubator group would be the owner of
> the general@ list where proposals come in and are discussed.

Yeah I agree, but can't we say that ComDev "owns" general@incubator
after my proposal is implemented?

And yes, I forgot to specify this initially well didn't forget, I just didn't think of
it, so thanks for you and Bill and for discussion to help flesh it out. I'd like
to add that to my proposal. ComDev owns general@incubator.

> 
> The VP of an incubating-TLP has ASF experience, but is otherwise "just
> another peer on the PMC" and is the liaison with the Board. I'm not
> sure that it makes sense to give them these "extra burden[s]" that
> you're talking about.

I think it's the same burdens that all VPs get, which is what the projects
should be striving for from day 1. We always have this odd situation
in the Incubator to date when a new project starts, especially with 
an elected chair that isn't used to interacting with the board. There's 
some knowledge that has to be gained, so outright even after graduation
the podling has some learning to do under the existing method and so does
its VP once it becomes TLP. Let's start that learning, day 1, and get them
interacting and just call them regular projects.

As Bill stated, before the Incubator, this is what you guys did anyways. I'm just
saying let's go back to that in the ASF, WITH the added benefit that now the
Incubator over its lifespan has delivered to us, the foundation:

1. a set of awesome guidelines, policies, procedures and documentation. Its 
new home will be ComDev. ComDev does that anyways like you said, and
I agree with that.

2. a process, a great process that new projects coming into the ASF should 
follow to start operating as ASF TLPs, from the get go.

3. great knowledge and discussion forever archived fleshing out the 
boundary cases of many of the parts of our foundation. Thank you 
Incubator for this.

That being said, with 1-3, some help from ComDev (which I think they 
aren't opposed to, but would be happy to cross post, or raise a new
thread over there to make sure), and with the existing attitude of many
of the IPMC members that care about bringing projects into the foundation
(which includes a majority of board members who are also IPMC members, or
at least read the Incubator MLs), I think we're fine. No need for the position 
anymore. Just another report to have to read as a board member, and
someone to middle-man, when what the board ought to be doing is
talking to the new project's VP, day 1.


> Decentralization is good, but I concur with
> Bill's analogy to security@ -- a group that helps to start and track
> the incubation status of some of our TLPs.

I hear what you guys are saying and if it's the only way to get some change 
around here I'll listen, but I just don't think it's needed. It's another meta-
committee, with no purpose. The purpose and deliverables are here, and
can go forward and be used.

> 
> By the time a TLP is ready to graduate, they might be self-aware
> enough to self-certify, but I'd be more comfortable with an Incubator
> group doing the review and recommendation.

Can't this just be the membership of the foundation? That's the Incubator
group going forward. With 100+ IPMC members, and with the basic tenant
today that any ASF member can simply be an IPMC member with an ACK
and with 99% of the Incubator PMC being ASF members, I think that naturally
follows. 

> 
> All this said, I can see an argument to combine this "Incubation"
> function/operations with ComDev. Certainly, the latter will have all
> the education resources. The question is whether the execution is
> distinct or rolled into ComDev.

+1, yep you and I are eye to eye on this (and I think on the above too, we're
not far off, neither is Bill). We're nearing consensus. Churn a bit on the
above and let me know what you think.

Peace out.

Cheers,
Chris

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


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


Mime
View raw message