Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta: Refine labels for Issues/PRs #3542

Open
dangotbanned opened this issue Aug 17, 2024 · 2 comments
Open

Meta: Refine labels for Issues/PRs #3542

dangotbanned opened this issue Aug 17, 2024 · 2 comments

Comments

@dangotbanned
Copy link
Member

dangotbanned commented Aug 17, 2024

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

Config

Edit

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

@dangotbanned
Copy link
Member Author

@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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants