I like that idea (and the list) as well. On Tue, Dec 6, 2022 at 1:59 PM Kerry Donny-Clark <kerr...@google.com> wrote:
> 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 >>>>>>>>> >>>>>>>>
