Meta: Refine labels for Issues/PRs

[dangotbanned]

What is your suggestion?

Pulling out a discussion on a merged PR (#3539), for visibility.

Discussion w/ @joelostblom

Just a note if you wonder why I added an additional label to this PR @dangotbanned . We try to always have one of the labels listed here on each PR: https://github.com/vega/altair/blob/main/.github/release.yml. GitHub then organize each PR into its corresponding section of the release notes automatically when creating the release via GitHub's interface. I don't have a strong opinion about labels not listed there, so feel free to add more to that list if there are some additional labels/sections you think would be useful.

I looked into automating the addition of a label to each PR via a GitHub action based on the conventional commit type mentioned in the PR title, but there was no such action so I just check through the closed PRs every now and then and label the ones that are missing one of the four labels our release notes are based on.

Originally posted by @joelostblom in #3539 (comment)

No worries @joelostblom
I won't be able to test right now, but main/.github/release.yml looks like you can map multiple labels to each title?

E.g. this had the dependencies label, which could fall under maintenance.

If that can work, I think that would be worth doing as there are other labels that wouldnt be picked up currently

Originally posted by @dangotbanned in #3539 (comment)

Yup, we can map additional labels just like you said. Another option would be to remove the labels we haven't used much in the past like dependencies and usability. I don't really have a preference since I mostly use the four other labels, but if you believe that these additional labels are useful, then I'm happy for them to be added.

Originally posted by @joelostblom in #3539 (comment)

Current labels

Labels in bold have a group in release notes.
I've added the position the group appears in https://github.com/vega/altair/blob/main/.github/release.yml

• bug (2)
• dependencies
• documentation (4)
• duplicate
• enhancement (1)
• good first issue
• help wanted
• maintenance (3)
• needs-info
• question
• usability
• v6
• vega-lite-related

---

Other projects

I may add to this later, but using polars as an example since they seem to have the CI workflow that @joelostblom was interested in

polars

Result

• https://github.com/pola-rs/polars/releases

Config

• https://github.com/pola-rs/polars/blob/main/.github/release-drafter-python.yml
• https://github.com/pola-rs/polars/blob/main/.github/workflows/pr-labeler.yml
• https://github.com/pola-rs/polars/blob/main/.github/workflows/release-drafter.yml
• https://github.com/pola-rs/polars/blob/main/.github/pr-title-checker-config.json

Edit

I linked the wrong release-drafter.
This one has the autolabeler @joelostblom mentioned

• https://github.com/pola-rs/polars/blob/main/.github/release-drafter.yml

[dangotbanned]

@joelostblom two labels I think could be helpful relating to #3548 (reply in thread)

New labels

breaking

To signal a PR will require a MAJOR version bump

deprecation

To signal a PR will require a MINOR version bump.
This won't be the only reason for a MINOR version, but it is the most obvious.
Also, it is likely something we'd want displayed in its own category in the release notes.

Examples

I think https://github.com/pola-rs/polars/releases/tag/py-1.0.0 is a good pattern to follow, in terms of prioritising the order of these new labels in release notes.

Although I've been doing some work lately on performance improvements in #3547, I don't think we need a category for it like polars.
It is certainly nice to have, but performance is a much higher priority for them than altair.

[joelostblom]

I linked the wrong release-drafter. This one has the autolabeler

Thanks for updating that, I was confused initially when looking for the labeling part. I think including this autolabeler CI would be convenient so I'm +1 there.

I also agree with you that adding the breaking and deprecation labels to the bolded ones in your first comment would be helpful. Displaying them on top of the release notes like in the polars release notes makes sense to me too.

[dangotbanned]

I've just added the new breaking, deprecation labels.

@joelostblom am I understanding this correctly, that we just need to add a category for each of these before - title: Enhancements?

altair/.github/release.yml

Lines 1 to 5 in 712680b

	changelog:
	categories:
	- title: Enhancements
	labels:
	- enhancement

[dangotbanned]

Was thinking about this as a new label for:

• feat: Adds ThemeConfig (TypedDict) #3536 (comment)
• Consolidate: alt.theme(s), alt.typing.theme, alt.vegalite.v5.theme, alt.utils.theme #3610

blocking

This wouldn't appear as a category in the release notes, but I think would be helpful when coordinating a new release.
When someone opens as discussion like #3478 they could clearly see issues/PRs that must be resolved prior to the next release

[joelostblom]

Yup, that should be all that is needed. You can see a few more options and examples in the GitHub docs in case it's helpful.

[dangotbanned]

Yup, that should be all that is needed. You can see a few more options and examples in the GitHub docs in case it's helpful.

Thanks, I'll try to take a look soon