I really like the idea of multi-select and automatic "awaiting triage". Kenn, I think the list you have looks good to me.
On Tue, Dec 6, 2022 at 1:55 PM Kenneth Knowles <k...@apache.org> wrote: > 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 >>>>>>>> >>>>>>>
