+1 sounds good to me One thing I did a lot of when triaging Jiras was moving them from one component to another, after which people who cared about those components would go through them. Making the labels more straightforward for users would streamline that.
Kenn On Sun, Jun 12, 2022 at 9:04 PM Chamikara Jayalath <[email protected]> wrote: > +1 for this in general. Also, as noted in the proposal, decomposing > labels should be done on a case by case basis since in some cases that > might result in creating labels that do not have proper context. > > Thanks, > Cham > > On Fri, Jun 10, 2022 at 8:35 AM Robert Burke <[email protected]> wrote: > >> +1. I like this consolidation proposal, but i also like thinking through >> conjunctions. :) >> >> On Fri, Jun 10, 2022, 6:42 AM Danny McCormick <[email protected]> >> wrote: >> >>> Hey everyone, >>> >>> After migrating over from Jira, our labels are somewhat messy and not as >>> helpful as they could be. Specifically, there are 2 sets of problems: >>> >>> >>> 1. There is significant overlap between the labels imported from Jira >>> and the labels we already had in GitHub for our PRs. For example, there was >>> already a “Go” GitHub label, and as part of the migration we imported a >>> “sdk-go” label. >>> >>> >>> 2. Because GitHub doesn’t provide an OR syntax in its searching, it is >>> much harder to search for things like “all io labels” because the io issues >>> are sharded across a number of io tags (e.g. io-java-aws, io-java-amqp, >>> io-py-avro, etc…). This applies to other areas like runner issues, >>> portability issues, and issues by language as well. >>> >>> I put together a quick 1 page proposal on how we can remove the label >>> duplication and make searching easier by decomposing our labels into their >>> smallest components. Please let me know if you have any thoughts or >>> suggestions! >>> https://docs.google.com/document/d/14S5coM_vfRrwygoQ9_NClJWmY5s30_L_J5yCurLW-XU/edit?usp=sharing >>> >>> Thanks, >>> Danny >>> >>
