Consider the GitHub "Stale" application for backdrop-issues

[indigoxela]

Issues queues tend to fill up with stale issues over time. GitHub offers a free application for this use case.

https://github.com/marketplace/stale

After a period of inactivity, a label will be applied to mark an issue as stale, and optionally post a comment to notify contributors that the Issue or Pull Request will be closed.

It also allows to define exemptLabels which prevent issues from auto-closing.

I wonder, if this could be useful to keep backdrop/backdrop-issues clean(er), so I'd like to start a discussion here.

Personally, I never used that application, but the description sounds appealing to me.

[ghost]

I've seen this (or similar bots) used in other issue queues, and I can see the benefit. Though we'd want to avoid a situation like:

• [A month with no activity]
• Bot: This issue will be closed in 1 week...
• Admin: No, don't close!
• [Another month with no activity]
• Bot: This issue will be closed in 1 week...
• Admin: No, don't close!
• etc.

So yeah, creating a not stale label would be handy for those situations (e.g. meta issues, etc.).

[stpaultim]

A few random thoughts about this:

• That when looking for related issues in the issue queue, I focus on open issues and assume that closed issues are fixed already. If stale issues get closed automatically, I may have to change my strategy and I'd like a good way of telling the difference between issues that are closed because they are fixed/resolved and those that are closed because they are stale.

• seems fairly common that issues 1-2 years old, suddenly gain new life and get acted on. I think that we'll see more duplication of issues if we are closing old issues that are not resolved and we may loose track of the history of an issue (??).

• If we do this, I would suggest not having an issue become stale for 6-12 months. I think that active issues often sit for 2-3 months in our issue queue, just because we have a lot of things going at any time. "Active" is a relative term.

• If we do this, I'd like to be able to get notifications of which issues are being closed because they are stale. I could envision a weekly email listing the title of all issues that were closed that week because they were stale (or every day). That way, I could browse through the titles and check for any that might be interesting to reopen. We might actually surface some interesting issues that way.

• This would really save @BWPanda some time. :-) Is that a good thing or a bad thing.
  On occasion, I've also gone through very old issues and closed a few. It can be interesting/fun, but it's also not the most productive use of my time.

• There is a point at which an issue does just become too old to worry about. I just don't know exactly when that is.

I could support using a tool like this if we could do the following:

1. Tag issues "not stale" (as was discussed)
2. Be pretty generous about how long we leave issues open (6-12 months - open for discussion).
3. Get notifications, individually or in bulk, about which issues are being closed. This might just be a way to sort the issue queue and see which issues were marked stale recently.

[ghost]

@stpaultim Thanks for the feedback. It looks like you can set a label that's applied when an issue's marked as stale. That means there will be ways you can see stale issues, sort by most recently updated, etc. That might address some if your concerns.

Here's some better documentation about what's possible with the bot: https://github.com/probot/stale/blob/master/README.md

[ghost]

This would really save @BWPanda some time. :-)

I knew it; I'm being replaced by a robot! 😄

[indigoxela]

@stpaultim some random answers to your random thoughts... 😉

we'll see more duplication of issues ... and we may loose track of the history of an issue...

Maybe yes, maybe no. If an issue queue fills up, people often miss an already existing one and create a new issue anyway.
The larger a queue gets, the harder it is to find the one that already covers a (my current) problem.

...I'd like to be able to get notifications of which issues are being closed...

It seems, that's exactly how this robot works. It gives a warning (comment = mail), adds a (configurable) label and after a configurable time span with no activity the issue gets closed.
There are no batch notifications, though. So this robot might send a lot of mails if we have a lot of stale issues.

Another thought: if issues get really old, they need re-evaluation anyway. It might be, the problem was already solved by another issue.

@BWPanda Noooooo.... no robot could ever replace you! 😂

[olafgrabienski]

I had similar thoughts as @stpaultim, and I see that the concerns can be addressed with a reasonable configuration of the bot.

[stpaultim]

This was discussed in some depth during the DEV meeting today (https://youtu.be/ot7ug0NvdFY)

There were some fairly strong objections to automatically closing issues. There is a strong concern about how the impact that might have on the people who took the time to report issues, to see them closed at a later date automatically. There is a sense that an issue that is unresolved should just stay open until it's resolved and that it's better to have a human triage these old issues and decide what should be closed.

There was interest in adding tools that would make it easier for humans to triage and close old issues. We primarily discussed two options.

1. Automatically tagging old issues with a label such as "Stale" that would make it easier to find and triage these issues.
2. Creating a filter link that with instructions that helps people find these old issues and triage them.

@jenlampton expressed some concerns about too many labels and encouraged us to create a useful link to a predefined filter that would help users triage these old issues.

I was just looking for a way to filter by a relative data or time ago - unable to find that, a temporary solution would be to pick a specific date and then update the filter from time to time. For example the following filter is:issue is:open updated:<=2016-10-31 would show all issues open that have not been updated in 3 years. But we would have to update the date from time to time.

FYI - there are currently 186 open issues that have not been updated in the last 3 years. We could work our way through them and then change the filter.

But, for this to work, we'd want to update each of these issues so that we don't end up retriaging them over and over. We could look at each of these issues and either close them or post a short comment saying that that it is still a relevant issue.

If we were do this, we'd in effect be saying that our goal is to NOT have any open issues that have not been commented on for more than 3 years (or some other time frame) and then either close or comment on each one until we reach our goal. The downside would be that many of these issues would float to the front of the "updated queue" without any real new information.

NOTE: I don't feel strongly about this, but would be willing to help triage old issues from time to time.

[ghost]

I personally disagree with the objections to this proposal. I think a carefully and respectfully worded message would suffice just as well as manually reviewing old issues. If the original author is still around/interested, they can reply to keep the issue open (same as if I manually ask them if it's still relevant). And if they don't care anymore they can ignore it and it'll be closed (which from experience I've seen is the case with the majority of old issues). I don't see any benefit to the manual process vs. an automated one, only more work, time and effort that could be better spent on other issues.

[indigoxela]

I don't see any benefit to the manual process vs. an automated one, only more work, time and effort that could be better spent on other issues.

I second that.

Of course, we don't want to be rude and close issues too early or in a disrespectful way, but I'm pretty sure, we're able to use that application without giving people a feeling of "a bot killed my contribution".

Please note: we're talking about times of inactivity of one or even more years, at least several months. If no one showed any interest on it for such a long time, and it's none of our meta tasks, this issue is obsolete for sure. At least to my understanding.

Another concern was: Issues should only get closed, if the problem is really fixed.
Yes, in a perfect world I'd agree. But in reality, there is always more work to do than people with spare time to do it. A label shows the reason for closing anyway. And at any time one can re-open such a stale issue.

Anyway, this is an interesting discussion. I'm curious, what the final decision will be.

[herbdool]

I'm all for using the bot. It's configurable so we can make sure that we're transparent and that we're considerate. And even if we decide not to close the issues, we could use a different action to just label them as stale to help people triage.

[ghost]

Also, as discussed in Gitter, GitHub now has native support (currently in beta) for actions such as Stale: https://github.com/actions/stale

[ghost]

Should this issue be marked as 'stale'? 😆

But seriously, do we continue to push for this or not?

[klonos]

I'm fine with this, so long as we don't auto-close:

we could use a different action to just label them as stale to help people triage.

[ghost]

Yeah, I think we should trial this by adding a new stale label to appropriate issues and posting a comment saying that the issue has been marked as 'stale' (so then participants are notified). After trialing that for a while, we can gauge feedback on whether adding an auto-close action would also be appropriate.

[ghost]

I have just setup this on the Auto Entity Label repo as a test:

• Config file
• Log
• Example 'stale' issue

If we want to test it here, we need to decide:

• How long since the last activity before an issue becomes 'stale' (I recommend either 6 months or 1 year)
• The wording to use for the automated message

For the wording, I think something like this:

This issue has not had any activity for [6 months] and has been marked as 'stale'. If there is no further activity in the next few months, this issue may be closed."

[ghost]

Here's a PR: #4757

[indigoxela]

One year later and after seeing myself fixing several pretty old issues, I'm not so convinced of the "stale" concept anymore. 😆

Anyway, I like @BWPanda's suggestion to do some cautious testing with only adding a label (no autoclose) and see how this affects our workflows.

The name could be more precise.. "Mark old issues as stale" - I don't think it's the age that causes a stale label. How about "Mark stale issues"?

[stpaultim]

I'm fine with auto tagging issues that are inactive. In fact, if we are auto tagging old issues, I prefer the term "inactive" or something like that. However, I'm fine with "stale." If we do this, I would say that anyone can remove the "stale" or "inactive" tag at any time.

I would not tag an issue as inactive for at least a year (I would prefer 2 years). I find it pretty common that issues 6-12 months old suddenly get very active and issues that have a lot of interest, sometimes go quiet for 6 months or more without becoming less important (just less urgent).

I don't really see any benefit to auto closing old issues, but am happy to leave that discussion on the table for later.

[jenlampton]

I'm against auto-closing. There's nothing more sad then searching for a bug you are experiencing and finding a github issue that has been auto-closed with no human interaction other than the original report. It's a contribution killer. Why would that first person ever contribute anything again? What does it mean for an issue to be stale? We can already reverse-sort issues by recent activity. I feel similarly concerned for our contributors when adding stale label automatically. We already have a "cannot reproduce" label that people can add when appropriate.

…

On Thu, Nov 12, 2020, 11:46 PM indigoxela ***@***.***> wrote: One year later and after seeing myself fixing several pretty old issues, I'm not so convinced of the "stale" concept anymore. 😆 Anyway, I like @BWPanda <https://github.com/BWPanda>'s suggestion to do some cautious testing with only adding a label (no autoclose) and see how this affects our workflows. The name could be more precise.. "Mark old issues as stale" - I don't think it's the age that causes a stale label. How about "Mark stale issues"? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4172 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADBER3Z7UO2TIWYLHJOU5LSPTP47ANCNFSM4JGV5GPQ> .

[ghost]

What does it mean for an issue to be stale? We can already reverse-sort issues by recent activity.

Yes but how often do we actually do that? The benefits here are:

• Old issues are automatically tagged (and therefore slightly easier to find - means you can filter issues by 'stale' label and sort by date (asc or desc))
• But primarily: the bot automatically posts a comment saying the issue is 'stale' which prompts a response from the participants (who get notified)

[jenlampton]

If people aren't using the tools we already have, I don't see how adding a duplicate one that's slightly harder to use will make them use it more. A reverse sort on the queue is already only one click. We already use a lot of labels and n the core queue, I don't really want to add another one that indicates something we already know. But most importantly, I am concerned about demoralizing contributors. If the primary benefit is the posting of a comment, why don't we automate that part, but with some more helpful and friendly language?

…

On Fri, Nov 13, 2020, 12:39 PM Peter Anderson ***@***.***> wrote: What does it mean for an issue to be stale? We can already reverse-sort issues by recent activity. Yes but how often do we actually *do* that? The benefits here are: - Old issues are *automatically* tagged (and therefore slightly easier to find - means you can filter issues by 'stale' label *and* sort by date (asc or desc)) - But primarily: the bot *automatically* posts a comment saying the issue is 'stale' which prompts a response from the participants (who get notified) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4172 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADBERYTBWM6O2BE23Q3273SPWKRNANCNFSM4JGV5GPQ> .

[klonos]

A reverse sort on the queue is already only one click.

I have to admit that that's what I do as well when I feel like revisiting the oldest issues in our queue.

[ghost]

If the primary benefit is the posting of a comment, why don't we automate that part, but with some more helpful and friendly language?

If we want to test it here, we need to decide:

• The wording to use for the automated message

I was asking for suggestions for the wording of the message, so please feel free to share ideas.

[indigoxela]

It seems that we all agree that auto-closing isn't what we want.

the bot automatically posts a comment saying the issue is 'stale' which prompts a response from the participants

That's where I see the benefit of it.
Often people post something, share ideas, make suggestions... and then the issue slips out of sight. A reminder mail may get back their attention and revive the discussion. At least, that's what I hope.

[ghost]

I'm losing interest in this issue. There doesn't seem to be much support for it. Maybe we should close for now and possibly re-visit later...?

[indigoxela]

There doesn't seem to be much support for it. Maybe we should close for now and possibly re-visit later...?

Agreed.