incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Incubator report sign-off
Date Tue, 06 Jan 2015 01:41:12 GMT
> An addition of the overseeing committee, will shield the board from
​> ​
*some* of the day-to-day business of telling the pTLP that something
​> ​
needs to be fixed.

Is this pretty close to IPMC in another name?

Who gets to be on the new overseeing committee? Not current IPMC membership
right? So is that a revocation of privilege in some respects?


On Mon, Jan 5, 2015 at 3:38 PM, Roman Shaposhnik <roman@shaposhnik.org>
wrote:

> I am clearly hitting my rate-limit with emails to general@, still since
> Ross' reply was one of the few pieces of feedback from the board,
> I'll do this one and then wait for others to chime in (Benson?).
>
> On Mon, Jan 5, 2015 at 2:27 PM, Ross Gardler (MS OPEN TECH)
> <Ross.Gardler@microsoft.com> wrote:
> > This proposal is not necessarily flawed, but it is incomplete.
>
> Couldn't agree more. But! The whole point is to try our best
> to get this:
>     https://wiki.apache.org/incubator/IncubatorV2
> to completion. Your direct feedback (as a sort of proxy for the
> board) is *very* much appreciated.
>
> > As I've said repeatedly. This simply moves the problem it does
> > not solve it. Today, a project has mentors, usually it works,
> > but sometimes it doesn't. When it doesn't work someone needs
> > to fix it. That is the work that is being moved from the IPMC to
> > the board by the pTLP proposal.
>
> Benson, perhaps we need to create an FAQ around failure scenarios
> on your wiki page. Here's what I would say to address the failure
> scenario described by Ross.
>
> An addition of the overseeing committee, will shield the board from
> *some* of the day-to-day business of telling the pTLP that something
> needs to be fixed. So lets, break the cases down:
>    1. pTLP is *really* doing fine, which means:
>         1.1. overseeing committee has nothing to address
>         1.2. board *still* has to review the reports (as it does today)
>                and agrees with the overseeing committee
>    END RESULT: no additional work for the board
>
>    2. pTLP is NOT doing fine, but it doesn't gets flagged by the committee:
>         2.1. board expresses its concerns *directly* to the pTLP PMC
>            while CCing the committee essentially pointing out something
> that
>            fell through the cracks when it should NOT have. NOTE: a huge
>            difference here is that board does NOT expect a committee to
>            fix the issue, but rather makes it aware of something that
> should've
>            been flagged by it. Only pTLP PMC can act to remedy the issue,
>            nobody else can help them (they could, of course, request help,
>            but again -- it has to come from them
>         2.2. pTLP PMC either fixes the issue. The comittee and the board
> are
>            happy again
>         2.3. pTLP PMC doesn't fix the issue ==> GOTO #3 (we are expecting
>            the level of maturity and dedication from the committee members
> so
>            that GOTO #2 becomes impossible since the board explicitly
> flagged
>            this issue in 2.1)
>    END RESULT: no additional work for the board
>
>    3. pTLP is NOT doing fine and it gets flagged by the committee, which
> means:
>         3.1. since committee is treated as an extension of the board,
> its authority
>             and the gravity of its opinion have exactly the same
> consequences if
>             the board flagged it (we may need to come up with
> additional steps for
>             the board to vet the committee's opinion, though)
>         3.2. the committee STILL is not responsible for fixing the
> problem, the PMC is.
>    END RESULT: no additional work for the board
>
> Essentially, the overseeing committee acts as an extension of
> the board, but the ultimate responsibility lies with pTLP PMCs.
> In that sense the overseeing committee inherits the good and
> the bad sides of the board. More specifically:
>     1. it becomes a jackhammer, not a scalpel
>     2. it is NOT expected to fix the problem, but rather unearth it
>     and delegate the solution to the PMC
>     3. if PMC doesn't act *really* grave consequences could follow
>     4. the level of maturity and the size of the committee needs to be
>     as close to the board's level as possible. That is the part that is
>     nicely addressed in Benson's wiki.
>
> Here's an elevator pitch: when it comes to running the foundation
> according to the 'Apache Way', the committee is a vice-board.
>
> One extra thing to note, that while we can *start* this comittee as
> dedicated
> to Incubating projects, it will be a very natural extension to get it
> involved
> in monitoring all of TLPs, not just pTLPs. In that sense, Rich's idea
> couldn't
> have been timelier.
>
> Honestly, I really feel we've collectively stumbled on something really
> promising here.
>
> > It's not necessarily a bad thing and may be acceptable to the board,
> > but I don't understand why proponents of this approach feel it is a
> > solution rather than a moving of the problem.
>
> Benson, another useful section on the wiki could be explicit listing
> of the benefits of the proposal. Here's what I see as benefits:
>    1. the new scheme avoids a very dangerous delusion that
>     IPMC somehow can 'fix' problems. In the new scheme that
>     is clearly not the case -- only PMC can fix problems (or perish!).
>     This is very much in-line with how TLPs are setup.
>
>     2. it avoids a very dangerous idea of IPMC having
>     a 'collective responsibility' for projects (and we all know if
>     everybody is responsible -- nobody really is). In the new scheme,
>     the only place responsible for success of the project is its PMC,
>     regardless of whether it is a PMC for pTLP or a TLP.
>
>     3. as a consequence of #2 board relationship with failing podlings
>     becomes very direct. In fact it becomes *exactly* the same as
>     the board relationship with failing TLPs: instead of delegating to
>     a nebulous entity (IPMC) the board delegates directly to PMC
>     and if PMC fails to act *really* grave consequences could follow
>
>     4. the new scheme (the committee part) has a very nice property
>     of not only being applicable to the Incubating projects, but naturally
>     extending to cover TLPs on the verge of failing and hopefully catching
>     it before its too late.
>
> > Furthermore, I've not even started on who would own the documentation
> aspect
> > (yes the proposal is ComDev but just as last time this was circulated
> nobody has
> > asked ComDev if they are willing to take it on and nobody has turned up
> in ComDev
> > to do the work.
>
> According to the new proposal it will be an overseeing committee.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

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