Christmas clean-up ;-)

[kybos]

Merry Christmas to you all, guys!

And a suggestion to bring some order into the issue tickets that are piling up infinitely and nobody will ever go through them again...

I've discovered a standard github service ("action") I was always looking for:

https://github.com/actions/stale

It checks for stale issues periodically, tags them and sets an info message (so the persons involved get notified) and if there is no reaction for another period of time, they are closed automatically.
Sounds very sensible, it's even possible to exclude issues with specific tags etc.

The default is 60 days old and 7 days time for reaction, which is too strict for our purpose I think. I would set it to 180 days and give 14 days time for reaction.

Is it ok with you to schedule the action as proposed?

[spamatica]

Merry Christmas! What better christmas eve than a bit of muse talk :D
Yeah, we do not handle the ticket list as good as we could...

It seems a very good solution to get the bug list manageable in size. But I'm also a little bit torn that people will feel turned away or that we will lose some good ideas.
But then again, if the list is always too big (good work closing many many tickets the last many months btw!) it will still be way too hard for us to reap the benefits of the bug list.
Besides it seems to me the track record for acting on new tickets is pretty good now.

I probably could look it up but I'm asking anyway. Can we set up several rules? Like a 30-60 day timeout where we in the devteam are just reminded but no closing occurs? And then a 180 day reminder to reporter and others involved which left unresponded will lead to termination.

[kybos]

I probably could look it up but I'm asking anyway. Can we set up several rules? Like a 30-60 day timeout where we in the devteam are just reminded but no closing occurs? And then a 180 day reminder to reporter and others involved which left unresponded will lead to termination.

I don't think it works that way. The notifications are not sent by the service itself (this is github standard, sent to all involved persons), it only adds a comment and/or tag.
You are right that it's not nice for the user when his message would just be closed, especially when there was no comment/discussion on it at all - but in this case it's not just closed, it's tagged as stale and comment entered that it should be updated if the issue is still relevant, then the user (and all involved) will get notified and have 2 weeks time to react (we can make it 4 weeks or 2 months, whatever).
Of course also the time after which untouched tickets are marked as stale can be longer, e.g. one year would be ok too.

There is also the possibility to define a tag (e.g. do_not_close) which excludes the issues from processing, but I think this would lead to everybody setting this tag and the situation would be the same as before ;-).

Sure the solution is not optimal, as there are so many different kinds of issues and handling of them, but IMO it's better than the current state, where there are many open issues more than 5 years old etc. And let's be realistic, nobody from the devs will probably ever look back at issues that are no longer on the first page...

BTW: The text search works also for closed issues, so they are not "lost".

[terminator356]

Merrrrrry Christmas fellow MusEers.

Gosh, I have difficulty enough keeping up these days.
I try to tackle what is most recently reported. Either I succeed, or it ends up
being waaay too complicated and I have to put it aside for another day.
For example the midi clock output, the looping and so on. Things that I tried very hard to work on
but are still in active development in branches here.
Much older tickets I don't think I have time to investigate.

So these proposals seem fine to me, I guess as long as they are not closed and forgotten forever.

[spamatica]

Well, they will be closed (after asking for action that is) so they won't be directly visible.
But on reflection I think this is as good as we can get it so I support the addition.

If we are to examine an issue that were left dangling I think it might be one of:

1. very old, the issuer has probably moved on.
   If there is someone actually waiting on the other end, they can let us know with the response mail.
2. it's not described very well so no one picks up the ball.
   Same here, let the issuer respond.
3. It's a feature request that might be hard to implement or otherwise does not inspire anyone to action.
   Same here.

When the bugs clearly have merit I don't think we (well...seldom me) haven't been that bad at acting on them.

[kybos]

I created the service and started the initial run manually. No periodic run yet and no deletion, in case the reactions become too negative...