Noting that what you've listed are the options in the issue template, which are then expanded to multiple labels. So focusing on the issue template, I like the general idea, but maybe we can simplify it even more:
When a user is filing a bug, I think a good outcome is for it to get into the right person's saved search (like Go, Python, etc) while still having the "awaiting triage" label on it. What if we just went all the way simple and had checkboxes for just the highest level. Something like the following: Which language SDK or feature is related to your report? (check all that apply) [ ] Python [ ] Java [ ] Go [ ] Typescript [ ] IO connector [ ] Beam examples [ ] Beam playground [ ] Beam katas [ ] Website [ ] Spark Runner [ ] Flink Runner [ ] Samza Runner [ ] Twister2 Runner [ ] Hazelcast Jet Runner [ ] Google Cloud Dataflow Runner We could even trim it even further to just language, and let the person doing triage handle the rest. Kenn On Tue, Dec 6, 2022 at 9:11 AM Danny McCormick via dev <dev@beam.apache.org> wrote: > > Is it possible to not have a default option? > > Sadly, no AFAIK. I agree this would help. We could try things like making > the default " " and auto-closing issues that don't pick something other > than the default, that's a pretty rough experience though and not worth it > IMO. > > > I definitely think reducing the label zoo could help. > > What's our desired end state here? I put together a doc with my suggested > labels - > https://docs.google.com/document/d/1FpaFr_Sdg217ogd5oMDRX4uLIMSatKLF_if9CzLg9tM/edit?usp=sharing > - > listed below as well for convenience. Please comment in the doc if you have > thoughts/labels you care about, or continue the email thread if you have > bigger ideas (e.g. getting rid of labels, changing our templates entirely > instead, etc...). > > *Danny's Proposed Labels:* > > > - > > beam-community > - > > beam-playground > - > > community-metrics > - > > cross-language > - > > examples-java > - > > examples-python > - > > extensions > - > > infrastructure > - > > io-go > - > > io-ideas > - > > io-java > - > > io-py > - > > katas > - > > release > - > > run-inference > - > > runner > - > > runner-dataflow > - > > runner-direct > - > > runner-flink > - > > runner-samza > - > > runner-spark > - > > runner-universal > - > > sdk-go > - > > sdk-ideas > - > > sdk-java > - > > sdk-py > - > > sdk-typescript > - > > test-failures > - > > website > > > On Tue, Dec 6, 2022 at 11:17 AM Bjorn Pedersen <bjornpeder...@google.com> > wrote: > >> As someone still newer to Beam, I can attest that the number of labels >> can be overwhelming. >> >> Is it possible to not have a default option? Even just getting people to >> interact with the dropdown might go a long way, especially if the labels >> were fewer and clearer. >> >> Bjorn >> >> On Mon, Dec 5, 2022 at 6:46 PM Kenneth Knowles <k...@apache.org> wrote: >> >>> I definitely think reducing the label zoo could help. We have a lot of >>> labels that are decompositions of what used to be Jira components. >>> >>> Kenn >>> >>> On Mon, Dec 5, 2022 at 12:17 PM Danny McCormick via dev < >>> dev@beam.apache.org> wrote: >>> >>>> > Previously, we had automation that would automatically mark >>>> self-assigned self-reported issues as triaged. That is probably a third of >>>> issues or more. >>>> >>>> I believe that automation exists now[1], but it wasn't retroactively >>>> applied to old issues. >>>> >>>> > One issue is that a lot of triage work is getting the labels right (a >>>> lot of things end up in beam-model or beam-community) >>>> >>>> Do you think it would help to cut down on our label options? >>>> beam-community might be popular because it's the default option, so >>>> reducing options might not help that much unfortunately. >>>> >>>> [1] example - https://github.com/apache/beam/issues/24521 >>>> >>>> On Mon, Dec 5, 2022 at 2:57 PM Kenneth Knowles <k...@apache.org> wrote: >>>> >>>>> Previously, we had automation that would automatically mark >>>>> self-assigned self-reported issues as triaged. That is probably a third of >>>>> issues or more. I'm not sure what else. I appreciate Valentyn keeping an >>>>> eye on the Python label. One issue is that a lot of triage work is getting >>>>> the labels right (a lot of things end up in beam-model or beam-community) >>>>> >>>>> Kenn >>>>> >>>>> On Mon, Dec 5, 2022 at 6:23 AM Kerry Donny-Clark via dev < >>>>> dev@beam.apache.org> wrote: >>>>> >>>>>> This is a glorious achievement Kenn! To keep things clean going >>>>>> forward are there any improvements we can make in our issue creation >>>>>> flow? >>>>>> >>>>>> On Fri, Dec 2, 2022, 6:44 PM Kenneth Knowles <k...@apache.org> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I've finally done it! I've emptied the label "awaiting triage". Help >>>>>>> me keep it that way! This ensures that we actually at least *look* at >>>>>>> each >>>>>>> issue once, preferably soon after it is filed. The idea is that you make >>>>>>> sure the priority and other labels are right, since users are not >>>>>>> expected >>>>>>> to know how we use labels. >>>>>>> >>>>>>> >>>>>>> https://github.com/apache/beam/issues?q=is%3Aissue+is%3Aopen+label%3A%22awaiting+triage%22 >>>>>>> >>>>>>> Kenn >>>>>>> >>>>>>
