Add a stale bot to help grooming issues

[masci]

This workflow will:

• Mark an issue with the stale label after 15 days of no activity on issues labelled with waiting for feedback
• Close an issue after 30 days with the label stale attached.

The stale labels is automatically removed as soon as somebody leaves a comment on the issue.

[per1234]

I don't support this. The fact that an issue hasn't been resolved in 30 days has no relevance to the validity of the issue.

If an issue is invalid, then close it. If it's valid, leave it open as long as it takes to get fixed.

[masci]

@per1234 that's not how it works. This only works on issues where a maintainer has manually put the special waiting for feedback label, it doesn't apply to bugs or feature requests.

[rsora]

LGTM, @per1234 basically to trigger all this automated workflow, a maintainer need to put the waiting for feedback label on the issue.
No label, no marking as stale. No marking no closing :)

[per1234]

I act as the "Stale Bot" for the Arduino/arduino repository's issue tracker. Every couple of months I go through the issues labeled "Waiting for Feedback", prompt the users from whom we're waiting on important feedback, and close issues where it's clear the user is not going to provide the feedback and the issue is invalid without that feedback. So this PR would automate that.

However, what I've found is that there are some issues that are still valid even without the requested feedback being provided. There's no way for a machine to make that distinction. Often it goes something like this:

USER: There is a bug...
Maintainer: Does ... fix the bug? *adds "Waiting for feedback" label

Even though the user doesn't respond, the bug may still be valid. Some other user may later come to report the same bug, and respond whether the possible fix works.

Now, I suppose we could comment on these issues every month to keep them open, but that just seems tedious and a lot of "noise" to me. I have found that acting as a human "stale bot" takes very little time, even though the Arduino/arduino issue tracker is very active.

[masci]

USER: There is a bug...
Maintainer: Does ... fix the bug? *adds "Waiting for feedback" label

As a rule of thumb, when not sure, we'll not add the label and the bot won't take any action.

Even though the user doesn't respond, the bug may still be valid. Some other user may later come to report the same bug, and respond whether the possible fix works.

Closed issues are still searchable and can be reopened. From my OSS experience, if an user doesn't bother to search throughly an issue tracker, it's very likely they'll just open another one, whether a similar issue exists or not, is open or closed.

Now, I suppose we could comment on these issues every month to keep them open

Nah, in this case I'd just remove the waiting for feedback label because it means we were able to reproduce and we don't strictly need feedback anymore.

[rsora]

I see your point @per1234 , I suggest the following:

1. we keep the bot active for now and close the PR
2. we plan a next session of grooming in which we do some screening together, to refine both the manual and the automated workflow, this way we can also create and additional label to mark an issue that needs feedback but not to be inserted in the automatic flow, if needed.
   What do you think about it?

[masci]

I think bot's settings are conservative enough to let us keep it under control. I'm going ahead and merge, we'll evaluate how much value the bot is bringing at the next grooming session and we'll decide whether to keep it or change it or remove it.

[per1234]

From my OSS experience, if an user doesn't bother to search throughly an issue tracker, it's very likely they'll just open another one, whether a similar issue exists or not, is open or closed.

In my experience, the ones who do search usually only look at the open issues. GitHub even filters out closed issues in the default search settings. That said, I have seen a very significant reduction in duplicate issues ever since the last update to the Arduino/arduino repository's issue template and CONTRIBUTING.md, which now very clearly instructs the user to check the closed issues.

we do some screening together, to refine both the manual and the automated workflow, this way we can also create and additional label to mark an issue that needs feedback but not to be inserted in the automatic flow, if needed.

That sounds like a good plan. I'm very happy to assist with the maintenance of this issue tracker in any way that might be helpful. I have never had any specific communication as to what my role should be here, so I've just tried to make my own judgements as to how I can be helpful. In the earlier days of the arduino-cli project, we didn't have many active maintainers, so I felt confident that it was helpful for me to take an active role in maintaining the issue tracker. Now we have such a amazing team of people working on this project that it's not always so clear to me whether I should get involved in a new issue report or if that will just get in the way of someone more knowledgeable in this area.