+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
