+1 for the automations. I agree with concerns related to #4. Auto closing issues is not a good experience. A person goes through the work of reporting an issue. This might very well be their first contribution. Automatically closing these issues with no human comments might make the reporter feel ignored. Auto-lowering the priority is a good suggestion.
I wonder if we can also do a spring cleaning up reviewing jira components/their default owners. If we can break the jira into more components, we could have more people as component owners, triaging smaller per-component backlogs. On Wed, Apr 29, 2020 at 11:17 AM Tyson Hamilton <tyso...@google.com> wrote: > +1 for automation. > > Regarding #4, what about adding the constraint that this rule only applies > to issues that are incomplete and require more information from the > reporter? > > Unfortunately it would require a human to triage issues to determine this > and apply an appropriate label. Triage should happen regularly anyways, > ideally even periodically for old issues, though this may be asking a bit > too much. > Even with automation, manual triaging would be a valuable action. If the automation can reduce the backlog for manual reviewers, doing manual triage would be easier to do, incremental work. > > Regarding #5 & #6, having some SLO for P0/P1 issues for both updates and > closures would be helpful in setting expectations. A daily P0 violation > email to dev@ sounds right, for P1 weekly. What would the Slack > notification look like? It would be neat if it could ping the assignee > directly. What group would be victims for the auto-assigner? > I agree with this. Email, or a dashboard would work equally well. (We need to first agree on SLOs though.) > > On 2020/04/29 17:15:48, Brian Hulette <bhule...@google.com> wrote: > > Agree I think this all sounds good except for 4. > > > > I like the idea of using automation to help tame the backlog of jiras, > but > > I worry that 4 could lead to a bad experience for users. Say they file a > > jira and maybe get it assigned, and then watch as it bounces all the way > > down to closed as obsolete because it was ignored. > > The status quo (the bug just gets ignored anyway) isn't great, but at > least > > the user doesn't have automation working against them. > > > > Is there something else we can do to make sure these bugs get attention? > > > > Brian > > > > > > On Wed, Apr 29, 2020 at 10:00 AM Robert Bradshaw <rober...@google.com> > > wrote: > > > > > +1 to more automation. > > > > > > I'm in favor of all but 4, I think it's quite common for issues to be > > > noticed but not worked on for 60+ days. Most of the time when a > developer > > > files an issue they either (1) are working on it right now or (2) are > > > filing it away because it's something they're not working on, but > should > > > get fixed. (Case in point, beginner issues that are not urgent but > nice to > > > have.) What we could do however is lower the priority after a set > amount of > > > time. (I suppose issues are a mix of blockers and backlog, and the two > > > have very different characteristics.) > > > > > > On Wed, Apr 29, 2020 at 9:38 AM Kenneth Knowles <k...@apache.org> > wrote: > > > > > >> Hi all, > > >> > > >> A while ago [1], we discussed using "Automation for Jira" to improve > > >> triage and backlog processing (I spend a lot of my time on this). Due > to > > >> some friction [2] [3] back then, I did not finish it. > > >> > > >> Now, I just happened to check and I do have the ability to create > rules > > >> directly. That's convenient! > > >> > > >> So I want to re-propose some of the ideas that Ismaël had, slightly > > >> modified, along with some other ideas I have from my experience doing > a lot > > >> of Jira handling. I will say it in specific rule form: > > >> > > >> 1. When issue created: if assignee == creator then mark Open (already > > >> Triaged), because someone is probably just filing a bug tracking work > they > > >> already started. > > >> > > >> 2. When issue linked to PR: mark it Open (already Triaged). *The > triggers > > >> should exist but seem to be missing. > > >> > > >> 3a. When assigned issue has no update in 30 days, add "stale-assigned" > > >> label > > >> 3b. When issue with "stale-assigned" label has no update in 7 days, > > >> unassign > > >> > > >> 4a. When unassigned issue has no update in 60 days, add "stale" label > > >> 4b. When issue with "stale" label has no update in 14 days, close as > > >> Obsolete > > >> > > >> And I think we can also use this to improve visibility and > understanding > > >> of expectation of high priority issues, per > > >> https://beam.apache.org/contribute/jira-priorities/ > > >> > > >> 5. Some kind of daily alert for P0 "Blocker" issues, because these are > > >> outages. The community is being blocked *right now* so it should have > dev@ > > >> visibility and at least daily updates (probably more). Options > include dev@ > > >> email, Slack notification, etc. > > >> > > >> 6. Some kind of alert or auto-assign for P1 "Critical" issues, because > > >> these aren't an outage but they would hinder a release. > > >> > > >> And, finally, they can also automate some aspects of release busywork: > > >> > > >> 7. When a version is released, it can create the n+2 version. Example: > > >> when 2.20.0 is being released, we already have 2.21.0 and move issues > to > > >> it. When 2.20.0 is finalized, create 2.22.0 so it is ready to have > issues > > >> moved to it. > > >> > > >> 8. We could have an automatic comment on bugs filed at P0 or P1 or > with > > >> Fix Version set to explain the special community awareness that they > imply. > > >> > > >> What do you think of each of these rules? Especially if you have > ideas of > > >> how to finish the ones that I left as just ideas. > > >> > > >> Kenn > > >> > > >> [1] > > >> > https://lists.apache.org/thread.html/125851639b2f5c2ee55a9eb6b27cf07adee48e2d2a4e5157609b3132%40%3Cdev.beam.apache.org%3E > > >> [2] > > >> > https://lists.apache.org/thread.html/ff221c1de7163ef073494cb8873a523ef9f487d7275ec8ae41e91f23%40%3Cdev.beam.apache.org%3E > > >> [3] > > >> > https://issues.apache.org/jira/browse/INFRA-17756?focusedCommentId=16790143&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16790143 > > >> > > > > > >
