Stackage: Reducing bounds issue noise

[bergmark]

Currently comments on bounds issues are majorly maintainers noting that they have fixed their packages. Unless these packages have reverse dependencies that also need updates (possibly outside of hackage) the notifications that are generated doesn't give any benefit to other maintainers, and it only really serves a purpose for stackage curators if it means we can close the issue.

We have previously experimented with locking bigger issues, is this something we should start doing again for issues above a certain size?

Optionally curators post occasional updates with fixed or remaining packages (we do this sometimes).

Currently you can mute issues that you consider "done". Does that mean that people might miss additional comments mentioning them or does github re-subscribe them to the issue?

What do you think?

PS.

2294 has another suggestion, some people don't want to be notified when their package is being held back when there is no action required on their side. It would be mitigated to a large degree by following my suggestion.

[seagreen]

After you unsubscribe from an issue, GitHub resubscribes you if you're mentioned by name.

[DanBurton]

As a first step, I think we should encourage people to mute the discussion once they have done their part. But it would be better if we could cut down on the noise that maintainers receive without requiring any action on their part.

[DanBurton]

Locked the aeson issue. #2449

[juhp]

Personally I feel the long term solution is to not to use github issues for stackage workflow.
But that requires writing quite a lot of code...

[ekmett]

I just want to speak up somewhat in favor of the current process. The github issues here are the main avenue by which I learn there is a problem, otherwise it'd silently fester until someone pinged me directly. It also fits into my existing day-to-day workflow, as I'm already here checking issues on my own packages.

[DanBurton]

I think our current process is pretty great, but has room to improve over time. I envision more automation and better dashboards (rather than checkbox lists copy pasted and updated by hand).

I do wish for something more tailored to our needs than GitHub issues, but the way GitHub already fits into workflows like Ed's (and mine) is not to be underestimated. It's also great because it's out in the open where anyone can check in and see what's going on or what has happened in the past.

[DanBurton]

Closing as de facto "won't do" per lack of recent engagement with this issue.

(The partial workaround is for curators to manually lock issues with a large number of pings)