I like this idea. It would then be the responsibility of the component maintainers to manage the lifecycle explicitly.
Cheers, Till On Mon, Jun 7, 2021 at 1:48 PM Arvid Heise <ar...@apache.org> wrote: > 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 > > >
