# Would it help to have a tool that automatically determines, which issues should be closed?

**URL:** <https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274>\
**Category:** Tooling\
**Created:** [March 1, 2021, 6:16pm UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274 "2021-03-01T18:16:13Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![vpetukhov](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vpetukhov/32/12954_2.png) [@vpetukhov](https://discourse.julialang.org/u/vpetukhov)\
**Post date:** [March 1, 2021, 6:16pm UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/1 "2021-03-01T18:16:13Z")

</div>

I’m looking at big packages, like [Plots.jl](https://github.com/JuliaPlots/Plots.jl), [GR.jl](https://github.com/jheinen/GR.jl/) or [DataFrames.jl](https://github.com/JuliaData/DataFrames.jl), which have all 100+ open issues. And from my humble experience, issues get lost there very quickly if not resolved immediately. So I wonder if it’s possible to improve the process with some technical solution. It should be relatively straightforward to build an algorithm with UI, which group similar issues together, so one can process them in batches. The same similarity metrics could be used to match open issues with closed issues PRs, so we could try to predict, which of them are already closed, and which are out of date.

I’m working on a kinda similar project, so drafting this tool shouldn’t take long. Do you think that it would help? Or what is the bottleneck with issue management? I never maintained such big packages, only [few small repos](https://github.com/VPetukhov), so please be kind if I miss the big picture 🙂

P.S. Not sure if it should be in tooling, but don’t know where to put it otherwise.

---

<div class="post-metadata">

**Author:** ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)\
**Post date:** [March 1, 2021, 7:09pm UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/2 "2021-03-01T19:09:28Z")

</div>

Anyone can help with problems like this by going through old issues and trying to reproduce the bug (i.e., updating to the latest version of every package, potentially updating the code in the bug report to the latest syntax). If it’s reproducible, you can post the latest MWE. If its no longer reproducible, you can leave a comment asking that it be closed.

To pick a random example: [https://github.com/JuliaPlots/Plots.jl/issues/535#issuecomment-592936130](https://github.com/JuliaPlots/Plots.jl/issues/535#issuecomment-592936130)

---

<div class="post-metadata">

**Author:** ![sylvaticus](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sylvaticus/32/203883_2.png) [@sylvaticus](https://discourse.julialang.org/u/sylvaticus)\
**Post date:** [March 2, 2021, 12:01am UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/3 "2021-03-02T00:01:02Z")

</div>

Maybe. But I hate that projects where time to time you are bumped with 'Hei, we noticed that there hasn’t been any activity on this issue by a while. Isn’t the issue solved?" and if you forget to respond, you get a “Thank you, the issue is now closed” :-/

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [March 2, 2021, 12:06am UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/4 "2021-03-02T00:06:26Z")

</div>

If there really is a simple technical solution, I think it could be a huge help. Julia itself would also be a good source of examples since there are \>3k issues, many of which are surely stale or duplicates. But I wonder if it’s really so easy; if so, wouldn’t GitHub have done this?

---

<div class="post-metadata">

**Author:** ![ImreSamu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/imresamu/32/20677_2.png) [@ImreSamu](https://discourse.julialang.org/u/ImreSamu)\
**Post date:** [March 2, 2021, 12:40am UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/5 "2021-03-02T00:40:45Z")

</div>

> [@odow](#):
>
> Anyone can help with problems like this by going through old issues

imho: a reversed time order … is a good start :

- julia - open issues - ordered by: “Least recently updated”  
[https://github.com/JuliaLang/julia/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc](https://github.com/JuliaLang/julia/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc)
  - last updated on 2014y count =\> 5

---

<div class="post-metadata">

**Author:** ![tbeason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbeason/32/15898_2.png) [@tbeason](https://discourse.julialang.org/u/tbeason)\
**Post date:** [March 2, 2021, 2:05am UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/6 "2021-03-02T02:05:42Z")

</div>

I remember a thread not all that long ago where there was some discussion of a github bot that would ping owners of stale PRs. So I’d imagine a technical solution exists. I’d imagine issues fall much lower than PRs on the priority list though…

---

<div class="post-metadata">

**Author:** ![vpetukhov](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vpetukhov/32/12954_2.png) [@vpetukhov](https://discourse.julialang.org/u/vpetukhov)\
**Post date:** [March 8, 2021, 6:40pm UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/7 "2021-03-08T18:40:57Z")

</div>

Thanks everyone for the answers!

@odow , the whole point is how to make the process more scalable, as it seems that the process is not completely optimized.

@tbeason , yep, focusing on PRs makes total sense.

@tim.holy , there are many things, which GitHub haven’t done… Given limited free time, I should be able to have some draft in 1-2 weeks. Would you maybe be interested in checking it when ready? It would be terrific if you could say if it’s something you’d find useful for yourself.

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [March 8, 2021, 7:41pm UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/8 "2021-03-08T19:41:43Z")

</div>

I’ll be happy to take a look, but also let others give it a whirl—you’re more likely to get useful feedback that way.

---

<div class="post-metadata">

**Author:** ![affans](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/affans/32/11911_2.png) [@affans](https://discourse.julialang.org/u/affans)\
**Post date:** [March 8, 2021, 7:46pm UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/9 "2021-03-08T19:46:41Z")

</div>

I don’t think this is something that can be solved without human interaction. Either the maintainers spend a considerable amount of time trying to reproduce old issues or the owner has to do it by pinging and reminding them. I suppose some sort of BugFest will be needed.

---

<div class="post-metadata">

**Author:** ![cormullion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cormullion/32/49131_2.png) [@cormullion](https://discourse.julialang.org/u/cormullion)\
**Post date:** [March 8, 2021, 7:47pm UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/10 "2021-03-08T19:47:54Z")

</div>

I use the github “stale bot” - if an issue isn’t marked as a potential enhancement, it eventually gets closed. It’s useful because people often open issues but then “move on” (or lose interest), and the stale bot eventually comes along and jogs people’s memory to do something. Everyone get notified of imminent closure, and if nobody responds, the issue eventually gets closed. It can always be re-opened.

I find it works quite well, to keep things tidy. Open issues prey on the mind. 😂

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [March 9, 2021, 1:30am UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/11 "2021-03-09T01:30:18Z")

</div>

We use it also in the [General](https://github.com/JuliaRegistries/General) registry to automatically close pull requests that have been inactive for more than 30 days. Users can always resubmit the package/version at any time, after fixing the issues that prevented automerging, but at least we can keep the list of open pull requests shorter.

---

<div class="post-metadata">

**Author:** ![bilderbuchi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bilderbuchi/32/13562_2.png) [@bilderbuchi](https://discourse.julialang.org/u/bilderbuchi)\
**Post date:** [March 9, 2021, 9:36am UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/12 "2021-03-09T09:36:53Z")

</div>

As a user reporting bugs, I find “stale bots” quite frustrating.  
I spend time and effort composing a good bug report for a problem in some piece of software, and if I don’t hit one of the few packages where open-source maintainers are not swamped in backlogs, I _then_ have to leave meaningless “Up” comments **every N days** just so some machine does not mindlessly close the issue (with the problem still present!).

Personally, the Ubuntu bug tracker was the worst for me - I reported a sizeable number of bugs over the years, and I think all but a handful were closed “due to inactivity”, just because the maintainers don’t find the time to deal with it (or even triage it). At some point I just stopped bothering to report bugs…

Also, I wonder what this practice does to your rate of duplicate reports…

In my opinion (and experience managing an OSS issue tracker with a high three-digit number of open issues), a better strategy can be to:

- Set up a process to ensure that most/all incoming issues get triaged (labeled, closed as inappropriate, classified, assigned, milestoned,…)
- Dedicate time/resources to look at old issues, and reproduce or close. The github sort-by-least-recently-updated view already mentioned works well for this
- If possible, plan for an issue resolution timeline: label as needs-analysis for devs to look at, needs-info from reporter, assign a milestone target (could be next-minor, next-major, “future” 😉 ). This way you also know when your milestones are getting overfull.
- I think only issues that remain at “need-info” waiting for reporter feedback for a long period should be eligible for autoclosing, as this more reliably indicates “lost interest” by the reporter
- In the end, take a look at your project priorities. Maybe the project should spend more effort on maintenance/fixing bugs than on shiny new features. But of course, this is often hard to sell (unfortunately)

> [@cormullion](#):
>
> keep things tidy. Open issues prey on the mind. 😂

Let me ask a provocative question: If open issues prey on your mind, why are you bothering with a public issue tracker (or users)? Sure it feels better to have few open issues in your tracker, but if you achieved that by just autoclosing issues nobody finds the time for to fix, is that metric still meaningful?

> [@cormullion](#):
>
> It’s useful because people often open issues but then “move on”

If users report an issue, and the maintainers do not react, what remains for them other than “moving on”? What would you like them to do instead?  
Mind that many people don’t have the technical competence to fix bugs themselves, otherwise you’d probably have gotten a PR instead.

Finally, let me say that I definitely know how it feels to not have enough time/energy to fix all bugs in the projects I help maintain. This means that issues stay open (sometimes for years), and that I try to focus on fixing bugs, not adding new features, but does not mean I just close reports because I don’t find the time to resolve them.

---

<div class="post-metadata">

**Author:** ![cormullion](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cormullion/32/49131_2.png) [@cormullion](https://discourse.julialang.org/u/cormullion)\
**Post date:** [March 9, 2021, 10:23am UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/13 "2021-03-09T10:23:04Z")

</div>

> [@bilderbuchi](#):
>
> why are you bothering with a public issue tracker (or users)?

Good question. I shall ponder it.

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [March 9, 2021, 5:47pm UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/14 "2021-03-09T17:47:13Z")

</div>

In a few packages I keep the issue list short by fixing bugs and then the really hard ones get tagged in a way that reminds me why they aren’t fixed yet. I find that settles my unease at having open issues. Example: [https://github.com/timholy/Revise.jl/issues](https://github.com/timholy/Revise.jl/issues)

---

<div class="post-metadata">

**Author:** ![bkamins](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bkamins/32/208538_2.png) [@bkamins](https://discourse.julialang.org/u/bkamins)\
**Post date:** [March 9, 2021, 6:06pm UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/16 "2021-03-09T18:06:27Z")

</div>

> [@vpetukhov](#):
>
> issues get lost there very quickly if not resolved immediately

I can speak of DataFrames.jl. Issues are not lost there. They are classified and assigned priority. The only issue is that given a number of things to be added things that are not considered by core contributors as important do not get handled for very long period as other things are more pressing. In particular bugs are mostly fixed immediately, and what is left open are feature requests.

---

<div class="post-metadata">

**Author:** ![bkamins](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bkamins/32/208538_2.png) [@bkamins](https://discourse.julialang.org/u/bkamins)\
**Post date:** [March 9, 2021, 7:02pm UTC](https://discourse.julialang.org/t/would-it-help-to-have-a-tool-that-automatically-determines-which-issues-should-be-closed/56274/17 "2021-03-09T19:02:12Z")

</div>

Prompted by this thread I had thought to resolve an issue from 2014 😄.  
See  
[https://github.com/JuliaData/DataFrames.jl/issues/659](https://github.com/JuliaData/DataFrames.jl/issues/659)  
and  
[https://github.com/JuliaData/DataFrames.jl/pull/2649](https://github.com/JuliaData/DataFrames.jl/pull/2649)