Can we revisit #5 and #6? We have 8 open unassigned P0s [1] and 96 open unassigned P1s [2]. Auto-assigning to a pool of people could be a good way to get them triaged. A couple of questions: 1) Can we actually do this with rules in Jira? 2) Who would be in the pool of stuckees and how could it be maintained? All committers seems too broad. Maybe there could be a "beam-triagers" group that people can opt-in to?
Brian [1] https://issues.apache.org/jira/browse/BEAM-10270?filter=12349888 [2] https://issues.apache.org/jira/browse/BEAM-9154?filter=12349889 On Wed, Jun 17, 2020 at 8:43 PM Kenneth Knowles <k...@apache.org> wrote: > > > 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 >>>>>>>>>>>>>>> > >> >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>
