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 2019/02/07 04:15:08 UTC
Re: [DISCUSS] (Forked thread) Beam issue triage & assignees
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 <ke...@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 <kl...@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 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 <sw...@google.com> 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.mikhail@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 <ro...@google.com>
>>>> wrote:
>>>>
>>>>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay <al...@google.com> 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 <mx...@apache.org>
>>>>> 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%7C4ba437528000034c87065a99ddea7c1ea92342aa%7Clin&Next=Next
>>>>>
>>>>
>>>
>>> --
>>>
>>>
>>>
>>>
>>> Got feedback? tinyurl.com/swegner-feedback
>>>
>>
Re: [DISCUSS] (Forked thread) Beam issue triage & assignees
Posted by Maximilian Michels <mx...@apache.org>.
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 <pabloem@google.com
> <ma...@google.com>> 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 <kenn@apache.org
> <ma...@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 <kenn@apache.org
> <ma...@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
> <kenn@apache.org <ma...@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
> <kenn@apache.org <ma...@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
> <kenn@apache.org <ma...@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
> <klk@google.com <ma...@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 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 <swegner@google.com
> <ma...@google.com>> 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.mikhail@gmail.com
> <ma...@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 <robertwb@google.com
> <ma...@google.com>> wrote:
>
> On Thu, Jan 10, 2019 at 3:20 AM
> Ahmet Altay <altay@google.com
> <ma...@google.com>> 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
> <mxm@apache.org
> <ma...@apache.org>> 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%7C4ba437528000034c87065a99ddea7c1ea92342aa%7Clin&Next=Next
>
>
>
> --
>
>
>
>
> Got feedback?
> tinyurl.com/swegner-feedback
> <https://tinyurl.com/swegner-feedback>
>
Re: [DISCUSS] (Forked thread) Beam issue triage & assignees
Posted by Kenneth Knowles <ke...@apache.org>.
Yes, new issues should have that status. And a correction: it is "Triage
Needed"
On Wed, May 1, 2019, 11:39 Pablo Estrada <pa...@google.com> 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 <ke...@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 <ke...@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 <ke...@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 <ke...@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 <ke...@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 <kl...@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 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 <sw...@google.com>
>>>>>>> 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.mikhail@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 <
>>>>>>>>> robertwb@google.com> wrote:
>>>>>>>>>
>>>>>>>>>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay <al...@google.com>
>>>>>>>>>> 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 <
>>>>>>>>>> mxm@apache.org> 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%7C4ba437528000034c87065a99ddea7c1ea92342aa%7Clin&Next=Next
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Got feedback? tinyurl.com/swegner-feedback
>>>>>>>>
>>>>>>>
Re: [DISCUSS] (Forked thread) Beam issue triage & assignees
Posted by Pablo Estrada <pa...@google.com>.
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 <ke...@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 <ke...@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 <ke...@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 <ke...@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 <ke...@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 <kl...@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 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 <sw...@google.com>
>>>>>> 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.mikhail@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 <
>>>>>>>> robertwb@google.com> wrote:
>>>>>>>>
>>>>>>>>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay <al...@google.com>
>>>>>>>>> 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 <
>>>>>>>>> mxm@apache.org> 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%7C4ba437528000034c87065a99ddea7c1ea92342aa%7Clin&Next=Next
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Got feedback? tinyurl.com/swegner-feedback
>>>>>>>
>>>>>>
Re: [DISCUSS] (Forked thread) Beam issue triage & assignees
Posted by Kenneth Knowles <ke...@apache.org>.
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 <ke...@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 <ke...@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 <ke...@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 <ke...@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 <kl...@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 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 <sw...@google.com>
>>>>> 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.mikhail@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 <
>>>>>>> robertwb@google.com> wrote:
>>>>>>>
>>>>>>>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay <al...@google.com>
>>>>>>>> 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 <
>>>>>>>> mxm@apache.org> 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%7C4ba437528000034c87065a99ddea7c1ea92342aa%7Clin&Next=Next
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Got feedback? tinyurl.com/swegner-feedback
>>>>>>
>>>>>
Re: [DISCUSS] (Forked thread) Beam issue triage & assignees
Posted by Kenneth Knowles <ke...@apache.org>.
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 <ke...@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 <ke...@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 <ke...@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 <kl...@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 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 <sw...@google.com>
>>>> 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.mikhail@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 <ro...@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay <al...@google.com>
>>>>>>> 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 <mx...@apache.org>
>>>>>>> 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%7C4ba437528000034c87065a99ddea7c1ea92342aa%7Clin&Next=Next
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Got feedback? tinyurl.com/swegner-feedback
>>>>>
>>>>
Re: [DISCUSS] (Forked thread) Beam issue triage & assignees
Posted by Kenneth Knowles <ke...@apache.org>.
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 <ke...@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 <ke...@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 <kl...@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 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 <sw...@google.com>
>>> 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.mikhail@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 <ro...@google.com>
>>>>> wrote:
>>>>>
>>>>>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay <al...@google.com> 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 <mx...@apache.org>
>>>>>> 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%7C4ba437528000034c87065a99ddea7c1ea92342aa%7Clin&Next=Next
>>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>> Got feedback? tinyurl.com/swegner-feedback
>>>>
>>>