I just finished #contributing > Cleaning up GitHub Issues , and based on that, I have some recommendations on ways to clean up the labels in GitHub. The list of labels is pretty long, so cleaning it up could make easier to navigate the list, see more useful labels, and keep things tagged consistently. The triage role doesn't give me permission to edit labels in the repo, so this would fall on someone who does have that permission.
These ones are pretty useless, just taking up space.
cli-platform
unused, and cli-platform isn't in the roc
repo.duplicate
unused, was a default github labelinvalid
only used once, not sure what it would even mean, was a default github labelP-evolution
used on 3 closed issues, all of which already have P-high
.perf-editor
Editor is defunct. Used on 3 closed issues, all of which have the editor
label.plugin
Editor is defunct. Used on 2 closed issues, both of which have the editor
label.planned
only used twice. There is lots of planned work but we're not using this to label it.polymorphic-expressions
Only used once. Too specific for a label.software-design
Only used oncestatic-site-gen
unused, and it's not in this repo.WIP
Used 7 times, all closed. Can be represented by GitHub's draft PRs instead.wontfix
unused, was a default github label.Not quite as slam dunk to delete, but if you want to get more aggressive in shortening the list of labels, these would be good candidates.
nightly
only used twice. Lots of issues mention nightly releases though. Should we be using this category?codegen-with-errors
Only used 3 times, pretty specific, all issues could use code gen
instead.N-SSCCE
and N-verification
. Lightly used, hard to keep up to date. Are they actually useful as part of the bug triaging process?roc_std
Only used twice. Is there a bigger category to put them in instead? Maybe the platforms
label I suggest below?Better descriptions would make it more likely that labels are used consistently.
editor
: Should be marked as historical. "(no longer used) The Roc editor"public
: Should be marked as hsitorical. "(no longer used) related to the repo going public"miscompilation
: No description. Rarely used, probably because it's unclear what belongs in this category. Should it be deleted and just use bug instead?reporting
: No description. Not obvious what it's for just from the name, so needs a description. What's the difference between this and error-messages
?testing
: A description could make it clear that this is about roc test
, not about testing the compiler. It would also be good to describe why this is different than expect
.I saw a lot of issues related to these topics. New labels for them could be helpful:
closures
: "Lambda sets and closure captures"platforms
: "Issues with defining and calling platforms"memory managment
: "Reference counting and allocation in roc programs"wowww, thank you so much for doing this!!! :heart_eyes: :heart_eyes: :heart_eyes:
maybe the testing
label could become roc test
for clarity?
I think reporting
could be merged into error-messages
I'm happy to update the labels, the reccomend ones look good. I dont know if they need much discussion.
What's the difference between reporting and error messages? I think I prefer error messages
as that is clearer
In theory I like merging error-messages and reporting, but GitHub doesn't have a way to merge labels. Deleting a label irreversibly removes the label from all its issues. You'd have to go through every issue with one of the labels to tag them with the other label, before deleting it.
reporting
has 33 open issues and PRs and 24 closed. So it wouldn't be too hard to change them all manually. (error-messages
has 80 open and 15 closed.)
If you didn't want to change them manually, this would be silly, but you could rename reporting
to like error-messages-2
"Also error messages, here for historical reasons".
There's a gh cli tool you can use locally to make listing and relabeling issues slightly less manual: https://cli.github.com/manual/gh_issue .
here's an example to list first 50 issues with "reporting" label, and generate commands for each one to add the "error-messages" label
gh issue list -R roc-lang/roc -L 50 -l reporting | cut -f1 | sed 's/.*/gh issue edit & -R roc-lang\/roc --add-label "error-messages"/' >relabel.sh
then check relabel.sh
, and run it if it looks right. I like to split up the generate/run steps because it's too easy for this kind of thing to turn into "oops, I relabelled all 9000+ issues"
Last updated: Jul 06 2025 at 12:14 UTC