GHC has a process for systematically downgrading inactive tickets. See
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/BugTracker
under "Re-milestoning after a release". Something like that might be useful for Cabal?
Mind you, I'm not sure that we have executed this algorithm following the 7.10 release (Austin NB).
Simon
| -----Original Message-----
| From: cabal-devel [mailto:cabal-devel-bounces@haskell.org] On Behalf Of
| Kosyrev Serge
| Sent: 21 April 2015 19:38
| To: Thomas Tuegel
| Cc: cabal-devel
| Subject: Re: inactive issues
|
| Thomas Tuegel writes:
| > On Wed, Feb 25, 2015 at 1:53 PM, Thomas Tuegel
| wrote:
| >> On Wed, Feb 25, 2015 at 12:21 PM, lennart spitzner
| >> wrote:
| >>> I am not convinced. how does closing ~40 out of ~700 open tickets
| make
| >>> the contributors more effective? that demand exceeds resources is
| >>> true, but it is no argument for closing issues. many of the issues
| >>> represent sensible ideas for features that do not need new feedback.
| >
| > At the risk of beating a dead horse, I just wanted to point out an
| > exchange on Twitter [1] which _proves_ that having a large number of
| > open tickets discourages our users from opening new issues when they
| > encounter bugs, even severe performance regressions.
| >
| > I recommend, if you think there is any reason to believe an issue is
| > inactive, close it! We can always re-open issues if the re-occur.
|
| As a bystander and purely philosophically, the action of "closing" feels
| gratuitiously non-injective, since it conflates "inactivity" with
| "completion".
|
| Could it be that we could have a more discerning tracker, which would
| show the "not inactive" subset of "open" issues by default?
|
| Hardly so, with github, and yet..
|
| --
| regards,
| Косырев Серёга
| _______________________________________________
| cabal-devel mailing list
| cabal-devel@haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
