incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ross Gardler (MS OPEN TECH)" <>
Subject RE: Incubator report sign-off
Date Tue, 06 Jan 2015 00:33:52 GMT
Thanks Roman, this looks like a really good step forward.

With these modifications this proposal is very similar to my original proposal to have a subset
of the PMC act like the board and have all the authority of the board when dealing with podlings/pTLP
or any other incubation vehicle we might want to try. I think I first made it about three
years ago and have repeated it numerous times over the years, including recently in these
thread. The first time I proposed this it got watered down into the shepherds role (which
certainly helped but is not complete).

I've talked to Sam about leveraging the tools we use for the board here in the IPMC. He says
it would require a little work on both the tools and the processes but he is game for it.
He's ready to discuss onlist if this is something that people want to explore, as am I.

It also occurs to me that this same committee could perform the periodic reviews Rich is proposing,
using the same tooling.

Any other of the many proposals can also work within this construct. Nothing here should be
seen as mutually exclusive. All I'm trying to do is ensure that some group of people take

A bit of a rant follows feel free to stop reading now, I leave it for those who want to see
into my reasoning ...

Let's think about the work a Director should do when reviewing a report. It’s not reading
the report and then ticking a box. It's reading a report, comparing it to previous reports.
Taking a quick look at the tone of emails on the dev list. Looking at commit activity. Checking
the private list is not too active  and more. We have some great tools (thanks Sam) for helping
with this process, but it's still time consuming. We also have the concept of Shepherds. Those
shepherds are expected to fully review a projects report and status. They will typically spend
10 minutes more than other directors and will be able to answer any questions that come up
in the meeting from other directors.

To really review a project properly takes a good 10 mins for non-shepherds and 20-30 minutes
for shepherds (at least that is how long *I* spend on each report, I think most, if not all,
directors would say the same). This is the case if there is no difficulties. If there are
difficulties you can be talking about hours. 

Even with no problems this is around half a day *extra* work for each *volunteer* board member
to review the podling/pTLP/whetever reports properly. I don't know about other Directors but
I can't afford another half day of distractions from my day job - my employer is already being
very generous with my time for the ASF.

As an example of how long it takes to decide whether or not action is taken let me give you
two concrete examples. Last night I spent just over four hours reviewing the archives of a
TLP to see if a potential problem was actually a problem. I've spent maybe another 2 hours
in email threads on the topic. For another project a different director has spent what I would
estimate to be at least three hours reviewing and addressing an issue while I've spent maybe
an hour tracking those threads to see if I need to  help out. That's just in the last week,
just the items I'm aware of and it doesn't address other things the directors do on a weekly

If, however, we run the IPMC like the board with formal review meetings with identified responsible
people (Bensons committee if you prefer that over my earlier proposals) then things start
to look more manageable because the responsibility remains delegated across a larger team
of people who are accountable. It gives a group of individuals the authority to act if and
when they need to, just as the board does for TLPs. It need not be surgical (that's what mentors
are for), but it does need to act. It also gives that group the recognition that they deserve
do doing a job well.

This is very similar to Bensons proposal with your modifications below. It just removes the
need for the board to take on additional responsibility which, in my opinion, it doesn't have
the time for even if one or two directors do (those directors can volunteer that time to the
IPMC either as part of the core committee, to count ticks in boxes, to properly review podling
status or to conduct parallel pTLP experiments or whetever).

Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation

-----Original Message-----
From: [] On Behalf Of Roman Shaposhnik
Sent: Monday, January 5, 2015 3:39 PM
To:; 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) <>
> 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:
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
    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.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:
View raw message