Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-05-02 Thread Maximilian Michels
Thanks for all the work Kenn. The new JIRA workflow is much better than the old label-based. -Max On 01.05.19 21:27, Kenneth Knowles wrote: Yes, new issues should have that status. And a correction: it is "Triage Needed" On Wed, May 1, 2019, 11:39 Pablo Estrada >

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-05-01 Thread Kenneth Knowles
Yes, new issues should have that status. And a correction: it is "Triage Needed" On Wed, May 1, 2019, 11:39 Pablo Estrada 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 >

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-05-01 Thread Pablo Estrada
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 wrote: > An update here: we have the new workflow in

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-05-01 Thread Kenneth Knowles
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

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-03-04 Thread Kenneth Knowles
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

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-02-06 Thread Kenneth Knowles
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

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-02-06 Thread Kenneth Knowles
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

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-01-11 Thread Kenneth Knowles
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 wrote: > It sounds

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-01-11 Thread Kenneth Knowles
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

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-01-10 Thread Scott Wegner
+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

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-01-10 Thread Mikhail Gryzykhin
+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 wrote: > On Thu, Jan 10,

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-01-10 Thread Robert Bradshaw
On Thu, Jan 10, 2019 at 3:20 AM Ahmet Altay 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,

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-01-09 Thread Ahmet Altay
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. On Wed, Jan 9, 2019 at 10:30 AM Maximilian Michels wrote: > Hi Kenn, > > As your data shows, default-assigning issues to a

Re: [DISCUSS] (Forked thread) Beam issue triage & assignees

2019-01-09 Thread Maximilian Michels
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

[DISCUSS] (Forked thread) Beam issue triage & assignees

2019-01-08 Thread Kenneth Knowles
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