incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Gardler (MS OPEN TECH)" <Ross.Gard...@microsoft.com>
Subject RE: Incubator report sign-off
Date Mon, 05 Jan 2015 23:46:06 GMT
Note from the board - from an IPMC member (and yes, my opinions don't change if I put my Director
hat on but don't assume that I speak for all board members)

Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

-----Original Message-----
From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of Roman Shaposhnik
Sent: Monday, January 5, 2015 3:39 PM
To: general@incubator.apache.org; Benson Margulies
Subject: Re: Incubator report sign-off

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

Mime
View raw message