Label suggestions

[mfisher87]

I think we can make our labels a bit more clear by making them multi-part with a delimiter (: or /). Many other projects do this, e.g. matplotlib. I don't have other great examples off the top of my head. What other projects are absolutely rocking the labels?

To start with, I propose:

• https://github.com/nsidc/earthaccess/labels/automation -> impact/automation
• https://github.com/nsidc/earthaccess/labels/bug -> type/bug
• https://github.com/nsidc/earthaccess/labels/dependencies -> impact/dependencies
• https://github.com/nsidc/earthaccess/labels/documentation -> impact/documentation
• https://github.com/nsidc/earthaccess/labels/duplicate -> type/duplicate
• https://github.com/nsidc/earthaccess/labels/enhancement -> type/enhancement
• https://github.com/nsidc/earthaccess/labels/feedback%20requested -> needs/feedback
• https://github.com/nsidc/earthaccess/labels/github_actions -> remove, we have the impact/automation label for this
• good first issue Good for newcomers -> keep as-is, this is a special label we want to optimize for searchability
• https://github.com/nsidc/earthaccess/labels/hackathon -> ?
• https://github.com/nsidc/earthaccess/labels/help%20wanted -> needs/help
• https://github.com/nsidc/earthaccess/labels/invalid -> remove? unused.
• https://github.com/nsidc/earthaccess/labels/python -> remove? unused. or: impact/library. Or impact/core in preparation for a future impact/plugin label.
• https://github.com/nsidc/earthaccess/labels/question -> remove? Should use GitHub discussions?
• https://github.com/nsidc/earthaccess/labels/wontfix -> type/will-not-do (using a contraction in a label without spacing is really hard to read even as a native English speaker - we can be more inclusive :) )

#281 offers us a mechanism to automatically apply these labels as issues are created. It also offers a mechanism to remove or avoid some labels by directing users away from Issues and towards a more appropriate place, e.g. type/feature-request need not exist as a "request" should (IMO :) ) start in Discussions and only become an issue once we agree it is a feature we will implement. Same for type/question.

I also propose colorizing the items based on the group they're in!

[asteiker]

@mfisher87 I took an initial stab at this:

• After looking at the matlab example I was actually keen to use a : instead of / as the delimiter, as a slash could imply either/or. This seemed more intuitive to me.
• I updated colors to be mostly consistent per grouping, but I'm not set anything if we want to change the color schemes. I did keep type: bug as red to highlight bugs specifically but I can change this if it's confusing.
• For all labels you suggested to remove I made sure to check on existing issues. For the github_actions label in particular, I went ahead and deleted, but I wasn't sure if dependabot was adding this automatically or not (see Bump the gha-dependencies group with 2 updates #885 as an example).
• I deleted hackathon and added needs: help if it didn't already exist. It feels like we can use needs: help to identify issues that are good candidates to work at a hackday.

I still need to go through type: question. We have 8 open issues so I wanted to dig into those more before simply converting those to discussions or doing anything else with that one.

[mfisher87]

Amazing work! I love how organized the labels page feels now 🤩

After looking at the matlab example I was actually keen to use a : instead of / as the delimiter, as a slash could imply either/or. This seemed more intuitive to me.

Makes sense to me too!

• I updated colors to be mostly consistent per grouping, but I'm not set anything if we want to change the color schemes.

Not sure I understand the bold part. My main thought on the colors is that the "impact" category color is too close to the "good first issue" color, which I think should keep its default color for recognizability.

I deleted hackathon and added needs: help if it didn't already exist. It feels like we can use needs: help to identify issues that are good candidates to work at a hackday.

Reasonable! We hadn't developed a pattern of using that label in the actual hackathons so it wasn't really serving its purpose.

[asteiker]

I missed a word above, no wonder that didn't make sense!

I'm not set on anything if we want to change the color schemes.

I thought the same thing on the colors being too close together on those categories - I'll update now.

[mfisher87]

Oh, of course! How did I miss that 😆 Thanks, Amy!

[asteiker]

I reviewed all issues with the question label and either converted to discussion or updated the label to needs: feedback depending on the context. I think this is good to close out unless you see anything else we're missing here @mfisher87 !

[mfisher87]

Awesome work! I think we're good to call this "complete" as well. 🤩