incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: Vote on personal matters: majority vote vs consensus
Date Fri, 29 Mar 2013 00:56:00 GMT
On Thu, Mar 28, 2013 at 4:30 PM, Benson Margulies <bimargulies@gmail.com> wrote:
> 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 your statement were true, then someone would make the assertions
you're making."

> 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.

Is this a question of standing, where material harm needs to be demonstrated?

The IPMC is needlessly inefficient and abusive of its podlings. Novel
"compliance" mechanisms are literally invented and argued about on
general@ during podlings' release votes.[1] The cultural clashes that
Chris's proposal refers to generate huge amounts of traffic on
general@ and private@, as ASF members argue the semantics of core
concepts. And it's not just edge-case legal issues; some are as basic
as the definition of "veto".

These discussions create needless confusion and deeply resented churn
for podlings. The asymmetry in power teaches submissiveness to ASF
members, rather than independence and self-sufficiency. There are, in
truth, *many* active interpretations of the Apache Way practiced
across the ASF. Reconciling them is not the mission of the incubator.
Putting esoteric debates on the critical path of new projects is
absurd and harmful.

[1] http://s.apache.org/lFI

> 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.

The incubator doesn't deal with this effectively, either. To take one
example, Chukwa's "retirement" was a fiasco.

> 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.

The recent discussion is about the mentor role. The ongoing
dysfunction is about supervision, and the IPMC failing to discharge
its purpose efficiently. It exists to put its podlings through a
curriculum that transfers some cultural norms, makes podlings aware of
resources, and establishes clean licensing. Even if it succeeds well
enough not to be disbanded by the board, its inefficiency is worth
correcting. -C

> 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
>>
>>

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


Mime
View raw message