[CI] Use bot to remove very old and obsolete issues

Hello,

In Nim's repos there are very old issues (2013) and certainly obsolete. Remove manualy old issues without actvity from a long time can give too much time and must made regurlaly.

So, use a bot maybe a good idea. I see this simple bot https://github.com/actions/stale but there are many other.

I agree, unfortunately we got a lot of pushback when we introduced this: https://github.com/nim-lang/Nim/issues/15159.

Old PRs are already automatically closed after a while, but I don't think that's a good idea for issues, especially since many of the old issues still seem to be valid (for many bugs, there just isn't much to talk about, that doesn't mean we should ignore them). If you find issues that are no longer valid, you can close them by submitting a PR with a test case.

It's not about whether issues are valid or not. It's about prioritisation, if people care about a certain issue then it can be bumped (this stimulates us to fix it too which is another plus) and if it doesn't get bumped then we should forget about it.

For the rare cases where it is clear that an issue is severe and must be fixed we can add a tag that will prevent getting closed by the stale bot.

In Nim's repos there are very old issues (2013) and certainly obsolete

Firstly OLD != OBSOLETE

It's not about whether issues are valid or not. It's about prioritisation

We already have multiple tags for specifying whether an issue is high priority or low priority or showstopper. And if you actually look at those bugs you will find that a lot of those high priority or showstopper bugs were fixed after years of opening and being tagged high priority. I don't see how closing down low priority issues unnecessarily is going to automatically fix high priority issues.

Also, Github (and other companies) provide several tools for managing projects/prioritisation etc. such as github boards. Maybe make proper use of them instead of unnecessarily closing down low priority issues.

if people care about a certain issue then it can be bumped

Yeah, so you are basically saying that i spend hours trying to produce a small reproduction of a bug, and you are going to close it because it does not have 50 likes? wtf? Why would i bother reporting any bugs if that is the case. People understand the concept of priority, they can understand if some low priority issue stays open for some time, but what kind of explanation is there for closing the issue unnecessarily.

if it doesn't get bumped then we should forget about it

What? Whatttt? Nim doesn't get much upvotes on hacker news. Lets all stop using it because low upvotes mean that it is useless as compared to the alternatives???

unfortunately we got a lot of pushback when we introduced this: nim-lang/Nim#15159.

If anybody feels that this is unfortunate, please give some valid points to discuss. Prioritization has got nothing to do with this, and the regular bumping of issues criteria is bs. Closing down issues automatically without any reason is rude to the person spending time on reporting the issues. Instead as mentioned in the previous discussions, maybe use tissue or some other tool (or create a manual test repo with code for all issues) to continuously check for validity of the issues and close them if they seem fixed. Or maybe just continue with how things are going on now.

In Nim's repos there are very old issues (2013) and certainly obsolete

Firstly OLD != OBSOLETE

It's why I add "certainly".

Also I should have specified that in issue I mean bug and not a feature.

So, I see that this problem was already discussed in the Nim repo and the result of the debate is that you don't want it. But...

I take several examples to explain my request. When it's a bug, you shouldn't close the issue unless it's no longer valid.

1 . I am DAveCodeur64 and I find a bug and I report it in the repo. Since I can't wait or it's too long, I bypass it. Several months and releases later I don't test if it is still valid and I forget about it.

In this example what do we do? Who is responsible for testing all the issues in this case? You need a code to reproduce it and it is not always the case. I don't know if there is a tool to automatically test the validity of the bug outcomes but it requires some thought.

Our friend @ghost (who doesn't exist anymore) requested a feature https://github.com/nim-lang/Nim/issues/2368 in 2015 and since then nothing.

This is not an isolated case, there is this one https://github.com/nim-lang/Nim/issues/4464 and https://github.com/nim-lang/Nim/issues/5194 for Visual Studio 2015. Ok, we don't close feature requests because it's not respectful but after 5 years what's the point? Yes, it's frustrating but after several years the contributor have either developed it or bypassed it. Worse, changed the language.

What? Whatttt? Nim doesn't get much upvotes on hacker news. Lets all stop using it because low upvotes mean that it is useless as compared to the alternatives ???

Let's be honest, everyone does it even unconsciously.

Also, Github (and other companies) provide several tools for managing projects/prioritisation etc. such as github boards. Maybe make proper use of them instead of unnecessarily closing down low priority issues.

I totally agree with this and I've said it before. Araq has started to use this feature in GitHub but it can go much further. Accepted RFC's should be further organized into tasks in milestones to improve development tracking. Also the contributeur can see that his issue is in the next milestones. A simple kamban like in Trello does the job very well. After that it takes time to organize but that will be more than compensated.

To get back to the topic, set up a bot that after 6 months but an stale outcome with the following message.

"This issue has been automatically marked as expired because it has not seen any activity in 6 months. This is not due to a lack of interest but to a lack of priority or time. If you think it is still a valid issue, write a comment below; otherwise it will be closed in 6 months. This will hopefully give you time to respond. You can also ask your question on the forum or by chat -> https://nim-lang.org/community.html so that the contributors can solve your issue. You can also make a contribution in the code with a PR. The following link shows you the procedure -> https://nim-lang.github.io/Nim/contributing.html. Thank you for your contributions and your understanding."

I think the message is respectful enough not to offend the contributor.

Whatever you do, when there are too many issues > 2500, as I hope, Nim becomes more popular, you'll be forced to put this up to save time and readability.

I am DAveCodeur64 and I find a bug and I report it in the repo. Since I can't wait or it's too long, I bypass it. Several months and releases later I don't test if it is still valid and I forget about it. In this example what do we do? Who is responsible for testing all the issues in this case? You need a code to reproduce it and it is not always the case.

In this case the problem is not that you have forgotten about the issue, but that you have not provided a minimum example which others can reproduce the issue. If there is a minimum reproduction available there is absolutely no need for you to be available later to bump up the issues. If any core developer or contributor looks at the issue, he copies the minimum code sample to his pc, compiles it, and gets to know whether it is still an issue or not. It takes <1 min to do this.

Our friend @ghost (who doesn't exist anymore) requested a feature Ensuring that symbols defined in an importing module are referenced Nim#2368 in 2015 and since then nothing.

Same as above. Issues should be triaged as soon as they are opened. And any and every piece of information should be taken at that point. It does not matter whether that person is available 1 year later.

This issue has been automatically marked as expired because it has not seen any activity in 6 months. This is not due to a lack of interest but to a lack of priority or time. If you think it is still a valid issue, write a comment below; otherwise it will be closed in 6 months. This will hopefully give you time to respond.

As i said previously even high priority / showstopper bugs remain opened for quite a long time. That does not mean that they can just be closed or are not important anymore. Lets take an example - I opened a high priority bug. The core team recognises it as such. There is plenty of discussions when the issue was opened. Workarounds were available but are really ugly so the issue remains high priority. There is nothing else to discuss as the issue has been properly triaged. I go along on my merry way. Now 6 months/ 1 year later, i may or may not be available. I might be down on some vacation. I might be fighting fires at my day job. Whatever. Does not mean the issue becomes any less priority. The point is that I was unable to bump up the issue on time, the core team / contributors missed out on that too and now the issue is closed. I come back a few weeks later, check my notification, find out my issue is closed, i am happy that i can finally remove the ugly workaround in my code, but when i open my issue, i see that it was not closed because it was fixed but it was closed because i did not bump it in time. What? Everything was discussed properly, the issue was acknowleged by the core team, but it was closed because i did not unnecessarily spam all the watchers in the issue? That does not make any sense. Plus, now what should i do? I ping the core team members saying that the issue is still present, but they are busy with other tasks, so what now? Should i keep pinging them every 2 days? Should I open another issue now? If i open another issue, all the discussion from the previous issue is lost for absolutely no reason. I can add a link to the previous issue, but what is people miss it and keep asking questions that already had the answers previously. What if the people watching the previous issue were also affected by the issue and were using the same ugly workaround, and after a few weeks they come online and find that the issue has been closed without being fixed? what now? Should they keep searching the issues till they find that i reopened another issue. Should they keep pinging people till they find out what happened? ...

In other words, I can imagine lots and lots of scenarios where closing issues unnecessarily will cause problems but i cannot see any scenario where it would help anybody at all...

IMO, the best time to triage issues is when they are opened. Many repos add a tag such as Needs-Author-Feedback. Simply if an issue is opened that does not have enough details for contributors / core team to act upon it, ask the person to provide the required details, and tag the issue with Needs-Author-Feedback. If no comment is received by the person within say 2 weeks, automatically close the issue. If comment is received, remove the tag, and check the details provided and carry on. Then assign priority, add to board or milestones or however you want to manage the project. If a comment is received after the issue is closed, well the issue can be manually reopened by the core team, and if they miss out on that, the person can create another issue, this time with proper details, no important discussions or anything is missed. And obviously if all the required information is already provided then it makes no sense to close the issue, not then, not 10 years later if the issue is not fixed.

Also, even if the core team does not have bandwidth to keep checking all 1000s of opened issues, contributors have in the past, and will in the future keep checking the issues and adding test cases for fixed issues. So this is not really a problem. Closing issues unnecessarily is well, unnecessary...

Also I should have specified that in issue I mean bug and not a feature.

We all do, most issues are bug reports.

I take several examples to explain my request. When it's a bug, you shouldn't close the issue unless it's no longer valid.

That's the opposite of what you were originally proposing, namely to just automatically close old issues.

1 . I am DAveCodeur64 and I find a bug and I report it in the repo. Since I can't wait or it's too long, I bypass it. Several months and releases later I don't test if it is still valid and I forget about it.

In this example what do we do? Who is responsible for testing all the issues in this case? You need a code to reproduce it and it is not always the case. I don't know if there is a tool to automatically test the validity of the bug outcomes but it requires some thought.

Just closing a potentially unfixed bug report doesn't solve any problem (except maybe it looks better to the outside, but that would feel like a lie to me).

2. Our friend @ghost (who doesn't exist anymore) requested a feature [Ensuring that symbols defined in an importing module are referenced Nim#2368](https://github.com/nim-lang/Nim/issues/2368) in 2015 and since then nothing.
This is not an isolated case, there is this one nim-lang/Nim#4464 and nim-lang/Nim#5194 for Visual Studio 2015. Ok, we don't close feature requests because it's not respectful but after 5 years what's the point? Yes, it's frustrating but after several years the contributor have either developed it or bypassed it. Worse, changed the language.

I don't have any problems with closing old (as in several years old) feature requests, but most issues are (at least nowadays) bug reports, since feature requests are usually submitted as RFCs.

Whatever you do, when there are too many issues > 2500, as I hope, Nim becomes more popular, you'll be forced to put this up to save time and readability.

Instead, how about we fix them eventually? There are projects with far more open issues (Rust has more than 7000, GHC (Haskell) has more than 4000) and they're doing fine. Sure, they have more contributors, but so will Nim, when it gets more popular.

You could argue that it looks better to the outside to have few open issues (and indeed it does), but the amount of bugs would be the same, we'd just pretend there were fewer. I couldn't say "Look, Nim has so few issues!" in good conscience. I don't see what advantage it would give developers either. Would they really fix more bugs if there were less reports? People do fix bugs all the time, as you can see if you look at PRs. Also, there is a chance that old reports get closed and people get demotivated because seemingly noone cares. Or people just always bump their issues, in which case, what do we gain?

tl;dr I simply don't see any (moral) advantage of this.

There is no advantage in closing old issues indeed. We have 1900 open issues. Let's say we can immediately close 1000 of these, either because they have been fixed already, were invalid or are outdated. We're left with 900 open bugs. Can you prioritize among 900 issues? I surely cannot do that more effectively than prioritizing among 1900, even 100 open bugs is too many to chose from. So instead bugs get tagged with "showstopper", "severe", "medium" and "low" and I work on the showstopper bugs and when they are fixed we work on "severe" bugs. The existing system works.

nim-lang / RFCs

[CI] Use bot to remove very old and obsolete issues #395