Proposed RFC Suggestion: Guidelines for duplicating O3DE main repo labels in other repos

[hultonha]

Summary

I would like to solidify guidelines on copying existing labels from the main O3DE repository to other repositories under the O3DE organization when they would be useful there too.

What is the motivation for this suggestion?

Right now creating new labels (at least for the main O3DE repo) requires TSC approval. The restrictions around other repositories (for example o3de-extras) however are not as clear.

As more Gems/Projects move to separate repositories and sigs would like to group related issues, keeping consistent labels would be incredibly useful. Streamlining this process would be very helpful and make maintaining issues across multiple repositories (using GitHub Project Boards for example) much simpler.

Suggestion design description:

Make it clear if a label exists in the main O3DE repo (188 as of 2023/02/06), it can be duplicated (matching the label name, description and color of the original) without the need for approval.

This guidance would only apply to existing labels. If a new label needs to be added, it would then need to be brought to the TSC with a justification and then approved in one of the TSC meetings when there are enough members present to vote on the proposal.

What are the advantages of the suggestion?

• Streamline organizing repositories and make filtering issues faster and more efficient (especially for sig triage meetings).

What are the disadvantages of the suggestion?

• It is possible that some 'mutations' creep in (slightly different labels/colors) but hopefully we can monitor this and use the o3de repository as the source of truth and edit/update invalid labels when encountered.

How will this work within the O3DE project?

• Maintainers will be empowered to add new labels to their repositories so long as that label has 'precedent' in the O3DE main repository.

Are there any alternatives to this suggestion?

• Require a process heavy means of adding labels that must be individually approved.

What is the strategy for adoption?

• Announce this and make sure it is clearly communicated on the community repository that maintainers should feel able to do this.

[moraaar]

Makes sense to me. Thanks for bringing this forward @hultonha.

Question:
Is this supposed to apply to ANY label? Maybe it's worth thinking which group of labels would be useful to have this, we may discover that only the 'feature/', 'priority/', 'sig/*' labels are the only relevant ones... But if this makes the process more complex it might not be worth doing any specialization like that.

[sptramer]

👍 for the proposal, and I think that @moraaar's comment is addressed by the idea that any SIG can use these labels. For example, in sig-docs-community, pretty much any label related to some aspect of 'software' isn't relevant, but it could be for Gems packaged in o3de-extras. If owners get to pick and choose from an "approved" list (plus any others they need as determined, which won't go to o3de) then this provides at minimum a really good starting point.

[hultonha]

No problem @moraaar

My feeling is yes, this does apply to any label (if it's good enough for o3de/o3de, it's good enough for me 😅) I think this is the simplest thing to start with. It is fine to copy labels that are useful and make sense (e.g. certain features and priority labels) but we don't need to copy labels just for the sake of it. It's easy to do, it would just be good to know we're not violating a particular policy when we do.

Thanks @sptramer for your support! I agree wholeheartedly with your sentiment - only use the labels that make sense for you. Thanks!

[lgleim]

Thanks @hultonha for starting this RFC! IMHO streamline organizing repositories and make filtering issues faster and more efficient is an important issue as the number of repositories under the O3DE organization continues to grow. Guidelines on label management will certainly help to avoid diverging governance processes.

@moraaar @sptramer @hultonha One potential route of implementation could also be to turn a subset of core O3DE labels into organization-wide default labels but that of course raised the question which that would be.

[hultonha]

No problem @lgleim, thanks for the feedback so far!

100% agree which is why I think making it clear existing labels are okay to use/steal is totally fine and encouraged to make sorting/filtering easier.

I wasn't aware of default labels, if we can promote some to there that could definitely be a start to solving this problem and remove duplication (tagging @amzn-changml for visibility who might be able to know about the permissions side of this).

We could come up with a short list of labels here that we can all agree would be useful. Likely priority/* and kind/* would be good, feature/... might make more sense to be on a case by case basis. Thanks!

[chanmosq]

Agree with this RFC!

[amzn-changml]

Yes, I did propose using the org default labels in this discussion as well: o3de/sig-release#79 (comment). I have the permissions to put this in.

We can discuss what we want to use as a start. So far what has been proposed has been:

1. needs/triage
2. triage/accepted
3. kind/roadmap

[hultonha]

Yes, I did propose using the org default labels in this discussion as well: o3de/sig-release#79 (comment). I have the permissions to put this in.

We can discuss what we want to use as a start. So far what has been proposed has been:

1. `needs/triage`
2. `triage/accepted`
3. `kind/roadmap`

This sounds great @amzn-changml, I'd also propose we add relevant existing features (and/or make it clear those feature labels are fine to migrate if they already exist). It would be great if the community could self-serve on a number of these (those with permissions) to add useful labels that have already been approved by sig-release and the TSC. Thanks!

[hultonha]

I'd definitely add

kind/* <all kinds>
priority/* <all priorities>
needs-* <all needs>