----- "Phil Steitz" <phil.ste...@gmail.com> a écrit : > On 5/16/11 4:21 PM, sebb wrote: > > On 17 May 2011 00:07, Gary Gregory <garydgreg...@gmail.com> wrote: > >> On Mon, May 16, 2011 at 5:57 PM, Paul Libbrecht <p...@hoplahup.net> > wrote: > >> > >>> So we should relaunch a vote? > >>> (or... I should vote a no and relaunch?) > >>> > >>> paul > >>> > >>> > >>> Le 16 mai 2011 à 23:44, Phil Steitz a écrit : > >>> > >>>>>> d) svn remains open (but no commits without revival vote) > >>>>> It seems slightly too harsh to me. > >>>>> Since jelly is among the heaviest targeted ones here, I think > the whole > >>> dormancy aspect would fit but preventing commits sounds like the > best way to > >>> "cap off any attempt of revival". > >>>>> Couldn't we say > >>>>> > >>>> Good point. I would be OK with that change. > > +1 to allowing SVN changes. > > > >>>> Phil > >>>>>> d) svn remains open (but no release without revival vote) > >> Dormant status feels like a death sentence of sorts or at least > another > >> barrier to entry. > >> > >> If a committer wants to fiddle with POMs for example across all of > commons, > >> he or she should be able to do so. Even a casual change like fixing > typos > >> would not be allowed. > >> > >> I wonder if the opposite would not be more interesting: showing > which > >> projects are Active. > >> > >> The whole dormant/active deliberation could be remedied with a page > ranking > >> project activity by commit + ML activity + last release date for > example. > >> > >> The audience can decide what is active based on this table: Project > Name, > >> Commits Last Week/Month/Year | ML msg count week/month/year | Last > Release > >> and Date > > Mature and stable components will tend to have low activity, but > > should not be marked dormant. > > > > It would be useful to know which projects have outstanding bugs > that > > are not being addressed - that seems more likely to indicate > dormancy. > > > > I agree with your points, but I am very hesitant to get into the > maintaining metrics game, partly because maintaining them requires > work but more because I don't really believe they can tell us what > we need to know to make these decisions. Some active components, > for some periods, have big backlogs and relatively slow response. > Some bugs get "attention" but no resolution for a long time. And as > you said, some stable, but still active components have few issues > and commits during some periods. > > What I wanted to capture in "dormancy" was community consensus that > nothing was - currently - going on with the component. The best way > to determine that is to ask the question, "is anyone planning to do > any work on this any time soon?" Voting -1 on a dormancy vote as I > have described it effectively means "yes" or at least "maybe." I > bet we can relatively quickly get to consensus on some really > "dormant" stuff (e.g. [attributes]) and any that are in any way > debatable, (e.g. [jelly]), we leave as active and revisit now and > then if there are no signs of life. My idea here was to make this a > "small reversible step" for us as a community, not a radical change > and not something that will create a lot of work or noise.
I agree with the proposal including the change to svn commits, and I agree with Phil's view in the paragraph above. Luc > > Phil > > > --------------------------------------------------------------------- > > 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
