Yes, my inbox is hit as well. I'm enjoying going through some old bugs actually. One takeaway is that we have a lot of early Jiras that are still relevant, and also that there are a lot of duplicates. I think some automation to help find duplicates might be helpful.
Also, some accidental automation humor: https://issues.apache.org/jira/browse/BEAM-6414 Kenn On Tue, Jun 2, 2020 at 8:39 AM Brian Hulette <[email protected]> wrote: > RIP my inbox :) > This is overwhelming, but I think it will be very good. Thanks for setting > this up Kenn. > > Brian > > On Mon, Jun 1, 2020 at 9:57 PM Kenneth Knowles <[email protected]> wrote: > >> I have now added modified 4: >> >> 4a. labeling stale-P2 for unassigned 60 day old jiras >> 4b. after 14 days downgrading stale-P2 labeled jiras to P3 >> >> On Mon, Jun 1, 2020 at 9:06 PM Kenneth Knowles <[email protected]> wrote: >> >>> I just added 3a and 3b. The comments will appear to be coming from me. >>> That is a misconfiguration that I have now fixed. In the future they will >>> come from the "Beam Jira Bot". There were 1119 stale-assigned issues. >>> >>> Kenn >>> >>> On Fri, May 1, 2020 at 1:41 PM Kenneth Knowles <[email protected]> wrote: >>> >>>> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> 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 < >>>>>> [email protected]> >>>>>> > 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 <[email protected]> >>>>>> 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 >>>>>> > >> >>>>>> > > >>>>>> > >>>>>> >>>>>
