On May 17, 2011, at 11:59, Phil Steitz <phil.ste...@gmail.com> wrote:

> On 5/17/11 2:27 AM, Emmanuel Bourg wrote:
>> What is the goal of this policy? Is it meant to lure users away
>> from the component because it's obsolete or seriously broken? Is
>> it an attempt to get new developers interested in maintaining the
>> component? Or a mere indication that no support will be provided
>> for this component?
>
> Great questions.  I was thinking it was mostly the last, but really
> saying "there is no one currently working on this component, so if
> you want to propose enhancements or report issues with it, nothing
> is likely to happen immediately."  For potential contributors, it
> really means "some effort is going to be required to revive this thing."
>>
>> - If the component is obsolete, I think the web page should
>> explain why and maybe redirect to better alternatives.
>
> I would be careful making this judgment, but OK with it if there is
> consensus in the community.  What I want to be very careful with is
> categorical pronouncements to the effect that "this thing is dead
> forever"
>
>>
>> - If the component is abandoned but still useful, an "help wanted"
>> message could be inserted on the site.
>
> Well, that could apply to every component that we have, but I get
> your point.  Could be the "dormancy disclaimer" includes a call to
> action to get the component revived.
>>
>>
>> By reading your proposal it seems like a stable and widely used
>> component could fall into the dormant category if no one
>> volunteers to maintain it at a given time. Also the barrier to
>> revive a component should be as low as possible IMHO, a single
>> motivated committer should be allowed to do it.
>
> Great suggestion.  I am OK with changing "revival" to require only
> one ASF committer.

That sounds good to me too.

We'll need clear instructions to deactivate and reactivate.

Gary
>
>
> Phil
>>
>> Emmanuel Bourg
>>
>>
>>
>> Le 16/05/2011 19:52, Phil Steitz a écrit :
>>> I would like to take the proposal made in [1], modified per
>>> discussion on that thread to a VOTE, so we can start implementing
>>> the policy.
>>>
>>> The provisions are as follows:
>>>
>>> 0) To move a component to dormant requires a VOTE.   A single -1
>>> suffices to postpone the action; but a -1 in a dormancy vote is
>>> really a +1 to help sustain or advance the component. Dormancy VOTEs
>>> will remain open for two weeks.
>>>
>>> 1) When a component is voted "dormant":
>>>     a) the main web site and site navigation links show the
>>> component as dormant
>>>     b) the component site and component JIRA page display a
>>> "dormant
>>> disclaimer" (TBD)
>>>     c) JIRA remains open (not merged into Commons-Dormant, but JIRA
>>> project page displays disclaimer)
>>>     d) svn remains open (but no commits without revival vote)
>>>
>>> 2) To revive a component requires another VOTE resulting in 3 +1s
>>> from ASF committers interested in bringing the zombie back to life.
>>> Revival VOTEs are majority rule.
>>>
>>> votes, please.  This VOTE will remain open for at least 72 hours.
>>>
>>> Comments, as well as votes, are welcome from all community members.
>>> I will revise the policy and restart the VOTE if necessary.
>>>
>>> Thanks!
>>>
>>> Phil
>>>
>>> [1] http://markmail.org/message/bbnuxxozsnkapfhr
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to