One thing I noticed is that links being added to issues automatically (e.g. a PR is opened that tags something) doesn't reset the activity counter so things are marked stale even though there are PRs opened for the issue recently.
On Thu, Jun 11, 2020 at 10:37 AM Kenneth Knowles <k...@apache.org> wrote: > 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 <bhule...@google.com> 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 <k...@apache.org> 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 <k...@apache.org> 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 <k...@apache.org> 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 <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 >>>>>>> > >> >>>>>>> > > >>>>>>> > >>>>>>> >>>>>>
