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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>>>> 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 <
>>>>> [email protected]> 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 <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay <[email protected]>
>>>>>>> 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 <[email protected]>
>>>>>>> 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
>>>>>
>>>>
