commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [VOTE] Revised dormancy policy
Date Tue, 17 May 2011 15:58:51 GMT
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.


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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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


Mime
View raw message