Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Maximilian Michels]

Thanks for all the work Kenn. The new JIRA workflow is much better than 
the old label-based.


-Max

On 01.05.19 21:27, Kenneth Knowles wrote:
Yes, new issues should have that status. And a correction: it is "Triage 
Needed"


On Wed, May 1, 2019, 11:39 Pablo Estrada > wrote:


Hi Kenn,
For my information... is the Needs Triage status automatically
assigned to new issues? Are users expected to give their issue the
Needs Triage status when they create it?
Thanks
-P.

On Wed, May 1, 2019 at 11:12 AM Kenneth Knowles mailto:k...@apache.org>> wrote:

An update here: we have the new workflow in place. I have
transitioned untriaged issues to the "Needs Triage" status" so
they are very easy to find, and removed the obsolete triaged label.

Please help to triage! You can just look at all issues with the
Needs Triage status and make sure it is in the right component
and priority makes sense, and maybe alert someone who might want
to know about it.

Kenn

On Mon, Mar 4, 2019 at 9:23 AM Kenneth Knowles mailto:k...@apache.org>> wrote:

This effort to improve our triage is still ongoing. To recall:

     Issues are no longer automatically assigned, so we have
to watch them!
Here's a saved search for issues needing triage:
https://issues.apache.org/jira/issues/?filter=12345682

Anyone can help out. Just make sure the issue is in a
suitable component and someone is assigned or mentioned so
they'll get a notification, then add the "triaged" tag.

You can also subscribe to the filter to watch incoming issues.

Kenn

On Wed, Feb 6, 2019 at 9:04 PM Kenneth Knowles
mailto:k...@apache.org>> wrote:

I re-triaged most issues where the creation date != last
update. I worked through everyone with more issues than
myself (which I have triaged regularly) and a few people
with a few fewer issues.

I didn't look as closely at issues that were filed by
the assignee. So if you filed a bunch of issues that
landed on yourself, take a look.

If you have fewer than 30 issues assigned to you, please
take a look at them now.

Kenn

On Wed, Feb 6, 2019 at 8:15 PM Kenneth Knowles
mailto:k...@apache.org>> wrote:

While we work with infra on this, let's remove the
broken system and use tags. It is important that
issues coming in are known to be untriaged, so
instead of a "Needs Triage" label, we should use
"triaged". So I will take these actions that
everyone seems to agree on:

  - Remove default assignment from Jira configs
  - Unassign all issues from people with a huge number
  - Add "triaged" tag to issues that are assigned
and have some meaningful recent activity

I will use trial-and-error to figure out what looks
OK for "huge number" and "meaningful recent activity".

Kenn

On Fri, Jan 11, 2019 at 3:20 PM Kenneth Knowles
mailto:k...@apache.org>> wrote:

Filed
https://issues.apache.org/jira/browse/INFRA-17628 for
the new status. The rest of 1-3 is self-service
I think. I expect step 4 and 5 will need INFRA
as well, but I/we should do what we can to make
a very clear request.

On Fri, Jan 11, 2019 at 12:54 PM Kenneth Knowles
mailto:k...@google.com>> wrote:

It sounds like there's a lot of consensus,
pretty much on the action items that Max and
Ahmet suggested. I will start on these first
steps if no one objects:

0) Add a Needs Review status to our workflow
1) Change new issues to be Unassigned and to
be in status "Needs Review"
2) Unassign all issues from folks with > 30

And I'm not sure if folks had more to say on
these:

3) Use Wiki of multiple committers per
component rather than Jira component owners
4) Automatically unassign stale issues that
are just sitting on an assignee
5) Look int

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Kenneth Knowles]

Yes, new issues should have that status. And a correction: it is "Triage
Needed"

On Wed, May 1, 2019, 11:39 Pablo Estrada  wrote:

> Hi Kenn,
> For my information... is the Needs Triage status automatically assigned to
> new issues? Are users expected to give their issue the Needs Triage status
> when they create it?
> Thanks
> -P.
>
> On Wed, May 1, 2019 at 11:12 AM Kenneth Knowles  wrote:
>
>> An update here: we have the new workflow in place. I have transitioned
>> untriaged issues to the "Needs Triage" status" so they are very easy to
>> find, and removed the obsolete triaged label.
>>
>> Please help to triage! You can just look at all issues with the Needs
>> Triage status and make sure it is in the right component and priority makes
>> sense, and maybe alert someone who might want to know about it.
>>
>> Kenn
>>
>> On Mon, Mar 4, 2019 at 9:23 AM Kenneth Knowles  wrote:
>>
>>> This effort to improve our triage is still ongoing. To recall:
>>>
>>> Issues are no longer automatically assigned, so we have to watch
>>> them!
>>>
>>> Here's a saved search for issues needing triage:
>>> https://issues.apache.org/jira/issues/?filter=12345682
>>>
>>> Anyone can help out. Just make sure the issue is in a suitable component
>>> and someone is assigned or mentioned so they'll get a notification, then
>>> add the "triaged" tag.
>>>
>>> You can also subscribe to the filter to watch incoming issues.
>>>
>>> Kenn
>>>
>>> On Wed, Feb 6, 2019 at 9:04 PM Kenneth Knowles  wrote:
>>>
 I re-triaged most issues where the creation date != last update. I
 worked through everyone with more issues than myself (which I have triaged
 regularly) and a few people with a few fewer issues.

 I didn't look as closely at issues that were filed by the assignee. So
 if you filed a bunch of issues that landed on yourself, take a look.

 If you have fewer than 30 issues assigned to you, please take a look at
 them now.

 Kenn

 On Wed, Feb 6, 2019 at 8:15 PM Kenneth Knowles  wrote:

> While we work with infra on this, let's remove the broken system and
> use tags. It is important that issues coming in are known to be untriaged,
> so instead of a "Needs Triage" label, we should use "triaged". So I will
> take these actions that everyone seems to agree on:
>
>  - Remove default assignment from Jira configs
>  - Unassign all issues from people with a huge number
>  - Add "triaged" tag to issues that are assigned and have some
> meaningful recent activity
>
> I will use trial-and-error to figure out what looks OK for "huge
> number" and "meaningful recent activity".
>
> Kenn
>
> On Fri, Jan 11, 2019 at 3:20 PM Kenneth Knowles 
> wrote:
>
>> Filed https://issues.apache.org/jira/browse/INFRA-17628 for the new
>> status. The rest of 1-3 is self-service I think. I expect step 4 and 5 
>> will
>> need INFRA as well, but I/we should do what we can to make a very clear
>> request.
>>
>> On Fri, Jan 11, 2019 at 12:54 PM Kenneth Knowles 
>> wrote:
>>
>>> It sounds like there's a lot of consensus, pretty much on the action
>>> items that Max and Ahmet suggested. I will start on these first steps 
>>> if no
>>> one objects:
>>>
>>> 0) Add a Needs Review status to our workflow
>>> 1) Change new issues to be Unassigned and to be in status "Needs
>>> Review"
>>> 2) Unassign all issues from folks with > 30
>>>
>>> And I'm not sure if folks had more to say on these:
>>>
>>> 3) Use Wiki of multiple committers per component rather than Jira
>>> component owners
>>> 4) Automatically unassign stale issues that are just sitting on an
>>> assignee
>>> 5) Look into SLOs per issue priority and see how we can surface SLO
>>> violations (reports and pings)
>>>
>>> Kenn
>>>
>>> On Thu, Jan 10, 2019 at 11:41 AM Scott Wegner 
>>> wrote:
>>>
 +1

 > 3) Ensure that each component's unresolved issues get looked at
 regularly

 This is ideal, but I also don't know how to get to this state.
 Starting with clear component ownership and expectations will help. If 
 the
 triaging process is well-defined, then members of the community can 
 help
 for any components which need additional support.

 On Thu, Jan 10, 2019 at 12:21 AM Mikhail Gryzykhin <
 gryzykhin.mikh...@gmail.com> wrote:

> +1 to keep issues unassigned and reevaluate backlog from time to
> time.
>
> We can also auto-unassign if there was no activity on ticket for N
> days. Or we can have auto-mailed report that highlights stale assigned
> issues.
>
> On Thu, Jan 10, 2019 at 12:10 AM Robert Bradshaw <
> rober...@google.com> wrote:
>
>> On Thu, Jan 10, 2

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Pablo Estrada]

Hi Kenn,
For my information... is the Needs Triage status automatically assigned to
new issues? Are users expected to give their issue the Needs Triage status
when they create it?
Thanks
-P.

On Wed, May 1, 2019 at 11:12 AM Kenneth Knowles  wrote:

> An update here: we have the new workflow in place. I have transitioned
> untriaged issues to the "Needs Triage" status" so they are very easy to
> find, and removed the obsolete triaged label.
>
> Please help to triage! You can just look at all issues with the Needs
> Triage status and make sure it is in the right component and priority makes
> sense, and maybe alert someone who might want to know about it.
>
> Kenn
>
> On Mon, Mar 4, 2019 at 9:23 AM Kenneth Knowles  wrote:
>
>> This effort to improve our triage is still ongoing. To recall:
>>
>> Issues are no longer automatically assigned, so we have to watch them!
>>
>> Here's a saved search for issues needing triage:
>> https://issues.apache.org/jira/issues/?filter=12345682
>>
>> Anyone can help out. Just make sure the issue is in a suitable component
>> and someone is assigned or mentioned so they'll get a notification, then
>> add the "triaged" tag.
>>
>> You can also subscribe to the filter to watch incoming issues.
>>
>> Kenn
>>
>> On Wed, Feb 6, 2019 at 9:04 PM Kenneth Knowles  wrote:
>>
>>> I re-triaged most issues where the creation date != last update. I
>>> worked through everyone with more issues than myself (which I have triaged
>>> regularly) and a few people with a few fewer issues.
>>>
>>> I didn't look as closely at issues that were filed by the assignee. So
>>> if you filed a bunch of issues that landed on yourself, take a look.
>>>
>>> If you have fewer than 30 issues assigned to you, please take a look at
>>> them now.
>>>
>>> Kenn
>>>
>>> On Wed, Feb 6, 2019 at 8:15 PM Kenneth Knowles  wrote:
>>>
 While we work with infra on this, let's remove the broken system and
 use tags. It is important that issues coming in are known to be untriaged,
 so instead of a "Needs Triage" label, we should use "triaged". So I will
 take these actions that everyone seems to agree on:

  - Remove default assignment from Jira configs
  - Unassign all issues from people with a huge number
  - Add "triaged" tag to issues that are assigned and have some
 meaningful recent activity

 I will use trial-and-error to figure out what looks OK for "huge
 number" and "meaningful recent activity".

 Kenn

 On Fri, Jan 11, 2019 at 3:20 PM Kenneth Knowles 
 wrote:

> Filed https://issues.apache.org/jira/browse/INFRA-17628 for the new
> status. The rest of 1-3 is self-service I think. I expect step 4 and 5 
> will
> need INFRA as well, but I/we should do what we can to make a very clear
> request.
>
> On Fri, Jan 11, 2019 at 12:54 PM Kenneth Knowles 
> wrote:
>
>> It sounds like there's a lot of consensus, pretty much on the action
>> items that Max and Ahmet suggested. I will start on these first steps if 
>> no
>> one objects:
>>
>> 0) Add a Needs Review status to our workflow
>> 1) Change new issues to be Unassigned and to be in status "Needs
>> Review"
>> 2) Unassign all issues from folks with > 30
>>
>> And I'm not sure if folks had more to say on these:
>>
>> 3) Use Wiki of multiple committers per component rather than Jira
>> component owners
>> 4) Automatically unassign stale issues that are just sitting on an
>> assignee
>> 5) Look into SLOs per issue priority and see how we can surface SLO
>> violations (reports and pings)
>>
>> Kenn
>>
>> On Thu, Jan 10, 2019 at 11:41 AM Scott Wegner 
>> wrote:
>>
>>> +1
>>>
>>> > 3) Ensure that each component's unresolved issues get looked at
>>> regularly
>>>
>>> This is ideal, but I also don't know how to get to this state.
>>> Starting with clear component ownership and expectations will help. If 
>>> the
>>> triaging process is well-defined, then members of the community can help
>>> for any components which need additional support.
>>>
>>> On Thu, Jan 10, 2019 at 12:21 AM Mikhail Gryzykhin <
>>> gryzykhin.mikh...@gmail.com> wrote:
>>>
 +1 to keep issues unassigned and reevaluate backlog from time to
 time.

 We can also auto-unassign if there was no activity on ticket for N
 days. Or we can have auto-mailed report that highlights stale assigned
 issues.

 On Thu, Jan 10, 2019 at 12:10 AM Robert Bradshaw <
 rober...@google.com> wrote:

> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay 
> wrote:
> >
> > I agree with the proposals here. Initial state of "Needs Review"
> and blocking releases on untriaged issues will ensure that we will at 
> least
> look at every new issue once.
>

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Kenneth Knowles]

An update here: we have the new workflow in place. I have transitioned
untriaged issues to the "Needs Triage" status" so they are very easy to
find, and removed the obsolete triaged label.

Please help to triage! You can just look at all issues with the Needs
Triage status and make sure it is in the right component and priority makes
sense, and maybe alert someone who might want to know about it.

Kenn

On Mon, Mar 4, 2019 at 9:23 AM Kenneth Knowles  wrote:

> This effort to improve our triage is still ongoing. To recall:
>
> Issues are no longer automatically assigned, so we have to watch them!
>
> Here's a saved search for issues needing triage:
> https://issues.apache.org/jira/issues/?filter=12345682
>
> Anyone can help out. Just make sure the issue is in a suitable component
> and someone is assigned or mentioned so they'll get a notification, then
> add the "triaged" tag.
>
> You can also subscribe to the filter to watch incoming issues.
>
> Kenn
>
> On Wed, Feb 6, 2019 at 9:04 PM Kenneth Knowles  wrote:
>
>> I re-triaged most issues where the creation date != last update. I worked
>> through everyone with more issues than myself (which I have triaged
>> regularly) and a few people with a few fewer issues.
>>
>> I didn't look as closely at issues that were filed by the assignee. So if
>> you filed a bunch of issues that landed on yourself, take a look.
>>
>> If you have fewer than 30 issues assigned to you, please take a look at
>> them now.
>>
>> Kenn
>>
>> On Wed, Feb 6, 2019 at 8:15 PM Kenneth Knowles  wrote:
>>
>>> While we work with infra on this, let's remove the broken system and use
>>> tags. It is important that issues coming in are known to be untriaged, so
>>> instead of a "Needs Triage" label, we should use "triaged". So I will take
>>> these actions that everyone seems to agree on:
>>>
>>>  - Remove default assignment from Jira configs
>>>  - Unassign all issues from people with a huge number
>>>  - Add "triaged" tag to issues that are assigned and have some
>>> meaningful recent activity
>>>
>>> I will use trial-and-error to figure out what looks OK for "huge number"
>>> and "meaningful recent activity".
>>>
>>> Kenn
>>>
>>> On Fri, Jan 11, 2019 at 3:20 PM Kenneth Knowles  wrote:
>>>
 Filed https://issues.apache.org/jira/browse/INFRA-17628 for the new
 status. The rest of 1-3 is self-service I think. I expect step 4 and 5 will
 need INFRA as well, but I/we should do what we can to make a very clear
 request.

 On Fri, Jan 11, 2019 at 12:54 PM Kenneth Knowles 
 wrote:

> It sounds like there's a lot of consensus, pretty much on the action
> items that Max and Ahmet suggested. I will start on these first steps if 
> no
> one objects:
>
> 0) Add a Needs Review status to our workflow
> 1) Change new issues to be Unassigned and to be in status "Needs
> Review"
> 2) Unassign all issues from folks with > 30
>
> And I'm not sure if folks had more to say on these:
>
> 3) Use Wiki of multiple committers per component rather than Jira
> component owners
> 4) Automatically unassign stale issues that are just sitting on an
> assignee
> 5) Look into SLOs per issue priority and see how we can surface SLO
> violations (reports and pings)
>
> Kenn
>
> On Thu, Jan 10, 2019 at 11:41 AM Scott Wegner 
> wrote:
>
>> +1
>>
>> > 3) Ensure that each component's unresolved issues get looked at
>> regularly
>>
>> This is ideal, but I also don't know how to get to this state.
>> Starting with clear component ownership and expectations will help. If 
>> the
>> triaging process is well-defined, then members of the community can help
>> for any components which need additional support.
>>
>> On Thu, Jan 10, 2019 at 12:21 AM Mikhail Gryzykhin <
>> gryzykhin.mikh...@gmail.com> wrote:
>>
>>> +1 to keep issues unassigned and reevaluate backlog from time to
>>> time.
>>>
>>> We can also auto-unassign if there was no activity on ticket for N
>>> days. Or we can have auto-mailed report that highlights stale assigned
>>> issues.
>>>
>>> On Thu, Jan 10, 2019 at 12:10 AM Robert Bradshaw <
>>> rober...@google.com> wrote:
>>>
 On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay 
 wrote:
 >
 > I agree with the proposals here. Initial state of "Needs Review"
 and blocking releases on untriaged issues will ensure that we will at 
 least
 look at every new issue once.

 +1.

 I'm more ambivalent about closing stale issues. Unlike PRs, issues
 can
 be filed as "we should (not forget to) do this" much sooner than
 they're actively worked on.

 > On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels <
 m...@apache.org> wrote:
 >>
 >> Hi Kenn,
 >>
 >> As your 

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Kenneth Knowles]

This effort to improve our triage is still ongoing. To recall:

Issues are no longer automatically assigned, so we have to watch them!

Here's a saved search for issues needing triage:
https://issues.apache.org/jira/issues/?filter=12345682

Anyone can help out. Just make sure the issue is in a suitable component
and someone is assigned or mentioned so they'll get a notification, then
add the "triaged" tag.

You can also subscribe to the filter to watch incoming issues.

Kenn

On Wed, Feb 6, 2019 at 9:04 PM Kenneth Knowles  wrote:

> I re-triaged most issues where the creation date != last update. I worked
> through everyone with more issues than myself (which I have triaged
> regularly) and a few people with a few fewer issues.
>
> I didn't look as closely at issues that were filed by the assignee. So if
> you filed a bunch of issues that landed on yourself, take a look.
>
> If you have fewer than 30 issues assigned to you, please take a look at
> them now.
>
> Kenn
>
> On Wed, Feb 6, 2019 at 8:15 PM Kenneth Knowles  wrote:
>
>> While we work with infra on this, let's remove the broken system and use
>> tags. It is important that issues coming in are known to be untriaged, so
>> instead of a "Needs Triage" label, we should use "triaged". So I will take
>> these actions that everyone seems to agree on:
>>
>>  - Remove default assignment from Jira configs
>>  - Unassign all issues from people with a huge number
>>  - Add "triaged" tag to issues that are assigned and have some meaningful
>> recent activity
>>
>> I will use trial-and-error to figure out what looks OK for "huge number"
>> and "meaningful recent activity".
>>
>> Kenn
>>
>> On Fri, Jan 11, 2019 at 3:20 PM Kenneth Knowles  wrote:
>>
>>> Filed https://issues.apache.org/jira/browse/INFRA-17628 for the new
>>> status. The rest of 1-3 is self-service I think. I expect step 4 and 5 will
>>> need INFRA as well, but I/we should do what we can to make a very clear
>>> request.
>>>
>>> On Fri, Jan 11, 2019 at 12:54 PM Kenneth Knowles  wrote:
>>>
 It sounds like there's a lot of consensus, pretty much on the action
 items that Max and Ahmet suggested. I will start on these first steps if no
 one objects:

 0) Add a Needs Review status to our workflow
 1) Change new issues to be Unassigned and to be in status "Needs Review"
 2) Unassign all issues from folks with > 30

 And I'm not sure if folks had more to say on these:

 3) Use Wiki of multiple committers per component rather than Jira
 component owners
 4) Automatically unassign stale issues that are just sitting on an
 assignee
 5) Look into SLOs per issue priority and see how we can surface SLO
 violations (reports and pings)

 Kenn

 On Thu, Jan 10, 2019 at 11:41 AM Scott Wegner 
 wrote:

> +1
>
> > 3) Ensure that each component's unresolved issues get looked at
> regularly
>
> This is ideal, but I also don't know how to get to this state.
> Starting with clear component ownership and expectations will help. If the
> triaging process is well-defined, then members of the community can help
> for any components which need additional support.
>
> On Thu, Jan 10, 2019 at 12:21 AM Mikhail Gryzykhin <
> gryzykhin.mikh...@gmail.com> wrote:
>
>> +1 to keep issues unassigned and reevaluate backlog from time to time.
>>
>> We can also auto-unassign if there was no activity on ticket for N
>> days. Or we can have auto-mailed report that highlights stale assigned
>> issues.
>>
>> On Thu, Jan 10, 2019 at 12:10 AM Robert Bradshaw 
>> wrote:
>>
>>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay 
>>> wrote:
>>> >
>>> > I agree with the proposals here. Initial state of "Needs Review"
>>> and blocking releases on untriaged issues will ensure that we will at 
>>> least
>>> look at every new issue once.
>>>
>>> +1.
>>>
>>> I'm more ambivalent about closing stale issues. Unlike PRs, issues
>>> can
>>> be filed as "we should (not forget to) do this" much sooner than
>>> they're actively worked on.
>>>
>>> > On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels 
>>> wrote:
>>> >>
>>> >> Hi Kenn,
>>> >>
>>> >> As your data shows, default-assigning issues to a single person
>>> does not
>>> >> automatically solve triaging issues. Quite the contrary, it hides
>>> the triage
>>> >> status of an issue.
>>> >>
>>> >>  From the perspective of the Flink Runner, we used to auto-assign
>>> but we got rid
>>> >> of this. Instead, we monitor the newly coming issues and take
>>> actions. We also
>>> >> go through the old ones occasionally. I believe that works fine
>>> for us.
>>> >>
>>> >> The Flink project itself also does not default-assign, newly
>>> created issues are
>>> >> unassigned. There are component leads overseei

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Kenneth Knowles]

I re-triaged most issues where the creation date != last update. I worked
through everyone with more issues than myself (which I have triaged
regularly) and a few people with a few fewer issues.

I didn't look as closely at issues that were filed by the assignee. So if
you filed a bunch of issues that landed on yourself, take a look.

If you have fewer than 30 issues assigned to you, please take a look at
them now.

Kenn

On Wed, Feb 6, 2019 at 8:15 PM Kenneth Knowles  wrote:

> While we work with infra on this, let's remove the broken system and use
> tags. It is important that issues coming in are known to be untriaged, so
> instead of a "Needs Triage" label, we should use "triaged". So I will take
> these actions that everyone seems to agree on:
>
>  - Remove default assignment from Jira configs
>  - Unassign all issues from people with a huge number
>  - Add "triaged" tag to issues that are assigned and have some meaningful
> recent activity
>
> I will use trial-and-error to figure out what looks OK for "huge number"
> and "meaningful recent activity".
>
> Kenn
>
> On Fri, Jan 11, 2019 at 3:20 PM Kenneth Knowles  wrote:
>
>> Filed https://issues.apache.org/jira/browse/INFRA-17628 for the new
>> status. The rest of 1-3 is self-service I think. I expect step 4 and 5 will
>> need INFRA as well, but I/we should do what we can to make a very clear
>> request.
>>
>> On Fri, Jan 11, 2019 at 12:54 PM Kenneth Knowles  wrote:
>>
>>> It sounds like there's a lot of consensus, pretty much on the action
>>> items that Max and Ahmet suggested. I will start on these first steps if no
>>> one objects:
>>>
>>> 0) Add a Needs Review status to our workflow
>>> 1) Change new issues to be Unassigned and to be in status "Needs Review"
>>> 2) Unassign all issues from folks with > 30
>>>
>>> And I'm not sure if folks had more to say on these:
>>>
>>> 3) Use Wiki of multiple committers per component rather than Jira
>>> component owners
>>> 4) Automatically unassign stale issues that are just sitting on an
>>> assignee
>>> 5) Look into SLOs per issue priority and see how we can surface SLO
>>> violations (reports and pings)
>>>
>>> Kenn
>>>
>>> On Thu, Jan 10, 2019 at 11:41 AM Scott Wegner 
>>> wrote:
>>>
 +1

 > 3) Ensure that each component's unresolved issues get looked at
 regularly

 This is ideal, but I also don't know how to get to this state. Starting
 with clear component ownership and expectations will help. If the triaging
 process is well-defined, then members of the community can help for any
 components which need additional support.

 On Thu, Jan 10, 2019 at 12:21 AM Mikhail Gryzykhin <
 gryzykhin.mikh...@gmail.com> wrote:

> +1 to keep issues unassigned and reevaluate backlog from time to time.
>
> We can also auto-unassign if there was no activity on ticket for N
> days. Or we can have auto-mailed report that highlights stale assigned
> issues.
>
> On Thu, Jan 10, 2019 at 12:10 AM Robert Bradshaw 
> wrote:
>
>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay  wrote:
>> >
>> > I agree with the proposals here. Initial state of "Needs Review"
>> and blocking releases on untriaged issues will ensure that we will at 
>> least
>> look at every new issue once.
>>
>> +1.
>>
>> I'm more ambivalent about closing stale issues. Unlike PRs, issues can
>> be filed as "we should (not forget to) do this" much sooner than
>> they're actively worked on.
>>
>> > On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels 
>> wrote:
>> >>
>> >> Hi Kenn,
>> >>
>> >> As your data shows, default-assigning issues to a single person
>> does not
>> >> automatically solve triaging issues. Quite the contrary, it hides
>> the triage
>> >> status of an issue.
>> >>
>> >>  From the perspective of the Flink Runner, we used to auto-assign
>> but we got rid
>> >> of this. Instead, we monitor the newly coming issues and take
>> actions. We also
>> >> go through the old ones occasionally. I believe that works fine
>> for us.
>> >>
>> >> The Flink project itself also does not default-assign, newly
>> created issues are
>> >> unassigned. There are component leads overseeing issues. There is
>> no guarantee
>> >> that every issue gets triaged.
>> >>
>> >> "Needs Triage" or or "Needs Review" (seems easier to understand of
>> non-native
>> >> speakers) sounds like a good addition, but it will not solve the
>> problem that
>> >> issues need to be curated and maintained after the initial triage.
>> For example,
>> >> I've seen issues not closed after they have been fixed via a PR.
>> However, "Needs
>> >> Triage" will ensure that all issues get looked at. This could be
>> helpful for
>> >> releases, if not-yet-triaged issues are looked at early enough.
>> >>
>> >> I'd suggest to:
>>

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Kenneth Knowles]

While we work with infra on this, let's remove the broken system and use
tags. It is important that issues coming in are known to be untriaged, so
instead of a "Needs Triage" label, we should use "triaged". So I will take
these actions that everyone seems to agree on:

 - Remove default assignment from Jira configs
 - Unassign all issues from people with a huge number
 - Add "triaged" tag to issues that are assigned and have some meaningful
recent activity

I will use trial-and-error to figure out what looks OK for "huge number"
and "meaningful recent activity".

Kenn

On Fri, Jan 11, 2019 at 3:20 PM Kenneth Knowles  wrote:

> Filed https://issues.apache.org/jira/browse/INFRA-17628 for the new
> status. The rest of 1-3 is self-service I think. I expect step 4 and 5 will
> need INFRA as well, but I/we should do what we can to make a very clear
> request.
>
> On Fri, Jan 11, 2019 at 12:54 PM Kenneth Knowles  wrote:
>
>> It sounds like there's a lot of consensus, pretty much on the action
>> items that Max and Ahmet suggested. I will start on these first steps if no
>> one objects:
>>
>> 0) Add a Needs Review status to our workflow
>> 1) Change new issues to be Unassigned and to be in status "Needs Review"
>> 2) Unassign all issues from folks with > 30
>>
>> And I'm not sure if folks had more to say on these:
>>
>> 3) Use Wiki of multiple committers per component rather than Jira
>> component owners
>> 4) Automatically unassign stale issues that are just sitting on an
>> assignee
>> 5) Look into SLOs per issue priority and see how we can surface SLO
>> violations (reports and pings)
>>
>> Kenn
>>
>> On Thu, Jan 10, 2019 at 11:41 AM Scott Wegner  wrote:
>>
>>> +1
>>>
>>> > 3) Ensure that each component's unresolved issues get looked at
>>> regularly
>>>
>>> This is ideal, but I also don't know how to get to this state. Starting
>>> with clear component ownership and expectations will help. If the triaging
>>> process is well-defined, then members of the community can help for any
>>> components which need additional support.
>>>
>>> On Thu, Jan 10, 2019 at 12:21 AM Mikhail Gryzykhin <
>>> gryzykhin.mikh...@gmail.com> wrote:
>>>
 +1 to keep issues unassigned and reevaluate backlog from time to time.

 We can also auto-unassign if there was no activity on ticket for N
 days. Or we can have auto-mailed report that highlights stale assigned
 issues.

 On Thu, Jan 10, 2019 at 12:10 AM Robert Bradshaw 
 wrote:

> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay  wrote:
> >
> > I agree with the proposals here. Initial state of "Needs Review" and
> blocking releases on untriaged issues will ensure that we will at least
> look at every new issue once.
>
> +1.
>
> I'm more ambivalent about closing stale issues. Unlike PRs, issues can
> be filed as "we should (not forget to) do this" much sooner than
> they're actively worked on.
>
> > On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels 
> wrote:
> >>
> >> Hi Kenn,
> >>
> >> As your data shows, default-assigning issues to a single person
> does not
> >> automatically solve triaging issues. Quite the contrary, it hides
> the triage
> >> status of an issue.
> >>
> >>  From the perspective of the Flink Runner, we used to auto-assign
> but we got rid
> >> of this. Instead, we monitor the newly coming issues and take
> actions. We also
> >> go through the old ones occasionally. I believe that works fine for
> us.
> >>
> >> The Flink project itself also does not default-assign, newly
> created issues are
> >> unassigned. There are component leads overseeing issues. There is
> no guarantee
> >> that every issue gets triaged.
> >>
> >> "Needs Triage" or or "Needs Review" (seems easier to understand of
> non-native
> >> speakers) sounds like a good addition, but it will not solve the
> problem that
> >> issues need to be curated and maintained after the initial triage.
> For example,
> >> I've seen issues not closed after they have been fixed via a PR.
> However, "Needs
> >> Triage" will ensure that all issues get looked at. This could be
> helpful for
> >> releases, if not-yet-triaged issues are looked at early enough.
> >>
> >> I'd suggest to:
> >>
> >> 1) Change new issues to be Unassigned and to be in status "Needs
> Review"
> >> 2) Remove Assignees from all not-being-worked-on issues
> >
> >
> > For the existing issues, I suggest unassign all issues assigned to
> people with > N issues for a large N. Something like 30, > %1 of all
> issues. There are also issues assigned to people who are no longer active
> in the community. We could unassign those as well.
> >
> > Another issue is average age for open issues is also ever growing
> and is over > 300 days now. It would be nice if we can have an equivale

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Kenneth Knowles]

Filed https://issues.apache.org/jira/browse/INFRA-17628 for the new status.
The rest of 1-3 is self-service I think. I expect step 4 and 5 will need
INFRA as well, but I/we should do what we can to make a very clear request.

On Fri, Jan 11, 2019 at 12:54 PM Kenneth Knowles  wrote:

> It sounds like there's a lot of consensus, pretty much on the action items
> that Max and Ahmet suggested. I will start on these first steps if no one
> objects:
>
> 0) Add a Needs Review status to our workflow
> 1) Change new issues to be Unassigned and to be in status "Needs Review"
> 2) Unassign all issues from folks with > 30
>
> And I'm not sure if folks had more to say on these:
>
> 3) Use Wiki of multiple committers per component rather than Jira
> component owners
> 4) Automatically unassign stale issues that are just sitting on an assignee
> 5) Look into SLOs per issue priority and see how we can surface SLO
> violations (reports and pings)
>
> Kenn
>
> On Thu, Jan 10, 2019 at 11:41 AM Scott Wegner  wrote:
>
>> +1
>>
>> > 3) Ensure that each component's unresolved issues get looked at
>> regularly
>>
>> This is ideal, but I also don't know how to get to this state. Starting
>> with clear component ownership and expectations will help. If the triaging
>> process is well-defined, then members of the community can help for any
>> components which need additional support.
>>
>> On Thu, Jan 10, 2019 at 12:21 AM Mikhail Gryzykhin <
>> gryzykhin.mikh...@gmail.com> wrote:
>>
>>> +1 to keep issues unassigned and reevaluate backlog from time to time.
>>>
>>> We can also auto-unassign if there was no activity on ticket for N days.
>>> Or we can have auto-mailed report that highlights stale assigned issues.
>>>
>>> On Thu, Jan 10, 2019 at 12:10 AM Robert Bradshaw 
>>> wrote:
>>>
 On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay  wrote:
 >
 > I agree with the proposals here. Initial state of "Needs Review" and
 blocking releases on untriaged issues will ensure that we will at least
 look at every new issue once.

 +1.

 I'm more ambivalent about closing stale issues. Unlike PRs, issues can
 be filed as "we should (not forget to) do this" much sooner than
 they're actively worked on.

 > On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels 
 wrote:
 >>
 >> Hi Kenn,
 >>
 >> As your data shows, default-assigning issues to a single person does
 not
 >> automatically solve triaging issues. Quite the contrary, it hides
 the triage
 >> status of an issue.
 >>
 >>  From the perspective of the Flink Runner, we used to auto-assign
 but we got rid
 >> of this. Instead, we monitor the newly coming issues and take
 actions. We also
 >> go through the old ones occasionally. I believe that works fine for
 us.
 >>
 >> The Flink project itself also does not default-assign, newly created
 issues are
 >> unassigned. There are component leads overseeing issues. There is no
 guarantee
 >> that every issue gets triaged.
 >>
 >> "Needs Triage" or or "Needs Review" (seems easier to understand of
 non-native
 >> speakers) sounds like a good addition, but it will not solve the
 problem that
 >> issues need to be curated and maintained after the initial triage.
 For example,
 >> I've seen issues not closed after they have been fixed via a PR.
 However, "Needs
 >> Triage" will ensure that all issues get looked at. This could be
 helpful for
 >> releases, if not-yet-triaged issues are looked at early enough.
 >>
 >> I'd suggest to:
 >>
 >> 1) Change new issues to be Unassigned and to be in status "Needs
 Review"
 >> 2) Remove Assignees from all not-being-worked-on issues
 >
 >
 > For the existing issues, I suggest unassign all issues assigned to
 people with > N issues for a large N. Something like 30, > %1 of all
 issues. There are also issues assigned to people who are no longer active
 in the community. We could unassign those as well.
 >
 > Another issue is average age for open issues is also ever growing and
 is over > 300 days now. It would be nice if we can have an equivalent of
 stale bot for PRs for JIRAs, unassigning/closing stale issues periodically.
 >
 >>
 >> 3) Ensure that each component's unresolved issues get looked at
 regularly
 >>
 >> I suppose how to do 3) effectively is an open question. I currently
 don't see a
 >> better way as to oversee each component by multiple committers,
 similar to the
 >> OWNERS idea that we once had. I think we should move the OWNERS
 information to a
 >> Wiki page to make ownership/maintainership more transparent and
 easier to change.
 >
 >
 > I think this is a good idea. We can also divide components even more
 and there will be more people looking at smaller components each. We could
 also consi

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Kenneth Knowles]

It sounds like there's a lot of consensus, pretty much on the action items
that Max and Ahmet suggested. I will start on these first steps if no one
objects:

0) Add a Needs Review status to our workflow
1) Change new issues to be Unassigned and to be in status "Needs Review"
2) Unassign all issues from folks with > 30

And I'm not sure if folks had more to say on these:

3) Use Wiki of multiple committers per component rather than Jira component
owners
4) Automatically unassign stale issues that are just sitting on an assignee
5) Look into SLOs per issue priority and see how we can surface SLO
violations (reports and pings)

Kenn

On Thu, Jan 10, 2019 at 11:41 AM Scott Wegner  wrote:

> +1
>
> > 3) Ensure that each component's unresolved issues get looked at regularly
>
> This is ideal, but I also don't know how to get to this state. Starting
> with clear component ownership and expectations will help. If the triaging
> process is well-defined, then members of the community can help for any
> components which need additional support.
>
> On Thu, Jan 10, 2019 at 12:21 AM Mikhail Gryzykhin <
> gryzykhin.mikh...@gmail.com> wrote:
>
>> +1 to keep issues unassigned and reevaluate backlog from time to time.
>>
>> We can also auto-unassign if there was no activity on ticket for N days.
>> Or we can have auto-mailed report that highlights stale assigned issues.
>>
>> On Thu, Jan 10, 2019 at 12:10 AM Robert Bradshaw 
>> wrote:
>>
>>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay  wrote:
>>> >
>>> > I agree with the proposals here. Initial state of "Needs Review" and
>>> blocking releases on untriaged issues will ensure that we will at least
>>> look at every new issue once.
>>>
>>> +1.
>>>
>>> I'm more ambivalent about closing stale issues. Unlike PRs, issues can
>>> be filed as "we should (not forget to) do this" much sooner than
>>> they're actively worked on.
>>>
>>> > On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels 
>>> wrote:
>>> >>
>>> >> Hi Kenn,
>>> >>
>>> >> As your data shows, default-assigning issues to a single person does
>>> not
>>> >> automatically solve triaging issues. Quite the contrary, it hides the
>>> triage
>>> >> status of an issue.
>>> >>
>>> >>  From the perspective of the Flink Runner, we used to auto-assign but
>>> we got rid
>>> >> of this. Instead, we monitor the newly coming issues and take
>>> actions. We also
>>> >> go through the old ones occasionally. I believe that works fine for
>>> us.
>>> >>
>>> >> The Flink project itself also does not default-assign, newly created
>>> issues are
>>> >> unassigned. There are component leads overseeing issues. There is no
>>> guarantee
>>> >> that every issue gets triaged.
>>> >>
>>> >> "Needs Triage" or or "Needs Review" (seems easier to understand of
>>> non-native
>>> >> speakers) sounds like a good addition, but it will not solve the
>>> problem that
>>> >> issues need to be curated and maintained after the initial triage.
>>> For example,
>>> >> I've seen issues not closed after they have been fixed via a PR.
>>> However, "Needs
>>> >> Triage" will ensure that all issues get looked at. This could be
>>> helpful for
>>> >> releases, if not-yet-triaged issues are looked at early enough.
>>> >>
>>> >> I'd suggest to:
>>> >>
>>> >> 1) Change new issues to be Unassigned and to be in status "Needs
>>> Review"
>>> >> 2) Remove Assignees from all not-being-worked-on issues
>>> >
>>> >
>>> > For the existing issues, I suggest unassign all issues assigned to
>>> people with > N issues for a large N. Something like 30, > %1 of all
>>> issues. There are also issues assigned to people who are no longer active
>>> in the community. We could unassign those as well.
>>> >
>>> > Another issue is average age for open issues is also ever growing and
>>> is over > 300 days now. It would be nice if we can have an equivalent of
>>> stale bot for PRs for JIRAs, unassigning/closing stale issues periodically.
>>> >
>>> >>
>>> >> 3) Ensure that each component's unresolved issues get looked at
>>> regularly
>>> >>
>>> >> I suppose how to do 3) effectively is an open question. I currently
>>> don't see a
>>> >> better way as to oversee each component by multiple committers,
>>> similar to the
>>> >> OWNERS idea that we once had. I think we should move the OWNERS
>>> information to a
>>> >> Wiki page to make ownership/maintainership more transparent and
>>> easier to change.
>>> >
>>> >
>>> > I think this is a good idea. We can also divide components even more
>>> and there will be more people looking at smaller components each. We could
>>> also consider defining SLO type metrics especially for high priority
>>> issues, and present those in a dashboard. That way we can collectively see
>>> the overall health of our triaging efforts and prevent important issues
>>> from being forgotten.
>>> >
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Max
>>> >>
>>> >> On 08.01.19 16:30, Kenneth Knowles wrote:
>>> >> > Forking discussion on
>>> >> >
>>> >> >   - Some folks have 100+ issues

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Scott Wegner]

+1

> 3) Ensure that each component's unresolved issues get looked at regularly

This is ideal, but I also don't know how to get to this state. Starting
with clear component ownership and expectations will help. If the triaging
process is well-defined, then members of the community can help for any
components which need additional support.

On Thu, Jan 10, 2019 at 12:21 AM Mikhail Gryzykhin <
gryzykhin.mikh...@gmail.com> wrote:

> +1 to keep issues unassigned and reevaluate backlog from time to time.
>
> We can also auto-unassign if there was no activity on ticket for N days.
> Or we can have auto-mailed report that highlights stale assigned issues.
>
> On Thu, Jan 10, 2019 at 12:10 AM Robert Bradshaw 
> wrote:
>
>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay  wrote:
>> >
>> > I agree with the proposals here. Initial state of "Needs Review" and
>> blocking releases on untriaged issues will ensure that we will at least
>> look at every new issue once.
>>
>> +1.
>>
>> I'm more ambivalent about closing stale issues. Unlike PRs, issues can
>> be filed as "we should (not forget to) do this" much sooner than
>> they're actively worked on.
>>
>> > On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels 
>> wrote:
>> >>
>> >> Hi Kenn,
>> >>
>> >> As your data shows, default-assigning issues to a single person does
>> not
>> >> automatically solve triaging issues. Quite the contrary, it hides the
>> triage
>> >> status of an issue.
>> >>
>> >>  From the perspective of the Flink Runner, we used to auto-assign but
>> we got rid
>> >> of this. Instead, we monitor the newly coming issues and take actions.
>> We also
>> >> go through the old ones occasionally. I believe that works fine for us.
>> >>
>> >> The Flink project itself also does not default-assign, newly created
>> issues are
>> >> unassigned. There are component leads overseeing issues. There is no
>> guarantee
>> >> that every issue gets triaged.
>> >>
>> >> "Needs Triage" or or "Needs Review" (seems easier to understand of
>> non-native
>> >> speakers) sounds like a good addition, but it will not solve the
>> problem that
>> >> issues need to be curated and maintained after the initial triage. For
>> example,
>> >> I've seen issues not closed after they have been fixed via a PR.
>> However, "Needs
>> >> Triage" will ensure that all issues get looked at. This could be
>> helpful for
>> >> releases, if not-yet-triaged issues are looked at early enough.
>> >>
>> >> I'd suggest to:
>> >>
>> >> 1) Change new issues to be Unassigned and to be in status "Needs
>> Review"
>> >> 2) Remove Assignees from all not-being-worked-on issues
>> >
>> >
>> > For the existing issues, I suggest unassign all issues assigned to
>> people with > N issues for a large N. Something like 30, > %1 of all
>> issues. There are also issues assigned to people who are no longer active
>> in the community. We could unassign those as well.
>> >
>> > Another issue is average age for open issues is also ever growing and
>> is over > 300 days now. It would be nice if we can have an equivalent of
>> stale bot for PRs for JIRAs, unassigning/closing stale issues periodically.
>> >
>> >>
>> >> 3) Ensure that each component's unresolved issues get looked at
>> regularly
>> >>
>> >> I suppose how to do 3) effectively is an open question. I currently
>> don't see a
>> >> better way as to oversee each component by multiple committers,
>> similar to the
>> >> OWNERS idea that we once had. I think we should move the OWNERS
>> information to a
>> >> Wiki page to make ownership/maintainership more transparent and easier
>> to change.
>> >
>> >
>> > I think this is a good idea. We can also divide components even more
>> and there will be more people looking at smaller components each. We could
>> also consider defining SLO type metrics especially for high priority
>> issues, and present those in a dashboard. That way we can collectively see
>> the overall health of our triaging efforts and prevent important issues
>> from being forgotten.
>> >
>> >>
>> >>
>> >> Thanks,
>> >> Max
>> >>
>> >> On 08.01.19 16:30, Kenneth Knowles wrote:
>> >> > Forking discussion on
>> >> >
>> >> >   - Some folks have 100+ issues assigned
>> >> >   - Jira components might not be the best way to get things triaged
>> >> >
>> >> > I just ran a built-in Jira report to summarize how many tickets are
>> claimed by
>> >> > different users [1]. It does look like component owners tend to
>> accumulate
>> >> > issues and they are not likely to get addressed.
>> >> >
>> >> > So what do we want and how can we make it happen? Here is what I
>> want, personally:
>> >> >
>> >> >   - every new issue gets looked at by someone who can decide the
>> right
>> >> > component, who to ping, etc
>> >> >   - no person is assigned an issue that they are not active on
>> >> >   - we don't release with potential bugs waiting to be triaged
>> >> >
>> >> > The current status it that issues get assigned to a component owner
>> when filed.
>> >> > The component ow

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Mikhail Gryzykhin]

+1 to keep issues unassigned and reevaluate backlog from time to time.

We can also auto-unassign if there was no activity on ticket for N days. Or
we can have auto-mailed report that highlights stale assigned issues.

On Thu, Jan 10, 2019 at 12:10 AM Robert Bradshaw 
wrote:

> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay  wrote:
> >
> > I agree with the proposals here. Initial state of "Needs Review" and
> blocking releases on untriaged issues will ensure that we will at least
> look at every new issue once.
>
> +1.
>
> I'm more ambivalent about closing stale issues. Unlike PRs, issues can
> be filed as "we should (not forget to) do this" much sooner than
> they're actively worked on.
>
> > On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels 
> wrote:
> >>
> >> Hi Kenn,
> >>
> >> As your data shows, default-assigning issues to a single person does not
> >> automatically solve triaging issues. Quite the contrary, it hides the
> triage
> >> status of an issue.
> >>
> >>  From the perspective of the Flink Runner, we used to auto-assign but
> we got rid
> >> of this. Instead, we monitor the newly coming issues and take actions.
> We also
> >> go through the old ones occasionally. I believe that works fine for us.
> >>
> >> The Flink project itself also does not default-assign, newly created
> issues are
> >> unassigned. There are component leads overseeing issues. There is no
> guarantee
> >> that every issue gets triaged.
> >>
> >> "Needs Triage" or or "Needs Review" (seems easier to understand of
> non-native
> >> speakers) sounds like a good addition, but it will not solve the
> problem that
> >> issues need to be curated and maintained after the initial triage. For
> example,
> >> I've seen issues not closed after they have been fixed via a PR.
> However, "Needs
> >> Triage" will ensure that all issues get looked at. This could be
> helpful for
> >> releases, if not-yet-triaged issues are looked at early enough.
> >>
> >> I'd suggest to:
> >>
> >> 1) Change new issues to be Unassigned and to be in status "Needs Review"
> >> 2) Remove Assignees from all not-being-worked-on issues
> >
> >
> > For the existing issues, I suggest unassign all issues assigned to
> people with > N issues for a large N. Something like 30, > %1 of all
> issues. There are also issues assigned to people who are no longer active
> in the community. We could unassign those as well.
> >
> > Another issue is average age for open issues is also ever growing and is
> over > 300 days now. It would be nice if we can have an equivalent of stale
> bot for PRs for JIRAs, unassigning/closing stale issues periodically.
> >
> >>
> >> 3) Ensure that each component's unresolved issues get looked at
> regularly
> >>
> >> I suppose how to do 3) effectively is an open question. I currently
> don't see a
> >> better way as to oversee each component by multiple committers, similar
> to the
> >> OWNERS idea that we once had. I think we should move the OWNERS
> information to a
> >> Wiki page to make ownership/maintainership more transparent and easier
> to change.
> >
> >
> > I think this is a good idea. We can also divide components even more and
> there will be more people looking at smaller components each. We could also
> consider defining SLO type metrics especially for high priority issues, and
> present those in a dashboard. That way we can collectively see the overall
> health of our triaging efforts and prevent important issues from being
> forgotten.
> >
> >>
> >>
> >> Thanks,
> >> Max
> >>
> >> On 08.01.19 16:30, Kenneth Knowles wrote:
> >> > Forking discussion on
> >> >
> >> >   - Some folks have 100+ issues assigned
> >> >   - Jira components might not be the best way to get things triaged
> >> >
> >> > I just ran a built-in Jira report to summarize how many tickets are
> claimed by
> >> > different users [1]. It does look like component owners tend to
> accumulate
> >> > issues and they are not likely to get addressed.
> >> >
> >> > So what do we want and how can we make it happen? Here is what I
> want, personally:
> >> >
> >> >   - every new issue gets looked at by someone who can decide the right
> >> > component, who to ping, etc
> >> >   - no person is assigned an issue that they are not active on
> >> >   - we don't release with potential bugs waiting to be triaged
> >> >
> >> > The current status it that issues get assigned to a component owner
> when filed.
> >> > The component owner should route it and it most likely will end up in
> some
> >> > component unassigned.
> >> >
> >> > Another possibility is that we add a "Needs Triage" status and figure
> out a way
> >> > to make sure they are all looked at - maybe also by blocking a
> release on having
> >> > zero Needs Triage bugs. Just an idea.
> >> >
> >> > And important question I did not look into: what do other Apache or
> Apache-style
> >> > decentralized projects do?
> >> >
> >> > Kenn
> >> >
> >> > [1]
> >> >
> https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectO

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Robert Bradshaw]

On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay  wrote:
>
> I agree with the proposals here. Initial state of "Needs Review" and blocking 
> releases on untriaged issues will ensure that we will at least look at every 
> new issue once.

+1.

I'm more ambivalent about closing stale issues. Unlike PRs, issues can
be filed as "we should (not forget to) do this" much sooner than
they're actively worked on.

> On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels  wrote:
>>
>> Hi Kenn,
>>
>> As your data shows, default-assigning issues to a single person does not
>> automatically solve triaging issues. Quite the contrary, it hides the triage
>> status of an issue.
>>
>>  From the perspective of the Flink Runner, we used to auto-assign but we got 
>> rid
>> of this. Instead, we monitor the newly coming issues and take actions. We 
>> also
>> go through the old ones occasionally. I believe that works fine for us.
>>
>> The Flink project itself also does not default-assign, newly created issues 
>> are
>> unassigned. There are component leads overseeing issues. There is no 
>> guarantee
>> that every issue gets triaged.
>>
>> "Needs Triage" or or "Needs Review" (seems easier to understand of non-native
>> speakers) sounds like a good addition, but it will not solve the problem that
>> issues need to be curated and maintained after the initial triage. For 
>> example,
>> I've seen issues not closed after they have been fixed via a PR. However, 
>> "Needs
>> Triage" will ensure that all issues get looked at. This could be helpful for
>> releases, if not-yet-triaged issues are looked at early enough.
>>
>> I'd suggest to:
>>
>> 1) Change new issues to be Unassigned and to be in status "Needs Review"
>> 2) Remove Assignees from all not-being-worked-on issues
>
>
> For the existing issues, I suggest unassign all issues assigned to people 
> with > N issues for a large N. Something like 30, > %1 of all issues. There 
> are also issues assigned to people who are no longer active in the community. 
> We could unassign those as well.
>
> Another issue is average age for open issues is also ever growing and is over 
> > 300 days now. It would be nice if we can have an equivalent of stale bot 
> for PRs for JIRAs, unassigning/closing stale issues periodically.
>
>>
>> 3) Ensure that each component's unresolved issues get looked at regularly
>>
>> I suppose how to do 3) effectively is an open question. I currently don't 
>> see a
>> better way as to oversee each component by multiple committers, similar to 
>> the
>> OWNERS idea that we once had. I think we should move the OWNERS information 
>> to a
>> Wiki page to make ownership/maintainership more transparent and easier to 
>> change.
>
>
> I think this is a good idea. We can also divide components even more and 
> there will be more people looking at smaller components each. We could also 
> consider defining SLO type metrics especially for high priority issues, and 
> present those in a dashboard. That way we can collectively see the overall 
> health of our triaging efforts and prevent important issues from being 
> forgotten.
>
>>
>>
>> Thanks,
>> Max
>>
>> On 08.01.19 16:30, Kenneth Knowles wrote:
>> > Forking discussion on
>> >
>> >   - Some folks have 100+ issues assigned
>> >   - Jira components might not be the best way to get things triaged
>> >
>> > I just ran a built-in Jira report to summarize how many tickets are 
>> > claimed by
>> > different users [1]. It does look like component owners tend to accumulate
>> > issues and they are not likely to get addressed.
>> >
>> > So what do we want and how can we make it happen? Here is what I want, 
>> > personally:
>> >
>> >   - every new issue gets looked at by someone who can decide the right
>> > component, who to ping, etc
>> >   - no person is assigned an issue that they are not active on
>> >   - we don't release with potential bugs waiting to be triaged
>> >
>> > The current status it that issues get assigned to a component owner when 
>> > filed.
>> > The component owner should route it and it most likely will end up in some
>> > component unassigned.
>> >
>> > Another possibility is that we add a "Needs Triage" status and figure out 
>> > a way
>> > to make sure they are all looked at - maybe also by blocking a release on 
>> > having
>> > zero Needs Triage bugs. Just an idea.
>> >
>> > And important question I did not look into: what do other Apache or 
>> > Apache-style
>> > decentralized projects do?
>> >
>> > Kenn
>> >
>> > [1]
>> > https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12343976&statistictype=assignees&selectedProjectId=12319527&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Apie-report&atl_token=A5KQ-2QAV-T4JA-FDED%7C4ba43752834c87065a99ddea7c1ea92342aa%7Clin&Next=Next

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Ahmet Altay]

I agree with the proposals here. Initial state of "Needs Review" and
blocking releases on untriaged issues will ensure that we will at least
look at every new issue once.

On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels  wrote:

> Hi Kenn,
>
> As your data shows, default-assigning issues to a single person does not
> automatically solve triaging issues. Quite the contrary, it hides the
> triage
> status of an issue.
>
>  From the perspective of the Flink Runner, we used to auto-assign but we
> got rid
> of this. Instead, we monitor the newly coming issues and take actions. We
> also
> go through the old ones occasionally. I believe that works fine for us.
>
> The Flink project itself also does not default-assign, newly created
> issues are
> unassigned. There are component leads overseeing issues. There is no
> guarantee
> that every issue gets triaged.
>
> "Needs Triage" or or "Needs Review" (seems easier to understand of
> non-native
> speakers) sounds like a good addition, but it will not solve the problem
> that
> issues need to be curated and maintained after the initial triage. For
> example,
> I've seen issues not closed after they have been fixed via a PR. However,
> "Needs
> Triage" will ensure that all issues get looked at. This could be helpful
> for
> releases, if not-yet-triaged issues are looked at early enough.
>
> I'd suggest to:
>
> 1) Change new issues to be Unassigned and to be in status "Needs Review"
> 2) Remove Assignees from all not-being-worked-on issues
>

For the existing issues, I suggest unassign all issues assigned to people
with > N issues for a large N. Something like 30, > %1 of all issues. There
are also issues assigned to people who are no longer active in the
community. We could unassign those as well.

Another issue is average age for open issues is also ever growing and is
over > 300 days now. It would be nice if we can have an equivalent of stale
bot for PRs for JIRAs, unassigning/closing stale issues periodically.


> 3) Ensure that each component's unresolved issues get looked at regularly
>
> I suppose how to do 3) effectively is an open question. I currently don't
> see a
> better way as to oversee each component by multiple committers, similar to
> the
> OWNERS idea that we once had. I think we should move the OWNERS
> information to a
> Wiki page to make ownership/maintainership more transparent and easier to
> change.
>

I think this is a good idea. We can also divide components even more and
there will be more people looking at smaller components each. We could also
consider defining SLO type metrics especially for high priority issues, and
present those in a dashboard. That way we can collectively see the overall
health of our triaging efforts and prevent important issues from being
forgotten.


>
> Thanks,
> Max
>
> On 08.01.19 16:30, Kenneth Knowles wrote:
> > Forking discussion on
> >
> >   - Some folks have 100+ issues assigned
> >   - Jira components might not be the best way to get things triaged
> >
> > I just ran a built-in Jira report to summarize how many tickets are
> claimed by
> > different users [1]. It does look like component owners tend to
> accumulate
> > issues and they are not likely to get addressed.
> >
> > So what do we want and how can we make it happen? Here is what I want,
> personally:
> >
> >   - every new issue gets looked at by someone who can decide the right
> > component, who to ping, etc
> >   - no person is assigned an issue that they are not active on
> >   - we don't release with potential bugs waiting to be triaged
> >
> > The current status it that issues get assigned to a component owner when
> filed.
> > The component owner should route it and it most likely will end up in
> some
> > component unassigned.
> >
> > Another possibility is that we add a "Needs Triage" status and figure
> out a way
> > to make sure they are all looked at - maybe also by blocking a release
> on having
> > zero Needs Triage bugs. Just an idea.
> >
> > And important question I did not look into: what do other Apache or
> Apache-style
> > decentralized projects do?
> >
> > Kenn
> >
> > [1]
> >
> https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12343976&statistictype=assignees&selectedProjectId=12319527&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Apie-report&atl_token=A5KQ-2QAV-T4JA-FDED%7C4ba43752834c87065a99ddea7c1ea92342aa%7Clin&Next=Next
>

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

[Maximilian Michels]

Hi Kenn,

As your data shows, default-assigning issues to a single person does not 
automatically solve triaging issues. Quite the contrary, it hides the triage 
status of an issue.


From the perspective of the Flink Runner, we used to auto-assign but we got rid 
of this. Instead, we monitor the newly coming issues and take actions. We also 
go through the old ones occasionally. I believe that works fine for us.


The Flink project itself also does not default-assign, newly created issues are 
unassigned. There are component leads overseeing issues. There is no guarantee 
that every issue gets triaged.


"Needs Triage" or or "Needs Review" (seems easier to understand of non-native 
speakers) sounds like a good addition, but it will not solve the problem that 
issues need to be curated and maintained after the initial triage. For example, 
I've seen issues not closed after they have been fixed via a PR. However, "Needs 
Triage" will ensure that all issues get looked at. This could be helpful for 
releases, if not-yet-triaged issues are looked at early enough.


I'd suggest to:

1) Change new issues to be Unassigned and to be in status "Needs Review"
2) Remove Assignees from all not-being-worked-on issues
3) Ensure that each component's unresolved issues get looked at regularly

I suppose how to do 3) effectively is an open question. I currently don't see a 
better way as to oversee each component by multiple committers, similar to the 
OWNERS idea that we once had. I think we should move the OWNERS information to a 
Wiki page to make ownership/maintainership more transparent and easier to change.


Thanks,
Max

On 08.01.19 16:30, Kenneth Knowles wrote:

Forking discussion on

  - Some folks have 100+ issues assigned
  - Jira components might not be the best way to get things triaged

I just ran a built-in Jira report to summarize how many tickets are claimed by 
different users [1]. It does look like component owners tend to accumulate 
issues and they are not likely to get addressed.


So what do we want and how can we make it happen? Here is what I want, 
personally:

  - every new issue gets looked at by someone who can decide the right 
component, who to ping, etc

  - no person is assigned an issue that they are not active on
  - we don't release with potential bugs waiting to be triaged

The current status it that issues get assigned to a component owner when filed. 
The component owner should route it and it most likely will end up in some 
component unassigned.


Another possibility is that we add a "Needs Triage" status and figure out a way 
to make sure they are all looked at - maybe also by blocking a release on having 
zero Needs Triage bugs. Just an idea.


And important question I did not look into: what do other Apache or Apache-style 
decentralized projects do?


Kenn

[1] 
https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12343976&statistictype=assignees&selectedProjectId=12319527&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Apie-report&atl_token=A5KQ-2QAV-T4JA-FDED%7C4ba43752834c87065a99ddea7c1ea92342aa%7Clin&Next=Next

[DISCUSS] (Forked thread) Beam issue triage & assignees

[Kenneth Knowles]

Forking discussion on

 - Some folks have 100+ issues assigned
 - Jira components might not be the best way to get things triaged

I just ran a built-in Jira report to summarize how many tickets are claimed
by different users [1]. It does look like component owners tend to
accumulate issues and they are not likely to get addressed.

So what do we want and how can we make it happen? Here is what I want,
personally:

 - every new issue gets looked at by someone who can decide the right
component, who to ping, etc
 - no person is assigned an issue that they are not active on
 - we don't release with potential bugs waiting to be triaged

The current status it that issues get assigned to a component owner when
filed. The component owner should route it and it most likely will end up
in some component unassigned.

Another possibility is that we add a "Needs Triage" status and figure out a
way to make sure they are all looked at - maybe also by blocking a release
on having zero Needs Triage bugs. Just an idea.

And important question I did not look into: what do other Apache or
Apache-style decentralized projects do?

Kenn

[1]
https://issues.apache.org/jira/secure/ConfigureReport.jspa?projectOrFilterId=filter-12343976&statistictype=assignees&selectedProjectId=12319527&reportKey=com.atlassian.jira.jira-core-reports-plugin%3Apie-report&atl_token=A5KQ-2QAV-T4JA-FDED%7C4ba43752834c87065a99ddea7c1ea92342aa%7Clin&Next=Next