On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay <[email protected]> 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 <[email protected]> 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
