> 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 <ro...@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.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 > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
