+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 >
