One more idea for the bot. Could we have a label to exclude certain tickets from the life-cycle?
I'm thinking about long-term tickets such as improving DataStream to eventually replace DataSet. We would collect ideas over the next couple of weeks without any visible progress on the implementation. On Fri, May 21, 2021 at 2:06 PM Konstantin Knauf <kna...@apache.org> wrote: > 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 >
