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 responsibility. 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 basis. 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: shaposh...@gmail.com [mailto:shaposh...@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.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 --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
