On Wed, Jun 17, 2020 at 8:40 PM Kenneth Knowles <k...@apache.org> wrote:
> > 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. > I've changed the "stale-assigned" rule from last public comment to last update. TBH I don't know what falls under the category of "update" but I expect it is the greatest overapproximation available. Kenn > 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 >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>
