+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 <dev@beam.apache.org>
wrote:

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

Reply via email to