search

MeltanoLabs / Meta

The why, what, and how of MeltanoLabs
MIT License
5 stars 1 forks source link

guild-se: Label Strategy #43

Closed kgpayne closed 1 year ago

kgpayne commented 1 year ago

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:

WillDaSilva commented 1 year ago

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

kgpayne commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

Related:

kgpayne commented 1 year ago

Closed in favour of https://github.com/meltano/.github/issues/12