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