Merged it. Please be on the lookout for bugs I have introduced, since they could result in issues slipping through the cracks.
On Wed, Dec 7, 2022 at 3:31 PM Kenneth Knowles <[email protected]> wrote: > OK I did my best in https://github.com/apache/beam/pull/24585 > > Yet another thought I had: Do we really need multiple templates? Do people > like the tags in the titles? After creation all these things are "just > labels" so there's no particular reason we need to conceptualize issues > as partitioned into these classes, unless it is helpful. > > Kenn > > On Tue, Dec 6, 2022 at 12:28 PM Robert Burke <[email protected]> wrote: > >> +1 to letting conjunctions form naturally. >> >> In the bikeshedding discusion: >> >> That would mean I'm biased to having the reduced label set to have >> reduced colours for the general category. >> >> Eg. SDK colour, Runner colour, beam resources colour, and IO being it's >> own special unique colour, and awaiting triage being unique as well. >> >> This would make triage checking a bit more glancible, since except for >> very particular issues that might warrant "several SDKs" or "several >> runners". >> >> On Tue, Dec 6, 2022, 11:13 AM Danny McCormick via dev < >> [email protected]> wrote: >> >>> I like that idea (and the list) as well. >>> >>> On Tue, Dec 6, 2022 at 1:59 PM Kerry Donny-Clark <[email protected]> >>> 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 <[email protected]> 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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> 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 < >>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>> 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 < >>>>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>
