Stream: contributing

Topic: Cleaning up GitHub Issues

Sky Rose (Nov 01 2024 at 21:44):

I've been thinking about going through the GitHub issues and trying to close a bunch of them out. Most recently inspired by this idea to keep down the number of issues, but I've been tempted to do this for a while.

Here's my plan:

• Make sure open issues have a label for "bug", "enhancement", "question", etc.
• Close issues that are obviously out of date. Requests for features that are no longer relevant. Issues that weren't closed when their corresponding PR was merged. The 65 issues for the editor that are still open even though all the editor code was removed more than a year ago. etc.
• Link and close any duplicates I see.
• Anything that I close I'll leave a comment explaining why. I'll look at every issue.
• Update descriptions on the labels. Some of them should be marked as obsolete.
• Leave a comment here with my progress when I'm done

I'm hoping to spend a few hours on it this weekend, and close out a couple hundred issues. The issues will still be a mess when I'm done, but a little bit less of a mess.

Things I won't do:

• Look at PRs, since those will require more effort and context to evaluate.
• Close issues just based on time. We're not very on top of the issues, so just because an issue hasn't been touched in x months doesn't mean it's not relevant anymore. I'll give a reason for any closure.
• Aim for completeness. There's a lot of issues and I won't know enough to handle every one. My goal is to get as many done as possible with a reasonable amount of effort.
• Aim for perfection. It's possible I'll close out some bug reports that are still relevant. I think that clearing out noise to make existing issues easier to deal with will still be a net positive in Roc's ability to manage community contributions, even if I make errors.
• Try to reproduce bugs so that outdated bug reports can be removed. That'd add a ton of time and effort, I'd rather focus on viewing as many issues as possible.
• Contribute towards making any issues more actionable. Like asking for bug reproductions, tagging priority levels, etc. This is about removing the noise, not making progress on issues that still matter.
• Move any issues into discussions, as that recent idea suggested. Having fewer issues around will make that easier if we decide to do it in the future, but I'm not directly implementing that idea.
• (edited to add) Ask for attention or more details on old issues. I'm trying to reduce the backlog of work, and I specifically don't want to assign more work. Unfortunately this will unavoidably cause a bunch of GitHub notifications.

About me
I've been a long-time lurker in Zulip. I haven't made any code contributions (yet) but I think I can contribute better with this chore than I could by writing code. I'm not an expert, which will limit my ability to judge some issues, but I'm familiar enough with Roc's plans to clear out some of them.

Why do this:

• A little less noise in the issue tracker, and a less intimidating number of open issues.
• So that any future efforts by other maintainers to clean things out have a better starting point.
• (edited to add) The alternatives are perpetually ignoring old issues, waiting to do this later, or using a bot to close old issues, all of which seem worse.

Would this be a useful way to contribute? If so, here's what I need from core maintainers before I can start:

• GitHub permissions (my account is skyqrose) to:
  - Add labels to issues
  - Close issues
  - Edit label descriptions
• Your blessing to embark on this before I send people 1000 GitHub notifications.

Sam Mohr (Nov 01 2024 at 23:34):

This would be extremely helpful IMO! I don't think I'm the person with the launch codes for this operation, but if I did, I'd give the go ahead

Brendan Hansknecht (Nov 01 2024 at 23:51):

I'm a bit nervous of the idea, but I think it would be by far be more useful than problematic

Anton (Nov 02 2024 at 12:41):

@Sky Rose thanks for helping out :heart:
I've given you the triage role, unfortunately it does not allow for editing of label descriptions and github does not appear to support giving someone granular permissions. So feel free to tell me which label descriptions should be changed.

Anton (Nov 02 2024 at 12:42):

Your blessing to embark on this before I send people 1000 GitHub notifications.

Let's start slow so it's easy to give feedback on your approach :)

Sky Rose (Nov 03 2024 at 03:18):

In the spirit of starting slow, here's an update after my first small batch:

I went through 69 issues, numbered 6133-6328, which is all open issues from December 2023. (I started in the middle because I that seemed more helpful than starting at the newest or oldest issues.)

I closed 13 issues and brought the number of unlabeled issues down from 418 to 368. That's not the smashing success I was hoping for, but it's still something, and I'm planning to continue.

There were a lot of issues where all I could do was tag it as a bug and move on, but nearly every bug has a reproduction. I expect that a lot of those bugs have been fixed over time (intentionally or accidentally), and if I were checking if the reproductions still worked, then I could close a lot more issues. But that would slow things down quite a bit. I think I want to continue with the current approach, and then consider doing a second pass to check the reproductions.

Sam Mohr (Nov 03 2024 at 03:43):

Yeah, double checking reproductions should be fine for a second pass

Luke Boswell (Nov 03 2024 at 21:19):

Thanks for all the work on these issues Sky... looking good :+1:

Sky Rose (Nov 05 2024 at 03:13):

Update:

I just finished going through all of 2023 (341 issues).
I started at 1160 issues, and am now at 1128 issues, which is 32 issues closed. (+1 issue opened, -1 issue closed by someone else).
There were 418 unlabeled issues to start with, and now there are 277, 42 of which are issues from 2023 that I looked at and couldn't categorize.
I've spent 9 hours going through issues (plus some time getting set up).

I consider this to be going pretty well. I won't extrapolate to what the numbers will be like when I'm done, cuz the older stuff is gonna be so much different than what I've done so far. I'm thinking next time I work on this, I'll close the 65 editor issues for an easy win, and then skip 2022 (328 issues) and go to 2021 (203 issues).

Anton (Nov 05 2024 at 09:44):

I've spent 9 hours going through issues (plus some time getting set up).

Wow, thank you very much @Sky Rose!

Richard Feldman (Nov 05 2024 at 12:52):

yeah, that's amazing - thank you so much, @Sky Rose! :heart_eyes:

Sky Rose (Nov 24 2024 at 04:14):

I'm done! I've reviewed more than a thousand issues from February 2020 through July 2024. The number of issues is down from 1160 to 963 which is 197 or 17% of issues closed. And I've labeled and cross-linked a lot of the issues that are still open. I'm satisfied with this outcome.

There are a few followup tasks that could be done. In decreasing order of being a good use of time:

• (most worth the time/effort)
• [x] Did you know that the repo has a wiki? It's very out of date. If there's no plans to use it and keep it updated, I suggest disabling it in the github repo settings.
• [x] The list of labels is long and could also use some cleanup. I've written recommendations in a separate thread: #contributing > Cleaning up GitHub Labels.
• [ ] The good first issue and help wanted labels (80 open issues) had a bit of cruft in them that I didn't feel qualified to clean up. But those labels get a lot more eyes on them from people wanting to help, and some of the open issues with those tags could be misleading. They'd be worth a second pass from someone more experienced.
• [ ] The dev-backend label still needs more cleanup. There are 30 open issues, and I think most of them are done. But completing them requires checking that all number types are handled, which I tried, but couldn't be confident in, so I left them open. It'll have to be done by someone who's more familiar with writing dev backend implementations. Most of these are tagged good first issue, so it'd be particularly impactful to clean them up, and it should be quick for the right person.
• [ ] There are 45 open PRs, dating back to 2022, and they routinely get marked stale. There's a lot of effort and improvements wrapped up in those open PRs. Some could be merged, some could be revived, and some could be closed. It'd be a lot harder than going through open issues, but could have a bigger payoff.
• [ ] Lots of issues mentioned disabling tests. Some of those won't need to be disabled anymore, but have been forgotten. Someone could go through the repo and check all the commented out and disabled tests to see whether they can be reenabled or deleted. The payoff would be having more test coverage and less dead code.
• (I recommend doing things above this line, and don't recommend doing things below this line.)
• [ ] There were plenty of issues that seemed simple that didn't have a good first issue label. If you're looking to pad out the list of good first issues to give new contributors more options, you could look for issues to give the good first issue tag. But I didn't label them, so you'd have to search for them.
• [ ] A lot of old bugs have probably been fixed or disappeared in the last few years, and nearly every bug has a reproduction included. I didn't try to reproduce them. If someone methodically checked every reproduction posted in old issues with the bug label (408 open), I bet you could close a hundred more issues.
• [ ] There were plenty of other issues that I couldn't resolve but someone with more context might be able to. You could do another pass of the whole thing. It took me 1-2 minutes per issue on average (some were quick, some I gave deeper investigations). Only do this if you decide clearing the issue backlog is a priority, or if you want to better understand the backlog of potential work in order to help with planning.
• (least worth the time/effort)

None of these are particularly urgent, they're just cleanup chores, and I know there's a ton of more urgent stuff going on with purity inference being released and AoC. Let me know if you want me to make issues for any of these or bring it up again at a less busy time.

Now the fun stats:

Isaac Van Doren (Dec 01 2024 at 03:35):

I'm happy to try the reproductions on some bugs, but not going to commit to all 400 :sweat_smile:. I'll start with the oldest first and leave a comment explaining why the issue can be closed or should be kept open if I check it. There are some (compiler internals) that I don't have enough context on to be able to tell if they are still relevant so I'll leave them alone. Let me know if you have any concerns with this approach.

Luke Boswell (Dec 01 2024 at 04:17):

This is ideal. We all chip away at it and we'll get there. Little steps :baby_chick:

Last updated: Jul 26 2025 at 12:14 UTC