beam-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Knowles <...@google.com>
Subject Re: [DISCUSS] (Forked thread) Beam issue triage & assignees
Date Fri, 11 Jan 2019 20:54:04 GMT
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> 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 <altay@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
>

Mime
View raw message