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.gard...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
