Hey Bill,
On Feb 2, 2012, at 10:33 AM, William A. Rowe Jr. wrote:
> On 2/2/2012 12:27 PM, Mattmann, Chris A (388J) wrote:
>>
>> I guess the key difference between this small (but important) part of
>> our interpretation of this Incubator fix resolution that we're discussing
>> is the following:
>>
>> You (and maybe Greg?) feel that you need 1 VP guy (and perhaps
>> a committee/or not) to help out these projects-from-day-1-new-projects
>> that will be coming into the ASF, and that you need information flow up
>> from that guy and responsibility/culpability from that guy to the board,
>> and on down from it.
>
> Nope, that VP would not be a flow-through. Not even visible when things
> are working optimally;
OK. If that VP isn't a flow-through and isn't visible when things are working
optimally, then why have him/her?
You might say: For when things go wrong.
I'll say:
- in the case that things go wrong, it's up to the committee to:
- fix itself (elect a new chair, fork and tell us where to stick it;
decide to
attic themselves, etc.)
- if it can't fix itself, it's the board's problem and they will fix it
(with their
bazooka and tank).
- part of that committee includes N>=3 ASF members (at least). If they can't
fix it,
and if they can't figure out how to elect a new chair, what is it a committee
for
anyways? Send it to the Attic; tell them to take a walk; whatever.
This isn't divide and conquer. The responsibility *is* there. It's with the
incoming Project's VP who like any other VP will be the eyes and ears
of the board until replaced, death, resignation or whatever that long list
on the resolutions consists of; I forget right now.
>
>> I, on the other hand, feel that the N(=3?) ASF members that have to be
>> part of the new project's PMC from day 1, and that that new project's
>> VP (from day 1), are sufficient to provide that information flow up, and
>> responsibility/culpability. And guidance. And pointers to ASF resources
>> like ComDev (which will hold the Incubator docs), like Legal, like etc.
>> Just like the way it works today on our projects.
>
> Exactly. When those N(>=3) mentors don't have it together, this VP can
> step in to facilitate.
If those N>=3 don't have it together, then the committee will realize it, just
like any other committee. Or it won't realize it and the board will when
the reports start to suck or have red flags in them. This is no different
than a TLP today.
> Those mentors have to follow this VP's documented
> process flow established to expedite things for the board's benefit. When
> (not if) the process changes and evolves, it's on this VP to make the
> necessary modifications.
Agreed with everything above; it's just not owned by this VP. It's the process
flow of the foundation; owned by its members, operated by its board of
directors and shared by its community.
>
> But that VP won't be a gating factor if the mentors are experienced with
> the process. Responsibility for incubating projects is /not/ on the VP.
>
+1 to that should this VP be created which would definitely be against my
will :) I hold out hope I can convince us of adding another officer position
instead of trying this without one like it was pre 2002.
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.mattm...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
