What is the best practice when closing Github issues?
From my point of view, after a fix is merged the original reporter of the issue should confirm (re-test) that the issue is fixed before closing the issue.
But de-facto this rarely happens, often the package author thinks that an issue is fixed and closes it immediately, and then I have to ask to re-open the issue, sometimes multiple times. I don’t like that. Should my suggestion in the second paragraph become a best-practice rule?
Ideally, a PR/commit introducing a fix for an issue should implement a representative test to ensure the problem is actually fixed. This has the advantage of also making sure that the bug doesn’t show up again, i.e. that there’s no regression and that things that used to work continue to work.
The problem is, that this is not always possible. For example Makie, but also other GUI programs often fail on specific versions of an operating system, and as-far-as-I-know the test infrastructure does not support different versions of the same OS. Example: Installation of GLMakie on Ubuntu 24.04 fails · Issue #4002 · MakieOrg/Makie.jl · GitHub
Usually an issue is closed if a bug is fixed, and that bug is hoped to be the original one, but sometimes it’s not possible to be sure if the original bug isn’t easily reproducible. If the original bug in fact hasn’t been fixed, re-opening makes sense, but so does filing a new, ideally more specific issue (making it clear that you have tested on the version with the supposed fix).
I don’t think it really makes sense to always wait for the original author to confirm, since most authors in fact don’t check, so many issues would just linger for a long time, adding to confusion if the bug has actually been fixed.
I do not agree. It can be a valid approach to ping the original and ask to re-test. If he doesn’t reply within a week it might be OK to close the issue, but not even asking him is not a professional approach.
I usually leave it up to the author but I don’t think it’s too bad to just close it - the author can always open it if they disagree. Also keep in mind that most of these developers are working voluntarily, judging someone for not being “professional” (however that is defined) is a bit of a reach…
Not really. We are trying to encourage best practice in many fields, and many of the voluntary package authors do this job for years, so they can also improve.
But only if we agree and document on how “best practice” should look like.
But who is “we”? There is no overarching body paying these people. It is up to the developers how they want to run their package.
This community. The people active here at discourse.
I don’t think that’s enough to really want to judge someone as being unprofessional. I do see the point of the issue but we are all just free users of these packages made and developed for free, it’s a bit harsh to judge them as being unprofessional (whatever professional means in this context).
I certainly do some things in my own packages that might not be professional if I were paid to make them, but I don’t think there should be much expectation that I be made to adhere to any sort of best practices.
In this case the issue was closed after the maintainer believed the bug to be fixed. Of course people can make mistakes but I don’t think it needs to be more complicated than that. If I can reproduce a bug and fix it, I’ll close the issue without confirmation. If I can’t repro it and can’t test it in CI either, I will wait for someone with an appropriate system to confirm. That may or may not be the issue author.
Note that there is a built in mechanism. If a pull request says it fixes #1234 and then that pull request is merged, then issue #1234 will be closed automatically.
That is not a culture issue, that’s just how Github works.
This is crap. Perhaps I worked too long at ABB. It just doen’t make sense to close an issue if the person who reported it doesn’t confirm that it is really fixed.
You can read about the “feature” here:
This is simply an unrealistically high standard to apply to all issues.
You can. But you don’t have to. You can also close issues manually at a good point in time.
But it is a standard that you can apply in general. You can always make exceptions. Not doing it means to create frustration with the people who report issues and it results in low quality software.
For what it is worth, in the packages I maintain, I close issues immediately. If I have even a slightest hunch I’ve fixed the bug, I’ll close the issue immediately, without waiting for the person who opened it, or any user, to say anything.
If someone believes the issue is not fixed, they can re-open the original GitHub post or open a new one, it’s not a big deal! 
Yet, the organizational power I get for closing the issue is an immediate benefit.
99% of the time the issue is probably indeed fixed. I’ve not personally had a problem where I’ve made an issue, it’s been closed, and then the issue wasn’t actually fixed as advertised - it probably just means there’s insufficient detail in the example provided in the issue’s description.
There’s little motivation for the developer to create more -unpaid- work from themselves by waiting for the author to confirm (fix the issue, mention the PR in the issue but don’t close it, make a comment in the issue and ping the author) when, most of the time, they can just fix the issue and close it automatically with the PR.
The author of the issue should just make a comment explaining if it wasn’t fixed.
The frustration is evident in your writing, so I give you that. But I don’t think software quality is lowered by closing issues prematurely, as they’ll just be opened again if they’re not fixed. The problems keeping quality low are that you don’t have time to fix all the bugs, don’t know how to fix them, or you don’t guard them well enough with tests such that you later break things again unintentionally.