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.
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.
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.
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).
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.
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.
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.
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
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.
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.
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, 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.
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.
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.
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.
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.