Replies: 3 comments
-
I responded to this here already: #865 (comment)
let me assure you it does in this repo |
Beta Was this translation helpful? Give feedback.
-
Thanks for the explanation, I understand your approach to GitHub issues better now. It seems you are treating the issues as your personal to-do list, rather than a place for the community to find issues to work on (or share workarounds). You are responsible for a popular FOSS project that I personally rely on and enjoy, so if this works for you I have to respect your process, even if I find it frustrating. If you must use this approach, I encourage you to rethink how you manage closed issues. When I browse through closed issues, I generally cannot tell which are closed because they have been fixed/implemented, and which may still be worth working on even if nobody is currently working on them. There are a few exceptions, such as the "wontfix" label which certainly clarifies things, but I don't see a "done" or "finished" tag for example. There is no "upstream" tag indicating the fix must be submitted elsewhere. When I click on the "good first issue" tag, I see a bunch of closed bugs, but which ones might still be good first issues, and which are no longer good first issues because they've been fixed/implemented? It seems if you want the closed bugs to be useful to the community, you'd have to do a lot more with tagging. Simply not closing these bugs seems simpler to me, but I guess it's just a question of where you want to focus your maintenance efforts, since I acknowledge that open issues can eventually be left behind by evolving software and need to be periodically checked to see if they're still relevant. I will say that the current system seems hostile to bugs that aren't quickly picked up by someone who wants to fix them, and I don't know how to keep a bug I care about in the public eye without repeatedly leaving comments to defend against stale bot. If I had confidence that the bug would still be easily found by people who want to find it, I wouldn't feel compelled to create this noise. How can someone who has the time and skill to fix my issue find it once it is closed, among all of the closed bugs that are no longer relevant? I also encourage you to think beyond this specific project, to the broader GitHub community... even if you are able to maintain a clear distinction between active and inactive bugs, e.g. by reopening bugs that someone is working on, many projects like the one I complained about do not succeed at this. In other words, many people may not consider it to be a reliable signal of what is actually being worked on by someone (especially if that someone is not a maintainer) once stale bot is in the mix. |
Beta Was this translation helpful? Give feedback.
-
Please disable stale bot on GitHub. It makes the open or closed status of an issue meaningless, and increases GitHub notification noise.
My understanding is that if an issue is closed, it means:
If stale bot runs around closing bugs willy nilly, now the closed state doesn't mean much of anything. The difference between a closed bug and an open bug can just be happenstance, or the confluence of tangential factors such as:
In my last confrontation with stale bot, me and the other user who cared about the bug eventually found someone to work on fixing it... But the bug is still closed! yuin/goldmark#180 "Closed" doesn't even mean that the bug is inactive, that nobody is working on it, because stale bot sucks meaning out of the universe!
From now on I will link to this issue in issues that stale bot marks as stale, rather than repeating myself.
Beta Was this translation helpful? Give feedback.
All reactions