Libelektra: bot for automatically closing bugs

[markus2330]

Many projects automatically close bugs if they had no activity for some time. I propose that we close all low-priority issues which do not receive any activity within one year, and any other bug within three years. It would be nice if it would be possible to get a list of these automatically-closed bugs.

[mpranj]

First, thank you for cleaning out many issues.

Second, I agree with the proposal that we should keep the issues with a clean focus on next releases. The current state is such that I do not really look at older issues because of the amount.

My only concern would be that a bot can not distinguish between important and unimportant issues. I'm quite sure we have important issues without recent activity. Thus the list of auto-closed issues is mandatory in my eyes.

[cerna]

(...)My only concern would be that a bot can not distinguish between important and unimportant issues(...)

Cannot you use labels for this? I - as normal, non-privileged user - can't manage labels (I tried for this issue), so all you would need to do is to assign important ones some label. That way it would be one time job done when the issue is opened. Minimal work spread across time.

The bot could then query only issues without label or with specific label and close ones accordingly.

For newly interested person like me, it is kind of annoying to see over 80 changed issues in most of which I have no idea if it is important to my use case or not. But spread over time it wouldn't be a problem.

[markus2330]

Thank you @cerna for jumping in :wink:

Yes, labels should be able to handle this. One of the issues about labels you already found out: only ElektraDevelopers can modify them. In your case, we can simple add you to ElektraDevelopers. Other people would need to ping issues so that they do not get automatically closed.

@mpranj wrote:

My only concern would be that a bot can not distinguish between important and unimportant issues.

Yes, I agree. We could also have some tags to prevent auto-closing. E.g.: to not close

• important/urgent: never close
• bug/usability: close in three years
• question/help wanted: close in one year
• proposal/enhancement: close in three months, with a reminder
• low priority, duplicate: close in one month
• otherwise: close in one year

Btw. https://github.com/probot/stale does not seem the flexibility to implement something like this. We can also go to a more simple schema: close everything in nine months, but not important/urgent/usability/. If we do like this, "low priority" is actually not needed.

What do you think?

First, thank you for cleaning out many issues.

The most important feature of auto-closing (and the reason why I opened this proposal) is a psychological one: In some cases I hesitated to close the issues because I knew that people spent a lot of time writing this issue, especially if it was a long proposal or feature request. From the rationale point it is clear that such an issue should be closed as these were usually huge changes for small benefits. An auto-closer would not have such hurdles and would treat all issues the same (I might also bias to close my own proposals less likely. E.g. #736 is obviously something which is beyond our reach but when going over it, I did not think of closing it. I corrected this now.).

Once we implemented auto-closing, cleanup is equivalent to do proper tagging. Then it is the responsibility of the reporter to have activity before the issue closes by itself and I do not need to worry if someone feels bad because I closed a "nice proposal".

[mpranj]

Thank you @cerna for the hint! @markus2330 thank you for checking this in more detail!

While the complex proposal sounds well adapted to how we use issues in this project I think I am in favor of the simple proposal (close in x months or exclude by label). The simple proposal is supported by probot and is also simple and clear to remember for all developers.

Additionally, we can configure the close message s.t. people are encouraged to re-open if they think an issue slipped through the radar and was closed by mistake (e.g. missing important label).

[markus2330]

I agree. If there are no objections tomorrow in the meeting we can implement the auto-closer with probot and a simple configuration. Fine-adjustments with more/less labels can also be done later.

[cerna]

(...)One of the issues about labels you already found out: only ElektraDevelopers can modify them(...)

I meant it as form of authorization. That nobody can upgrade his issue to _non-deletable_ without write/admin access to the repository. That way it is protected against _not so funny_ pranksters.

(...)Yes, I agree. We could also have some tags to prevent auto-closing. E.g.: to not close(...)

I presume you mean updated and not closed, right?

If I haven't done any stupid mistakes in this query:

{
  search(type: ISSUE, query: "repo:ElektraInitiative/libelektra is:issue is:open -updated:2019-04-13..2020-04-13 -label:\"low priority\" -label:duplicate -label:proposal -label:enhancement -label:question -label:help -label:bug -label:usability -label:urgent -label:important", first: 100) {
    issueCount
    nodes {
      ... on Issue {
        title
        labels(first: 100) {
          nodes {
            name
          }
        }
      }
    }
  }
}

That gives about 39 issues in the otherwise: close in one year category. If you limited it to - I don't know - five issues per day per category (or ten issues per day across all categories), it would work nicely without big pushes.

I think with jq and something like this it wouldn't be too hard to create the wanted mutations to achieve this proposal.

[markus2330]

Thank you, great job!