Hi Timo, Thanks for joining the discussion. All rules except the unassigned rule do not apply to Sub-Tasks actually (like deprioritization, closing). Additionally, activity on a Sub-Taks counts as activity for the parent. So, the parent ticket would not be touched by the bot as long as there is a single Sub-Task that has a discussion or an update. If you experience something different, this is a bug.
Is there a reason why it is important to assign all Sub-Tasks to the same person immediately? I am not sure if this kind "reserving tickets" is a good idea in general to be honest. Cheers, Konstantin On Fri, May 21, 2021 at 12:00 PM Timo Walther <twal...@apache.org> wrote: > Hi Konstantin, > > thanks for starting this discussion. I was also about to provide some > feedback because I have the feeling that the bot is too aggressive at > the moment. > > Even a 14 days interval is a short period of time for bigger efforts > that might include several subtasks. Currently, if we split an issue > into subtasks usually most subtasks are assigned to the same person. But > the bot requires us to update all subtasks again after 7 days. Could we > disable the bot for subtasks or extend the period to 30 days? > > The core problem in the past was that we had issues laying around > untouched for years. Luckily, this is solved with the bot now. But going > from years to 7 days spams the mail box quite a bit. > > Regards, > Timo > > > On 21.05.21 09:22, Konstantin Knauf wrote: > > Hi Robert, > > > > Could you elaborate on your comment on test instabilities? Would test > > instabilities always get a fixVersion then? > > > > Background: Test instabilities are supposed to be Critical. Critical > > tickets are deprioritized if they are unassigned and have not received an > > update for 14 days. > > > > Cheers, > > > > Konstantin > > > > > > > > On Thu, May 20, 2021 at 9:34 AM Robert Metzger <rmetz...@apache.org> > wrote: > > > >> +1 > >> This would also cover test instabilities, which I personally believe > should > >> not be auto-deprioritized until they've been analyzed. > >> > >> On Wed, May 19, 2021 at 1:46 PM Till Rohrmann <trohrm...@apache.org> > >> wrote: > >> > >>> I like this idea. +1 for your proposal Konstantin. > >>> > >>> Cheers, > >>> Till > >>> > >>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf < > >> konstan...@ververica.com > >>>> > >>> wrote: > >>> > >>>> Hi everyone, > >>>> > >>>> Till and I recently discussed whether we should disable the > >>>> "stale-blocker", "stale-critical", "stale-major" and "stale-minor" > >> rules > >>>> for tickets that have a fixVersion set. This would allow people to > plan > >>> the > >>>> upcoming release without tickets being deprioritized by the bot during > >>> the > >>>> release cycle. > >>>> > >>>> From my point of view, this is a good idea as long as we can agree to > >> use > >>>> the "fixVersion" a bit more conservatively. What do I mean by that? If > >>> you > >>>> would categorize tickets planned for an upcoming release into: > >>>> > >>>> * Must Have > >>>> * Should Have > >>>> * Nice-To-Have > >>>> > >>>> only "Must Have" and "Should Have" tickets should get a fixVersion. > >> From > >>> my > >>>> observation, we currently often set the fixVersion if we just wished a > >>>> feature was included in an upcoming release. Similarly, I often see > >> bulk > >>>> changes of fixVersion that "roll over" many tickets to the next > release > >>> if > >>>> they have not made into the previous release although there is no > >>> concrete > >>>> plan to fix them or they have even become obsolete by then. Excluding > >>> those > >>>> from the bot would be counterproductive. > >>>> > >>>> What do you think? > >>>> > >>>> Cheers, > >>>> > >>>> Konstantin > >>>> > >>>> > >>>> On Fri, Apr 23, 2021 at 2:25 PM Konstantin Knauf <kna...@apache.org> > >>>> wrote: > >>>> > >>>>> Hi everyone, > >>>>> > >>>>> After some offline conversations, I think, it makes sense to already > >>> open > >>>>> this thread now in order to collect feedback and suggestions around > >> the > >>>>> Jira Bot. > >>>>> > >>>>> The following two changes I will do right away: > >>>>> > >>>>> * increase "stale-assigned.stale-days" to 14 days (Marta, Stephan, > >> Nico > >>>>> have provided feedback that this is too aggressive). > >>>>> > >>>>> * exclude Sub-Tasks from all rules except the "stale-assigned" rule > >> (I > >>>>> think, this was just an oversight in the original discussion.) > >>>>> > >>>>> Keep it coming. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Konstantin > >>>>> > >>>>> -- > >>>>> > >>>>> Konstantin Knauf > >>>>> > >>>>> https://twitter.com/snntrable > >>>>> > >>>>> https://github.com/knaufk > >>>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Konstantin Knauf | Head of Product > >>>> > >>>> +49 160 91394525 > >>>> > >>>> > >>>> Follow us @VervericaData Ververica <https://www.ververica.com/> > >>>> > >>>> > >>>> -- > >>>> > >>>> Join Flink Forward <https://flink-forward.org/> - The Apache Flink > >>>> Conference > >>>> > >>>> Stream Processing | Event Driven | Real Time > >>>> > >>>> -- > >>>> > >>>> Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany > >>>> > >>>> -- > >>>> Ververica GmbH > >>>> Registered at Amtsgericht Charlottenburg: HRB 158244 B > >>>> Managing Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl > >> Anton > >>>> Wehner > >>>> > >>> > >> > > > > > > -- Konstantin Knauf https://twitter.com/snntrable https://github.com/knaufk
