This is not a way to assert a bug is fixed. Success looks like actually trying the code in the bug report that demonstrates the bug, and/or contacting the report participants, to confirm that the bug is actually fixed for the participants.
the point of a bug report is to let you know something is going on, to provide context useful in tracking it down, and tracking for the eventual resolution.
as they years tick by, some bug reports are counterproductive because they are unclear, dont give _any_ diagnostic information, or are no longer relevant because the codebase has shifted.
its great to say for each of these issues we should spend a day or two trying to reproduce them - but its really not the best use of time.
we're not talking about capriciously trashing useful bug reports. we're trying to lower the noise floor so that the actionable bugs stand out and are more likely to be dealt with.
- if the issue lead to a commit, or a merge is mentioned in the thread, then it is actionable,
- if the issue was closed without any code change, then it is noise.
and I bet your AI isn't going to be able to say 'oh yeah, thats just that thing we fixed in 2.1'
seems useful in a second-order capacity though - process introspection
Sure for commercial situations you expect the customer to sign off on a fix but a maintainer's responsibility in open source is exactly 0. Even having a bug tracker is an affordance from the maintainer, GitHub supports turning issues off.
I'm going to continue to terminate old issues where the problem described was vague or the reporter has gone AWOL and I would encourage all OSS maintainers out there to do the same, let's manage expectations.
I personally think that's fine. You'd have the time to verify and close every issue in a perfect world, but the world rarely is. Before that we had 100+ issues open with bugs we could not even reproduce that where open for years. It just becomes clutter at that point.