I'm sure this is possible. I made a (personal) call to not do it. I think using words in a comment to communicate is the most important thing. I don't want automated updates to reset things. I definitely don't want to reset it unless the action causes a notification to watchers. Silently grabbing and fixing a bug will very rarely take long enough that it gets unassigned or downgraded. And anyhow removing the label and commenting "working on it" is very easy.
These are just my thoughts. I'm happy to do whatever the community wants. Kenn On Tue, Jun 16, 2020 at 12:21 PM Brian Hulette <bhule...@google.com> wrote: > Sorry if you already looked into this, but is it possible to reset the > counter based on anything in the "activity" tab? It looks like ASF GitHub > Bot is always doing things whenever there's activity on a linked PR. So we > wouldn't need to call out to GitHub to check for PR activity. > > On Tue, Jun 16, 2020 at 11:49 AM Kenneth Knowles <k...@apache.org> wrote: > >> 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 >>>>>>>>>>> > >> >>>>>>>>>>> > > >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>
