> 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.
What problem exists today where the Board needs such a buffer? In what ways could this committee substitute its judgement for PMC of the TLP? How would one apply to be on this committee? Would this be a case of some members being more member than others? What would be the process and expectations for resolving disagreements between the TLP and this committee? 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)