Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of bimargulies@gmail.com
 designates 209.85.223.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALhtWkeNWvV1EJsG2z8oPd0v=uCAAybw2gbgocZHCRT9kaO-1A@mail.gmail.com>
References: 
 <CALhtWkeNWvV1EJsG2z8oPd0v=uCAAybw2gbgocZHCRT9kaO-1A@mail.gmail.com>
Date: Wed, 28 Nov 2012 08:35:29 -0500
Message-ID: 
 <CALhtWkf6nCPPc9gLtAWHvH96Jbb1TW4=Gy=ZnA68Nhmqrsivww@mail.gmail.com>
Subject: Re: Retirement decision making
From: Benson Margulies <bimargulies@gmail.com>
To: "general@incubator.apache.org" <general@incubator.apache.org>
Content-Type: text/plain; charset=UTF-8

On Wed, Nov 28, 2012 at 8:32 AM, Benson Margulies <bimargulies@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org