Huge number of open issues

[JayPalm]

I've noticed that there are a huge number of open issues from many years ago. Can we start to go through and close old, stale issues? I know many projects have bots that automatically close issues after so many days of no activity, maybe something like that should be implemented? Additionally, as I've been solving the various issues I've had (currently, mostly related to GSM), I am trying to post my findings, code samples, etc to the existing issues that I came across, I'd love a way to signal to maintainers that the issue is now solved and should be closed.

[stinos]

Bots cannot correctly determine whether an issue is stale. Just old, but that is not good enough of a reason to close it. At least in my opinion: just like I do for the day-job teams I work for, MicroPython seems to treat issues not literally as issues but also as feature requests or even just mere idea placeholders. So closing means 'done/won't implement/irrelevant/not an issue', not just 'not quite done but closed because it is old'. As such I also don't immediately think of a huge number of open issues as an issue :)

I'd love a way to signal to maintainers that the issue is now solved and should be closed.

I'd suggest leaving a comment. If needed with some kind of proof that the issue is effectively solved.

[JayPalm]

Fair enough, and reasonable. Thanks for the input.

[jimmo]

@JayPalm Sorry about the delay responding! Thanks for the feedback.

We've discussed auto-closing old issues but my experience with other projects (and in private work bug trackers) is that this isn't a good experience. Just because a bug is old doesn't mean it's not relevant any more, it just isn't the highest priority.

The maintainers do try to keep on top of reading all updates to issues/PRs/discussions (which we do mostly via email updates). So if you have a update to an issue (especially if it's to say that it can be closed!) then please do post an update and we will likely see it.

I do wish GitHub had more features for this, for example a limited set of tags that any user could apply to an issue.

But to the broader point, yes it's definitely not ideal because it seems to give people the impression that issues are being ignored or not taken seriously. The reality is just that MicroPython has a very large scope, we get a lot of issues raised of highly variable quality, it can be a lot of work to investigate any given report and we err on the side of leaving them open rather than closing them.

We've made a real effort in the past year or so to ensure that we dedicate specific chunks of time each weeks to triage and processing of issues and PRs rather than just doing this organically. PRs have been the priority though. I've actually forgotten what the number was when we started but I think we're now something like 100 fewer open PRs than we were when we started (~350 -> ~250), despite a lot of new ones being raised in the meantime.

When we get the PRs under control, I'd like to investigate finding a way to combine related issues into "aggregate" issues for a given MicroPython feature... i.e. one issue that captures all known issues and feature requests for, say, ADC on ESP32, and then more proactively de-dupe new issues into these "tracking" issues.