On 28 November 2012 13:42, Benson Margulies <bimargul...@gmail.com> wrote:
> 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. > I agree indefinite incubation is a problem and my suggestion is not intended to allow it. The Incubator was always designed to scale in a self contained and managed way. If a project could muster sufficient mentors then it could enter incubation. If it can retain sufficient mentor interest it can remain. My mail simply restates this original design feature. I hope that when Sam expressed his concerns he didn't intend to say that there should be a time limit. I hope he meant there should be active efforts to graduate projects. I don't see that my view is in conflict with this. Perhaps the problem is that the IPMC has lost sight of the self-regulating model designed for it. I feel that we started to loose sight of the fact that the mentor role is one of support and guidance on how to get from "here" to graduation. We began to treat the mentor role as a rubber-stamping exercise. The shepherd role is a nice lightweight approach to catching when mentoring is not doing the job it should (helping chart the course from "here" to graduation). In the case of Chuckwa this model is working well. A mentor expressed an informed opinion, the community respond to that opinion. The IPMC demands a new plan to get from "here" to graduation and some new mentors step up. In x months time I expect those mentors to report successful progress towards graduation or I expect them to be recommending retirement from an informed position rather than an uniformed observer vote on the general@incubatorlist. I didn't vote this time around as I didn't have the time to review and couldn't see consensus in the community. Next time I will be better informed as a result of the recent discussion and will have the opinions of new mentors I trust to dig a little deeper in the coming months. I see this as validation of the existing process, not evidence that the process is broken and needs to change. Ross > > 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 > > -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
