Hi Kenn, For my information... is the Needs Triage status automatically assigned to new issues? Are users expected to give their issue the Needs Triage status when they create it? Thanks -P.
On Wed, May 1, 2019 at 11:12 AM Kenneth Knowles <[email protected]> wrote: > An update here: we have the new workflow in place. I have transitioned > untriaged issues to the "Needs Triage" status" so they are very easy to > find, and removed the obsolete triaged label. > > Please help to triage! You can just look at all issues with the Needs > Triage status and make sure it is in the right component and priority makes > sense, and maybe alert someone who might want to know about it. > > Kenn > > On Mon, Mar 4, 2019 at 9:23 AM Kenneth Knowles <[email protected]> wrote: > >> This effort to improve our triage is still ongoing. To recall: >> >> Issues are no longer automatically assigned, so we have to watch them! >> >> Here's a saved search for issues needing triage: >> https://issues.apache.org/jira/issues/?filter=12345682 >> >> Anyone can help out. Just make sure the issue is in a suitable component >> and someone is assigned or mentioned so they'll get a notification, then >> add the "triaged" tag. >> >> You can also subscribe to the filter to watch incoming issues. >> >> Kenn >> >> On Wed, Feb 6, 2019 at 9:04 PM Kenneth Knowles <[email protected]> wrote: >> >>> 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 <[email protected]> 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 <[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 >>>>>>> >>>>>>
