I have only one point of discomfort with Ross' writing here. Ross's position, in this and other messages, seems to me to be that it a podling can persist indefinitely, so long as (a) it has involved mentors, and (b) there's no ongoing violation of Foundation policy.
I have two reasons to wonder about this. 1: My recollection of the original set of messages from the Board by way of Sam were that indefinite residence in the incubator was a problem, even well properly supervised. 2: While I appreciate that mentors are not entirely fungible, I tend to think in terms of a limited pool of volunteer effort, so indefinite incubation worries me. Neither of these are a reason to change the short-term outcome of Chuckwa, one way or the other. I'm thinking of starting a Wiki page on the Incubator's mission and scope that might result in a clarification of (1). As for (2), Ross' formulation in this message, and in others, is to help the community to find consensus by offering a constructive logical view. It's always better to do that than to reach, or worry about, an impasse. On Wed, Nov 28, 2012 at 8:35 AM, Benson Margulies <bimargul...@gmail.com> wrote: > On Wed, Nov 28, 2012 at 8:32 AM, Benson Margulies <bimargul...@gmail.com> > wrote: >> The current vote thread for retirement of Chukwa, coupled with some of >> the other discussion threads, raises some questions that need to be >> resolved. >> >> How do we make retirement decisions? >> >> http://incubator.apache.org/guides/retirement.html says: >> >> "Before following the retirement steps, the remaining developers of >> the project should be informed and vote should happen on the projects >> dev list. After the vote, the IPMC must vote on the general list to >> retire the project. >> >> In some cases the developers of a project might be opposed to >> retirement, while the IPMC is in favour because its members cannot see >> a succesfull graduation now or in future. In this case the IPMC >> _decides_ about the retirement." >> >> In general, Apache projects strive to reach decisions by consensus, >> using votes to memorialize consensus. >> >> In the Chukwa case, there seems to have been a consensus some months >> ago about how things would proceed. However, I don't think it's >> reasonable to view that decision as a self-operating process in which >> the community pre-decided exactly how and when the plug would be >> pulled. Actually deciding to retire the project, over the objections >> of even one of its contributors, is a decision point that the >> community has to cope with -- however frustrating this may be for >> mentors. >> >> So, in hindsight, it would have been good to have a [DISCUSS] thread >> in which the mentors could present their view, Eric could argue back, >> and other people could pose questions of clarification. If people >> really want to compare to Wink, someone could do the necessary >> slogging to bring forth real comparative data for Wink. >> >> But let's imagine that we have a DISCUSS thread and a clear lack of >> consensus. In essence, that's what the current [VOTE] thread amounts >> to. Now what? Do we say, 'well, in the absence of consensus, we must >> continue the podling'? Do we say this even in the absence of enough >> mentors willing to supervise it? >> >> I stupidly posted an initial version of this question to private@, and >> Ross replied with some very clear thinking on this, which I trust that >> he will re-send to this thread. I'll stop here and wait for that. >> >> --benson > > Here are Ross' remarks: > > In my opinion retirement should not be a decision made by a VOTE of the IPMC. > > Firstly, the ASF is not governed by votes, it is governed by > consensus. Secondly, in votes people often pile on without doing the > appropriate background work (a +/-1 is easier than discussing the > various options to reach consensus). > > Votes in the ASF are usually used to confirm consensus that has > already been achieved through discussion. So, in addition to > supporting your suggestion to have a [DISCUSS] thread before a [VOTE] > thread I suggest we follow the following guidelines with respect to > podling retirement: > > 1) If the PPMC unanimously recommends retirement, it gets retired. No > need for a VOTE, just notify the IPMC, leave for 72 hours minimum and > retire it. > > 2) If the mentors say it should be retired but the PPMC does not > unanimously agree then the podling should seek to recruit new mentors. > No need to VOTE, just get on with it. > > 3) If there insufficient mentors willing to continue working with the > project then the IPMC has a problem to address on a case by case > basis. The shepherd role ensures that these cases are spotted during > the reporting process. If necessary a [DISCUSS} thread can be started > and a sensible plan is developed (which may include a VOTE to retire, > at this point there should be no -1's as a -1 needs to be backed by a > willingness to act and thus this should have been surfaced in case 2) > above. > > Note, this is exactly what happens with board oversight of TLPs, the > language and role titles change but in general the board merely > implement the wishes of the community. The only time the board makes > an actual decision is when the community is breaking down for some > reason. This is done on a case by case basis after spending time > trying to understand the situation (case 3) above) > > Ross --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
