I would think something along the lines of: if an issues has not been apparently worked or or clearly commented on in some number of release cycles (maybe 2 or 3), then the issue should be able to be closed.
> On Apr 23, 2016, at 6:26 AM, Gilles <gil...@harfang.homelinux.org> wrote: > > Hi. > > Browsing through the project's open issues is becoming a huge time sink. > Commons Math is crumbling under its own weight in this area too. > > Some of the old issues are feature requests that are unlikely to be > implemented in the near future. > Others contain discussions and/or patches not updated in years, and are > thus likely outdated wrt to the current line of development. Just > checking whether anything can be salvaged would anyways take a lot of > time which nobody is prepared to do, as anyone can see from the recent > activity in the project. > > Some reports should have been resolved/closed long ago but were not, > probably because of the sheer number of pages to look at. > > Lacking resources to manage this large number of issues, I think that > we have to set an expiry date on the JIRA reports (and close them upon > expiry), unless they pertain to confirmed bugs. If you want to throw a sequence of numbers my direction I can collate them into something more manageable. -Rob > > There could perhaps be a single open JIRA report with links to all > issues resolved as "Unresolved", just in case some future contributor > wants to revisit whatever had been raised in the past but could not be > completed. > > What do you think? > > Gilles > > > --------------------------------------------------------------------- > 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
