> 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 >>>>>> >>>>>
