While we work with infra on this, let's remove the broken system and use tags. It is important that issues coming in are known to be untriaged, so instead of a "Needs Triage" label, we should use "triaged". So I will take these actions that everyone seems to agree on:
- Remove default assignment from Jira configs - Unassign all issues from people with a huge number - Add "triaged" tag to issues that are assigned and have some meaningful recent activity I will use trial-and-error to figure out what looks OK for "huge number" and "meaningful recent activity". Kenn On Fri, Jan 11, 2019 at 3:20 PM Kenneth Knowles <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 < >>> [email protected]> 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 <[email protected]> >>>> wrote: >>>> >>>>> 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 >>>>> >>>> >>> >>> -- >>> >>> >>> >>> >>> Got feedback? tinyurl.com/swegner-feedback >>> >>
