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