Based on the mild consensus and my availability, I just did #1. I have not done any others. It seems #2 may be infeasible [1] and I am convinced that we should not auto-close. I'll update again in a bit...
Kenn [1] https://jira.atlassian.com/browse/JRACLOUD-28064 On Wed, Apr 29, 2020 at 2:54 PM Ahmet Altay <al...@google.com> wrote: > +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 >> > >> >> > > >> > >> >
