The nice thing about Hen's solution is, that I expect it to be better structured. When 20 people begin voting on 30 different components it will get confusing in that thread. Having one single file which contains the result of the vote would be very easy.
How do you want to reach non commons committers? By announcing on community@? Or were you talking about those who lurk around on the ML anyway :-) Benedikt 2013/10/14 Phil Steitz <phil.ste...@gmail.com> > On 10/14/13 2:04 AM, Henri Yandell wrote: > > Wearing my old Attic fart hat - something is dead when there is no one > left > > to turn the light out. Something is inactive when it couldn't pass a vote > > to keep the project alive (ie: 3 +1s). > > > > So that's one way to do this. Make a file in SVN. Put each component in > it > > (include the sandbox perhaps). Ask everyone to vote by putting their name > > next to a component. > > > > Any component failing to get 3 names is a goner [aka up for debate, but > the > > point of the debate is to convince others to add their name to the > > component]. Any component with zero names is a goner, kaput, deceased. > > Sounds good to me, with some slight changes. I think non-committers > - especially ASF committers who are not commons committers - should > be able to vote (with meaning as described below). I was about to > propose something similar to get the initial pruning done, and then > an ongoing process like: > > 0) Anyone can present a "dormancy challenge" at any time for a > component that they think might be dormant. Just start a thread > with subject [DORMANT][FOO] (content optional). > 1) We allow a nice long time for people to chime in - say two > weeks. If an ASF committer volunteers to RM a (future) release, or > if at least 2 people signal intent to do material work on [FOO], the > challenge fails and [FOO] remains active; otherwise it is lazily > deemed dormant. > 2) Reviving a dormant component requires nothing more than the > action awaited in 1). Dormant components stay put in svn, but their > websites and the main commons site designate them as dormant. > > So basically, you are presenting a challenge for "all" components to > start. I am +1 for that. The key question is what exactly does it > mean to vote +1 for a component. It can't mean "we should keep it > alive." To be meaningful, it has to mean "I am going to work on > it." I would rather be more hard core on what +1 means and tolerant > of only 2 +1s, especially if one of them is stepping up to RM. > > Phil > > Hen On Wed, Oct 9, 2013 at 12:17 PM, Benedikt Ritter > <brit...@apache.org> wrote: > >> Hi, > >> > >> I think Phil came up with the idea to try to focus on the components > that > >> we are able to maintain and put all other stuff to dormant. Here is the > >> list of components that I think really are proper: > >> > >> - CLI > >> - Codec > >> - Collections > >> - Compress > >> - Configuration > >> - CSV > >> - Daemon > >> - DBCP (?) > >> - Email > >> - Functor > >> - Imaging (?) > >> - IO > >> - JCI > >> - Lang > >> - Logging > >> - Math > >> - Net > >> - Pool (?) > >> - Proxy > >> - SCXML (after recent interest) > >> - VFS > >> - Weaver > >> > >> All other stuff can go dormant because there is currently nobody who > >> maintains it. Still a pretty long list. Thoughts? Anything missing? > >> > >> Benedikt > >> > >> -- > >> http://people.apache.org/~britter/ > >> http://www.systemoutprintln.de/ > >> http://twitter.com/BenediktRitter > >> http://github.com/britter > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter > <dev-h...@commons.apache.org> >
