# When and how to close Github issues?
**URL:** https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766
**Category:** General Usage
**Tags:** question
**Created:** [July 8, 2024, 11:52am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766 "2024-07-08T11:52:34Z")
**Posts on this page:** 18
**Page:** 2
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [July 8, 2024, 8:17pm UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/21 "2024-07-08T20:17:21Z")
I understand your point of view, but I think there’s a pretty strong consensus around closing issues immediately, as evidenced by GitHub making it a core feature, and the responses to this thread.
I’d say the right time for the person who opened the issues to check whether a PR truly fixed that issue is while that PR is under review. Once it’s merged, the issue should be closed. If it turns out there the PR didn’t address all edge cases later on, the issue should be reopened or a new issue created.
---
### Author:  [@sdanisch](https://discourse.julialang.org/u/sdanisch)
#### Post date: [July 8, 2024, 8:45pm UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/22 "2024-07-08T20:45:26Z")
I’m sure you don’t mean ill, but maybe it’s time for you to reflect on how the free software you use gets actually build and funded.
And how many open source maintainers burn out because of difficult funding and very demanding users, who don’t give anything back, neither in funding nor in actual work.
It seems like it makes you really angry to invest a few seconds on actually re-opening an issue, while you take it for granted that the issue you had just got fixed for free, likely taking someone hours to work on.
How do you even think this is economical for the person that fixes your issue? And how can you expect that person to invest further time into this by following up and running after the issue opener?
I’m honestly curious what your expectations are here, and your cost model. Is a few seconds of your time more valuable than the hours spend by the open source developer?
Or do you take it for granted that someone has a well paid full time job to maintain free software and all that’s missing for them is advise on how to “close issues in a more professional way”?
I’d love to know what you actually think is happening behind the scenes, entitling you to free software and free support in the way you envision it.
---
### Author:  [@sadish-d](https://discourse.julialang.org/u/sadish-d)
#### Post date: [July 9, 2024, 2:19am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/23 "2024-07-09T02:19:57Z")
When I open an issue on open source software, I do not expect to be consulted before the issue gets closed. Work on the software should not dependent on my availability.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 9, 2024, 7:49am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/24 "2024-07-09T07:49:05Z")
Conclusion: As far as I see nobody in this community supports my suggestion to apply a 4-eye method on closing of user reported bugs.
That’s a pity, but I have to live with it.
---
### Author:  [@kellertuer](https://discourse.julialang.org/u/kellertuer)
#### Post date: [July 9, 2024, 7:54am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/25 "2024-07-09T07:54:03Z")
I am a bit late to the party – for me the idea that the PR closes the Issue is the best choice.
Because it means
- the issue is for reporting and clarifying the problem at hand
- The PR is for solving the issue and discussing whether it works as intended. The original issuer should be involved and approve that this does solve the issue raised. Hence, when the PR is merged, the issue is solved and automatically closed.
To ensure the second point I usually ping the original issuer and ask them for feedback. So that indeed does follow the 4-eye idea/method.
_edit:_ For the rest I agree with all the arguments about us doing most of the open source (package development) work in our free time or at least to some extend as work during work time that is maybe not valued as much as it should (at least from my view point as a mathematician, where papers count, but not necessarily code).
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 9, 2024, 8:00am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/26 "2024-07-09T08:00:30Z")
> [@kellertuer](#):
>
> PR closes the Issue is the best choice
Well, this does not work in my example, because the bug in Makie was not fixed with any PR. It was instead fixed in a different package on which Makie depends on.
---
### Author:  [@kellertuer](https://discourse.julialang.org/u/kellertuer)
#### Post date: [July 9, 2024, 8:01am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/27 "2024-07-09T08:01:46Z")
Then you are still in another persons set of rules how to handle these. You can like these or not, but not change them much.
Ifit was resolved in another package, just closing the issue is fine IMHO.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 9, 2024, 8:06am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/28 "2024-07-09T08:06:18Z")
> [@kellertuer](#):
>
> just closing the issue is fine IMHO.
Closing a bug that was found on Ubuntu 24.04 without doing any testing on Ubuntu 24.04 is bad style, in particular because it was clear that the bug appears only on some Linux distributions.
---
### Author:  [@kellertuer](https://discourse.julialang.org/u/kellertuer)
#### Post date: [July 9, 2024, 8:10am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/29 "2024-07-09T08:10:51Z")
Well, as far as I can see, it _was_ fixed.
Independent of that. Entering someone’s repository with Issues / Discussions or even your PR to them is like entering someone else’s house.
Their repo, their rules. If they want you to take of your shoes – you do that.
Sure I disagree, how sometimes PRs are handled (usually some of them are too much rushed for me) – then I might reopen an issue or comment on the PR, but I still do respect their rules. For me that is quite simple. I am happy they provide a package and do their amazing work – and that hey found their way to handle all that mainly in their free time
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 9, 2024, 8:13am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/30 "2024-07-09T08:13:40Z")
> [@kellertuer](#):
>
> is like entering someone else’s house.
Well, I am worried about the quality of the Julia ecosystem and am thinking about ways to improve it. That should be welcome by the community.
---
### Author:  [@kellertuer](https://discourse.julialang.org/u/kellertuer)
#### Post date: [July 9, 2024, 8:23am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/31 "2024-07-09T08:23:09Z")
I am confident that most people mean well and aim for quality, and for the concrete example especially in the Makie ecosystem.
But I do understand now that even my point of how it is meant with PRs and the 4-eyes system is not what you were aiming for. Similarly commenting further on issues and reopening them is a way to do so (and it even worked in your case), so I feel – even with “my house my rules” in most places there is a very good workflow around issues and resolving them. We might have different viewpoints and/or opinions here, though.
---
### Author:  [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [July 9, 2024, 8:44am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/32 "2024-07-09T08:44:46Z")
> [@ufechner7](#):
>
> worried about the quality of the Julia ecosystem and am thinking about ways to improve it
OK, but I don’t think your proposal would help. That is, it’d do more harm than good.
As far as I understand, this is what we (all?) agree about: there’s a spectrum here, ranging from **never** asking for feedback on whether the issue is solved, to **always** doing that, and blocking closing the issue on the feedback. While you advocate for asking for feedback by default, IMO that’s not at all appropriate for volunteer open source projects.
Why your proposal wouldn’t do much good: user feedback is much less valuable than CI. Many would say that whatever’s not covered by CI isn’t supported anyway. If it’s not covered by CI it’ll bit rot again anyway sooner or later.
Why your proposal would be harmful:
- Both the maintainers and issue submitters here are volunteers, may lack free time, and may be located all over the globe. Synchronizing with each other may be (unpredictably) time consuming.
- It’d take away precious developer time, that could instead be used for fixing other issues.
In conclusion, I’d say it’s not the case that the community doesn’t want to improve, it’s rather that there are simply disagreements of opinion on the best practices here.
The workflow you propose may work better for some corpos, but that’s probably because they have dedicated QA people.
---
### Author:  [@goerz](https://discourse.julialang.org/u/goerz)
#### Post date: [July 9, 2024, 10:49am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/33 "2024-07-09T10:49:51Z")
I just don’t know where the idea comes from that the standard workflow (closing issues when a PR is merged) means that the original reporter of the issue wouldn’t verify that the PR resolves the issue. All PRs have a review period, and it would be common to ping the reporter of the issue to check the PR (they might even get notified _automatically_, I’m not sure how GitHub handles notifications there). Most larger projects even require formal reviews of a PR and will insist that the PR contains a test that demonstrates that the issue has been resolved.
Of course, there are issues that are difficult to test, e.g., because they’re platform-dependent, so no check is perfect. I doubt that type of bug is exceedingly common, and I don’t think the standard workflow has any significant impact on software quality. And even within the standard workflow, you can just have a policy of requiring a review by the original reporter before a PR can be merged. If you’re going to insist on closing issues only _after_ PRs are merged, with a secondary post-merge review, you will have to fight the tooling (GitHub), so that just creates extra work for you. Of course, in certain corporate environments you’ll have different tooling and different policies, and that’s fine too. Like [nsajko said](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/32), if you have a dedicated QA department, you might have different workflows.
But either way is fine, and perfectly capable of producing high-quality software packages.
P.S: There isn’t much difference between pinging a reporter after a merge with “Check that the problem is resolved on `master` and close the issue if so” vs “Check that the problem is resolved and reopen the issue if not”. Arguably, the latter case is the more common one, and the former will leave lots of issues open that should in fact be closed.
---
### Author:  [@kevbonham](https://discourse.julialang.org/u/kevbonham)
#### Post date: [July 9, 2024, 4:11pm UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/34 "2024-07-09T16:11:47Z")
> [@ufechner7](#):
>
> Well, I am worried about the quality of the Julia ecosystem and am thinking about ways to improve it. That should be welcome by the community.
I am certain that your motives are genuine here, since you have a long history of productive discussions on this forum. Also as a result of this history, I think you know that this community **also** cares about the ecosystem, and welcomes ideas to improve it. Even harsh criticism by relative newcomers is usually treated seriously, as long as they stay respectful.
But this is no guarantee that people will agree with you.
It sounds like you had a bad experience with a bug report that got closed prematurely, and that’s obviously frustrating. But I’d like to invite you to step back a moment and look at how this thread appears from the outside. You are implicitly saying that Makie, in my opinion one of the crown jewels of the Julia ecosystem, is unprofessional and low quality software. I don’t think that’s what you mean to imply, but you have both the originator of Makie and one of it’s chief architects and maintainers responding and clearly hurt by this, whatever your intentions.
FWIW, I also disagree with your suggested fix - for every bug report closed prematurely in the ecosystem, I would guess there are hundreds that get closed correctly without double checking, and that the cognitive overhead on maintainers to keep track of open PRs or issues would do more to degrade the ecosystem and burn folks out than the need to occasionally reopen an issue.
But if it feels particularly bad for you for an issue to be closed without it being fixed, I’d encourage you to add a line to an issue saying that you’d like to review any PRs, or chime in on PRs when they’re opened - you should be notified if someone mentions your issue.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 9, 2024, 6:37pm UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/35 "2024-07-09T18:37:27Z")
> [@kevbonham](#):
>
> You are implicitly saying that Makie, in my opinion one of the crown jewels of the Julia ecosystem, is unprofessional and low quality software.
I never said that. I heavily rely on Makie, and this is why it is important to me that it works and does not break. But on the one hand side it did not reach version 1.0 yet, which means there are breaking API changes a few times per year. On the other hand GLMakie relies on OpenGL, and OpenGL drivers not always work as expected on all operating systems.
---
### Author:  [@kevbonham](https://discourse.julialang.org/u/kevbonham)
#### Post date: [July 9, 2024, 8:59pm UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/36 "2024-07-09T20:59:21Z")
> [@ufechner7](#):
>
> I never said that.
What you said was
> [@ufechner7](#):
>
> Not doing it means to create frustration with the people who report issues and it results in low quality software.
And
> [@ufechner7](#):
>
> but not even asking him is not a professional approach.
Given that the precipitating experience was in the Makie repo, and they didn’t do what you are advocating, that is the implication, even if, as I said, you did not intend it that way.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [July 9, 2024, 9:18pm UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/37 "2024-07-09T21:18:46Z")
I made a generic suggestion how to handle Github issues. This was not Makie related, I just used one Makie issue as example, but the same happens in many other repositories. My suggestion was rejected by the community. That is fine, no reason to continue this discussion.
Perhaps a moderator can close this thread?
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [July 10, 2024, 9:18am UTC](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766/38 "2024-07-10T09:18:00Z")
[Previous page](https://discourse.julialang.org/t/when-and-how-to-close-github-issues/116766.md?page=1)