You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Kenneth Knowles <ke...@apache.org> on 2022/12/02 23:44:08 UTC
Achievement unlocked: fully triaged
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
Re: Achievement unlocked: fully triaged
Posted by Robert Burke <ro...@frantil.com>.
I do a regular look at the go label myself. Partly because that's the best
way to learn what to fix next.
On Mon, Dec 5, 2022, 11:57 AM Kenneth Knowles <ke...@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 <ke...@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
>>>
>>
Re: Achievement unlocked: fully triaged
Posted by Moritz Mack <mm...@talend.com>.
Great, I really like the new simplified flow! Thanks for that!
On 08.12.22, 19:48, "Kenneth Knowles" <ke...@apache.org> wrote:
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 <kenn@ apache. org> wrote: OK I did my best in https: //github. com/apache/beam/pull/24585Yet
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 <ke...@apache.org>> wrote:
OK I did my best in https://github.com/apache/beam/pull/24585<https://urldefense.com/v3/__https:/github.com/apache/beam/pull/24585__;!!CiXD_PY!Siz_0ENa4zDO3jTcN-IP8o24q1DZ9lVhf26aoAoGMcwJ2T2JKxxdN_S_y-tzzKVzYul6Z6_FUg$>
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 <ro...@frantil.com>> 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 <de...@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 <ke...@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 <ke...@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 <de...@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<https://urldefense.com/v3/__https:/docs.google.com/document/d/1FpaFr_Sdg217ogd5oMDRX4uLIMSatKLF_if9CzLg9tM/edit?usp=sharing__;!!CiXD_PY!Siz_0ENa4zDO3jTcN-IP8o24q1DZ9lVhf26aoAoGMcwJ2T2JKxxdN_S_y-tzzKVzYumtjGTF4A$> - 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 <bj...@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 <ke...@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 <de...@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<https://urldefense.com/v3/__https:/github.com/apache/beam/issues/24521__;!!CiXD_PY!Siz_0ENa4zDO3jTcN-IP8o24q1DZ9lVhf26aoAoGMcwJ2T2JKxxdN_S_y-tzzKVzYulB8OMp6w$>
On Mon, Dec 5, 2022 at 2:57 PM Kenneth Knowles <ke...@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 <de...@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 <ke...@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<https://urldefense.com/v3/__https:/github.com/apache/beam/issues?q=is*3Aissue*is*3Aopen*label*3A*22awaiting*triage*22__;JSslKyUlKyU!!CiXD_PY!Siz_0ENa4zDO3jTcN-IP8o24q1DZ9lVhf26aoAoGMcwJ2T2JKxxdN_S_y-tzzKVzYukioAtCnw$>
Kenn
As a recipient of an email from Talend, your contact personal data will be on our systems. Please see our privacy notice. <https://www.talend.com/privacy/>
Re: Achievement unlocked: fully triaged
Posted by Kenneth Knowles <ke...@apache.org>.
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 <ke...@apache.org> 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 <ro...@frantil.com> 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 <
>> 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 <ke...@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 <ke...@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 <
>>>>>> bjornpedersen@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 <ke...@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 <ke...@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 <ke...@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
>>>>>>>>>>>>
>>>>>>>>>>>
Re: Achievement unlocked: fully triaged
Posted by Kenneth Knowles <ke...@apache.org>.
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 <ro...@frantil.com> 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 <de...@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 <ke...@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 <ke...@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 <
>>>>> bjornpedersen@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 <ke...@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 <ke...@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 <ke...@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
>>>>>>>>>>>
>>>>>>>>>>
Re: Achievement unlocked: fully triaged
Posted by Robert Burke <ro...@frantil.com>.
+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 <de...@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 <ke...@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 <ke...@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 <
>>>> bjornpedersen@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 <ke...@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 <ke...@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 <ke...@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
>>>>>>>>>>
>>>>>>>>>
Re: Achievement unlocked: fully triaged
Posted by Danny McCormick via dev <de...@beam.apache.org>.
I like that idea (and the list) as well.
On Tue, Dec 6, 2022 at 1:59 PM Kerry Donny-Clark <ke...@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 <ke...@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 <bj...@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 <ke...@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 <ke...@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 <ke...@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
>>>>>>>>>
>>>>>>>>
Re: Achievement unlocked: fully triaged
Posted by Kerry Donny-Clark via dev <de...@beam.apache.org>.
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 <ke...@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 <bj...@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 <ke...@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 <ke...@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 <ke...@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
>>>>>>>>
>>>>>>>
Re: Achievement unlocked: fully triaged
Posted by Kenneth Knowles <ke...@apache.org>.
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 <de...@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 <bj...@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 <ke...@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 <ke...@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 <ke...@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
>>>>>>>
>>>>>>
Re: Achievement unlocked: fully triaged
Posted by Danny McCormick via dev <de...@beam.apache.org>.
> 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 <bj...@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 <ke...@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 <ke...@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 <ke...@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
>>>>>>
>>>>>
Re: Achievement unlocked: fully triaged
Posted by Bjorn Pedersen via dev <de...@beam.apache.org>.
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 <ke...@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 <ke...@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 <ke...@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
>>>>>
>>>>
Re: Achievement unlocked: fully triaged
Posted by Kenneth Knowles <ke...@apache.org>.
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 <de...@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 <ke...@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 <ke...@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
>>>>
>>>
Re: Achievement unlocked: fully triaged
Posted by Danny McCormick via dev <de...@beam.apache.org>.
> 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 <ke...@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 <ke...@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
>>>
>>
Re: Achievement unlocked: fully triaged
Posted by Kenneth Knowles <ke...@apache.org>.
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 <ke...@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
>>
>
Re: Achievement unlocked: fully triaged
Posted by Kerry Donny-Clark via dev <de...@beam.apache.org>.
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 <ke...@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
>