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

guild-se: Label Strategy #43

Closed
kgpayne opened this issue May 2, 2023 · 7 comments
Closed

guild-se: Label Strategy #43

kgpayne opened this issue May 2, 2023 · 7 comments

Comments

@kgpayne
Copy link

kgpayne commented May 2, 2023

Inspired by the labels specified as Meltano Area Labels in the Handbook, it would be helpful to come up with a set of issue categories to create as labels and apply to issues in the Singer Ecosystem.

The areas that come to mind are:

  • Configuration
  • Performance Improvement
  • REST/Graph/SQL/Soap (Stream Subclass Types)
  • Meltano Cloud
  • SDK Migration
  • SDK Feature Candidate (for features pioneered in Taps/Targets to inform a generic SDK implementation)
@WillDaSilva
Copy link

@kgpayne it may make sense to transfer this issue to https://github.com/meltano/.github

@kgpayne
Copy link
Author

kgpayne commented May 2, 2023

@WillDaSilva I did see your updates to the label-sync tool there, but this is specifically for choosing labels for use by the Singer-Ecosystem guild to track SDK and MeltanoLabs/* work.

As for actually applying labels, I suspect we will want to create labels in both meltano/sdk and in all repos in the MeltanoLabs org. Would be cool to manage sets of "label groups", so we can 'inherit' a base set of labels (e.g. for urgency or generic categories like bugs, docs and blogs/content) and also apply domain-specific ones. I didn't see a capability like that in label-sync, and figured it may be something for pulumi in future (as we also want to programatically manage other repo settings such as permissions, branch protection etc. in the MeltanoLabs org).

Do you think it makes sense to try and manage all labels centrally, or should the guilds be responsible for labelling alongside other git automations in their specific domains?

@WillDaSilva
Copy link

CC @tayloramurphy

Do you think it makes sense to try and manage all labels centrally, or should the guilds be responsible for labelling alongside other git automations in their specific domains?

@kgpayne I think it makes sense to centrally manage labels, provided anyone can submit PRs to update the central config.

For now it can be done with the label sync tool. In the future it'd be nice if we could use Pulumi for that.

https://github.com/meltano/.github syncs labels for both the meltano and MeltanoLabs GitHub orgs.

@kgpayne
Copy link
Author

kgpayne commented May 2, 2023

@WillDaSilva my assumption is that we likely don't want to apply all labels to all repos, to avoid bleeding label meaning across domain boundaries. The singer-ecosystem labels won't make sense in the meltano/* org except in the meltano/sdk repo, and vice versa, yet by creating them in those repos we can't stop them being applied (by us, the community or future engineers).

If we don't already have the ability to manage groups of scoped labels separately from a global list, I'd be inclined to hold off on applying domain specific labels until we can.

Alternatively, we can add prefixes to labels to denote domain. This could get messy though as we already have a mix of delimiters in use 😬 / and ::

@WillDaSilva
Copy link

we likely don't want to apply all labels to all repos, to avoid bleeding label meaning across domain boundaries.

@kgpayne It would be simple to update https://github.com/meltano/.github/blob/51c16bd08b33c745ba9d559c6893e889fb7b97ca/labels.yaml to only apply certain labels to certain groups of repositories, along with a base set of labels. The label sync tool only works on one repository at a time, and the logic to apply the labels from a central config is custom - see https://github.com/meltano/.github/blob/51c16bd08b33c745ba9d559c6893e889fb7b97ca/.github/actions/sync_labels/index.js

If you would like this feature, I'd ask that you open an issue in https://github.com/meltano/.github for it.

Alternatively, we can add prefixes to labels to denote domain. This could get messy though as we already have a mix of delimiters in use 😬 / and ::

We should decide on a canonical delimiter to be used in the actual labels, but that's as easy as deciding and then doing a find-and-replace on the central config file. When it comes to pre-existing labels, the label sync action considers / and :: equivalent: https://github.com/meltano/.github/blob/51c16bd08b33c745ba9d559c6893e889fb7b97ca/.github/actions/sync_labels/index.js#L52-L53

To get back to my original comment here: since this is a GitHub ops issue that has a larger impact that just MeltanoLabs repositories, I think it would be best if it were transferred to https://github.com/meltano/.github

@WillDaSilva
Copy link

Related:

@kgpayne
Copy link
Author

kgpayne commented May 2, 2023

Closed in favour of meltano/.github#12

@kgpayne kgpayne closed this as completed May 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants