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 <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 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 <sweg...@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.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 <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 <m...@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 >> >
