Yes, new issues should have that status. And a correction: it is "Triage
Needed"
On Wed, May 1, 2019, 11:39 Pablo Estrada <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[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]
<mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>> wrote:
On Thu, Jan 10, 2019 at 3:20 AM
Ahmet Altay <[email protected]
<mailto:[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]
<mailto:[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
<https://tinyurl.com/swegner-feedback>
