On Wed, Jun 17, 2020 at 3:13 PM Robert Burke <rob...@frantil.com> wrote:
> It may be very easy, but commenting in addition to self assignment is also > not yet part of the official process, while the assignment/unassignment is > already visible to watchers based on deluge of emails I've been getting as > older issues have been unassigned from me. > > I'd say assignment needs to be a signal to the automation based on that > experience, if it isn't already. > Very good point. The clock should start when someone is assigned an issue, and reset when it changes hands. Just did a minute of quick research and it does look like this may not be expressible in JQL, so we might have to go with time since any change. > That said i agree with Kenn that the automatic touch by the bot isn't > sufficient to determine if the person assigned the issue is actually > working on it or not. The bot is only looking for a matching JIRA ID on the > PR title nd it's not checking if said PR is authored by the person to whom > the JIRA is assigned. > > I'm personally bad at closing issues after a resolution PR, but that can't > be made automatic anyway. I've been reminding authors to resolve the > associated JIRA as appropriate to build the habit. > Another issue in vanilla JQL: cannot search for Jiras in this state and at least ping them. You need a human to decide the PR really finished it, for sure. There's add ons we could go with to do more but I wanted to get some more experience. Kenn > On Wed, Jun 17, 2020, 1:57 PM Kenneth Knowles <k...@apache.org> wrote: > >> 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 >>>>>>>>>>>>> > >> >>>>>>>>>>>>> > > >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>
