Yes, new issues should have that status. And a correction: it is "Triage Needed"
On Wed, May 1, 2019, 11:39 Pablo Estrada <pabl...@google.com> wrote: > 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 <k...@apache.org> 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 <k...@apache.org> 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 <k...@apache.org> 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 <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 >>>>>>>> >>>>>>>
