I re-triaged most issues where the creation date != last update. I worked through everyone with more issues than myself (which I have triaged regularly) and a few people with a few fewer issues.
I didn't look as closely at issues that were filed by the assignee. So if you filed a bunch of issues that landed on yourself, take a look. If you have fewer than 30 issues assigned to you, please take a look at them now. Kenn On Wed, Feb 6, 2019 at 8:15 PM Kenneth Knowles <k...@apache.org> wrote: > 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 <k...@apache.org> 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 <k...@google.com> 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 <sweg...@google.com> >>> 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 < >>>> 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 >>>> >>>
