+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. 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? 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 > >> > > >
