Stream: contributing

Topic: Cleaning up GitHub Labels

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

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.

Recommend deleting:

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 label
• invalid only used once, not sure what it would even mean, was a default github label
• P-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 once
• static-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.

Consider deleting

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?

Recommend adding/editing descriptions for:

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.
• There are also 18 other labels without descriptions. I like having descriptions for everything, but they're not causing confusion, so they're less important.

Consider new labels:

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"

Richard Feldman (Nov 24 2024 at 04:44):

wowww, thank you so much for doing this!!! :heart_eyes: :heart_eyes: :heart_eyes:

Richard Feldman (Nov 24 2024 at 04:45):

maybe the testing label could become roc test for clarity?

Richard Feldman (Nov 24 2024 at 04:45):

I think reporting could be merged into error-messages

Luke Boswell (Nov 24 2024 at 04:45):

I'm happy to update the labels, the reccomend ones look good. I dont know if they need much discussion.

Luke Boswell (Nov 24 2024 at 06:52):

What's the difference between reporting and error messages? I think I prefer error messages as that is clearer

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

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".

shua (Nov 25 2024 at 22:40):

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 26 2025 at 12:14 UTC