Yes, only public comments reset the counter. On Mon, Jun 15, 2020 at 6:57 PM Udi Meiri <eh...@google.com> wrote:
> Interesting: you could consider the JIRA as active as long as the linked > PRs are open. > > On Mon, Jun 15, 2020 at 2:28 PM Luke Cwik <lc...@google.com> wrote: > >> 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 >>>>>>>>> > >> >>>>>>>>> > > >>>>>>>>> > >>>>>>>>> >>>>>>>>
