incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Vote on personal matters: majority vote vs consensus
Date Thu, 28 Mar 2013 23:30:56 GMT
Chris,

Your position is that the IPMC fails to supervise. The consensus of the
IPMC is that this is not true. Otherwise, someone would be reading the
monthly report and objecting to the failure to report 'failure' to the
board. If you want to change minds about this, you might need to come up
with some concrete evidence of actual failure: bad commits, bad doings on
mailing lists, etc.

What the IPMC now does is use the shepherd process to compensate for mentor
weakness. It's not perfect. Under your plan, instead, the board would have
to cope, directly, with 'starter' projects suffering from inevitable
attrition -- or the Foundation would need to start many less projects, as
only those who could attract very strongly committed foundation members
could start.

Strangely, I find myself thinking that the logical endpoint of your line of
thought is to use the existing projects as incubators for new ones. A
healthy TLP could, I think, easily ride herd on a small group of people
starting something new in a related technology area, and then calve them
off.  I write this mostly to make the point that there are many possible
places to take the conversation if you start from the premise that no
variation on the existing scheme is workable. I personally don't know how,
organizationally, to reach that conclusion, especially insofar as the
recent disfunction is not about supervision, it's _merely_ about sorting
out who can be a member and thus a mentor.




On Thu, Mar 28, 2013 at 6:38 PM, Dave Fisher <dave2wave@comcast.net> wrote:

>
> On Mar 28, 2013, at 9:19 AM, Mattmann, Chris A (388J) wrote:
>
> > Hey Ross,
> >
> >
> >>>> I disagree. Chris' proposal removes the IPMC thus making the board
> >> legally
> >>>> responsible for everything that committee does today. Yes it replaces
> >>> it
> >>>> with an oversight body, but how does that scale?
> >>>
> >>> Please let me respectfully disagree with your interpretation of my
> >>> Incubator
> >>> deconstruction proposal [1]. In fact, it does not make the board
> legally
> >>> responsible
> >>> in any different way than the board is currently responsible for its
> >>> plethora of
> >>> TLPs -- IOW, it doesn't change a thing. It basically suggests that
> >>> incoming projects
> >>> can simply fast track to (t)LPs from the get go, so long as they have
> >>>> = 3
> >>> ASF members
> >>> present to help execute and manage the Incubator "process" which still
> >>> exists in
> >>> my proposed deconstruction.
> >>
> >> My point is that all the oversight currently provided by the IPMC would
> >> have to be provided by the board. We already know that having three
> >> mentors
> >> does not guarantee adequate support for podlings.
> >
> > I guess I would ask "what oversight"? There is no global IPMC oversight.
> > Ever since Joe's experiment, and even before, the podlings that get
> through
> > the Incubator (and I've taken quite a few now, and recently, so I think I
> > can speak from a position of experience here within the last few years),
> > are the ones that have active mentors and *distributed*, not
> *centralized*
> > oversight.
> >
> > IOW, I'm not seeing any IPMC oversight at the moment. I'm seeing good
> > mentors,
> > located in each podling, distributed, that get podlings through. Those
> that
> > stall well they need help. Usually the help is debated endlessly, and not
> > solved,
> > or simply solved with more active/better mentors.
>
> My experience as a shepherd shows that you can in fact recognize podling
> issues and eventually get them to the point where graduation of one kind or
> another happens. Two examples:
>
> EasyAnt graduating to Apache Ant.
>
> Etch finally graduated with a small, but sufficient PMC.
>
> > So, that's my whole point. You either agree with me that there is no IPMC
> > oversight at the moment (for years now), and that really podlings are
> TLPs
> > (well the ones that graduate within a fixed set of time as Sam was trying
> > to measure
> > before, or simply point out that is) or you still believe that there is
> > oversight
> > within the IPMC.
>
> I don't think it is an either / or. The current amount of oversight for
> any podling is a function of mentors, current IPMC dynamics, and real life
> influences.
>
> The shepherds serve a purpose as more of a divining rod into that dynamic,
> many solutions are possible, and the podling needs to be pushed into making
> choices.
>
> Regards,
> Dave
>
> > I personally don't. That's why I wrote the proposal. And
> > I think
> > that's at least evident to me and more than a few others that that's the
> > problem here
> > and that's why I don't think the Incubator should exist anymore in its
> > current form
> > and should be deconstructed :)
> >
> > Thanks for your comments and conversation and for listening.
> >
> > 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message