Stale issues on theia-apps

Do we just wait when they are closed automatically: Should not someone verify whether they are valid and keep valid opened? cc @marc-dumais @vince-fugnitto

[original thread by Anton Kosyakov]

I don’t think that we want to make an impression that the proejct is not actively supported, since valid issues get staled and never taken care by maintainers. If it is an idea i would rather not do it on theia repo. I would imagine that it can be useful just to bring an attention of maintainers to old issues. Although right now it could be bad timing if a lot of issues go stale on theia repo and someone has to verify whether they are valid. Plus it would generate a lot of noise via email notifications.

That’s why I’ve proposed marking issues as stale with the question label only.

@anton-kosyakov we wanted to try out the bot on the theia-apps repo as a dry-run for the main repository, and a major reason for not adding it now only affecting the question label was since it had a bug ( In general, I try to look at old issues/prs in the theia-apps to see which are still valid and let the bot close them automatically after 30 days of being stale. This will give the authors and maintainers some time to verify the issues. I assume the noise from the bot is more of an initial and temporary problem as a lot of issues/prs were old and inactive, but once it passes it should only happen regularly.

Hi Anton. Fair point about it not being ideal, to let valid issues get stale and closed by the bot. At the end of the day, the bot is not an intelligent agent, and we need to guide it so that the end-result is what we want. The good news is that the bot is very configurable and we can be pro-active for those issues we want to keep. For example, we could add a label to such issues/PRs that we want to keep that, once applied, will tell the bot to leave it be. e.g. “no-bot” or “no-stale”. We can also exclude labels from the stale process when it makes sense, like “epic”.

What do you think?

If/when we introduce the bot to the main repo, we have the choice to configure it conservatively, if wanted. Then starting with a small white-list of labels to consider could make sense (e.g. like only considering label “question”, like suggested by Akos).

I would vote for the conservative approach. Each morning i try to review new issues, it would be hard if there would be 100 staled issues. I will need to figure out which are new and which are changed by bot. Plus we would need to take an action on these issues to decide whether to keep the or not. For PRs i won’t enable it all. For issues maybe very high threshhold that it does not turn a lot of issues to stale at once but a bit each day. So they can be reviewed next to new issues.

I think that’s fine, we can configure it to only mark issues conservatively (perhaps 1 issue / hour) using the config option:

# Limit the number of actions per hour, from 1-30. Default is 30
limitPerRun: 30

We can also increase the time before stale and closed states.

And once fixed, only apply the bot for specific labels and excluded others

ok, we can try such config only on question label first

and then expand to other labels or increase the limit?

I was waiting on so hopefully it’s addressed soon else it ignores the labels

Yes, that way we can have a gradual “ramp-up” instead of a “big bang” where too many issues are subject to “bot operations” all of a sudden. At some later point if the white-list is getting long and it would be simpler, we have the option to switch to a black-list, where we let the bot handle all issues except those with labels we chose to exclude.