[Meta] More structured issue labels

[mahesh-hegde]

For example, many repos in CNCF / K8S ecosystem do this: https://github.com/kubernetes/kubernetes/issues

area: [area/language-feature, area/configuration, area/jni, area/summarizer, area/tools, area/tests] kind: [kind/bug, kind/enhancement, kind/discussion, kind/cleanup, kind/documentation] priority: [priority/urgent, priority/medium, priority/low] size: [size/small, size/medium, size/large] milestone: [milestone/v0.5 etc..] uncategorized: [help-wanted, good-first-issue]

cc: @dcharkes @mit-mit

[dcharkes]

I think this is more of a @HosseinYousefi meta issue, as he is the one organizing the issues. (e.g. in https://github.com/orgs/dart-lang/projects/69)

[HosseinYousefi]

The only thing is that we're not such a huge project with many issues. So not having slashes also will work. area/language-feature can be either java or kotlin. area/configuration can be config. I personally put the sizes and the priorities in the project. This way those can be in separate columns.

I think milestones can also be separate columns instead of labels in the project. Old milestones accumulate and we don't really need that.

So I suggest keeping the label only for area and kind (and misc). Every once in a while, we can go through the new issues in the project is add the size, priority and milestone.

Some more thoughts:

• Milestones can actually be milestones as we have those!
• I feel like enhancement is a weird label, since everything is – after all – an ✨ enhancement ✨
• Labels like feature request make more sense.
• If we have 1000+ issues then having a more rigorous naming strategy can help a lot.

[mahesh-hegde]

If we have 1000+ issues then having a more rigorous naming strategy can help a lot.

I believe it's not only about scale but also about strict categorization. Unless it's a very cross-cutting concern, you will know you have to label it under one kind/ and one feature/.

This also makes it easier to a) search and b) find appropriate labels when creating issue.

So I suggest keeping the label only for area and kind (and misc). Every once in a while, we can go through the new issues in the project is add the size, priority and milestone.

Sounds good to me.

I feel like enhancement is a weird label, since everything is – after all – an ✨ enhancement ✨

This seems to be just a common conventional label across GitHub, probably in an enhancement vs bugfix sense. Let's use kind/feature instead.

[HosseinYousefi]

SGTM! Please let me know your suggested kind- and area- labels and I'll apply them.

[mahesh-hegde]

Borrowing a few from K8S repo

kind: [feature, bug, documentation, discussion, support]

area: [java-feature, kotlin-feature, summarizer, configuration, code-generator, jni]

I don't expect this to be exhaustive or mutually exclusive at this point, but the goal is to converge on such a set of labels.

Open questions:

• Naming: jni vs support-library vs runtime
• Should documentation be area or kind?

[HosseinYousefi]

Naming: jni vs support-library vs runtime

jni

Should documentation be area or kind?

kind

[mahesh-hegde]

SGTM!

[mahesh-hegde]

Maybe: area += [build-system] (Build system or related tooling)] kind += [refactoring-and-testing or tidy-up] (Improve codebase)

[HosseinYousefi]

I'll separate refactor and test kinds. I'll add the area. Maybe also an area-meta for this very issue!