Hi everyone, thank you for all the feedback so far. I believe we have four different topics by now:
1 about *test-instability tickets* raised by Robert. Waiting for feedback by Robert. 2 about *aggressiveness of stale-assigned *rule raised by Timo. Waiting for feedback by Timo and others. 3 about *excluding issues with a fixVersion* raised by Konstantin, Till. Waiting for more feedback by the community as it involves general changes to how we deal with fixVersion. 4 about *excluding issues with a specific-label* raised by Arvid. I've already written something about 1-3. Regarding 4: How do we make sure that these don't become stale? I think, there have been a few "long-term efforts" in the past that never got the attention that we initially wanted. Is this just about the ability to collect tickets under an umbrella to document a future effort? Maybe for the example of DataStream replacing DataSet how would this look like in Jira? Cheers, Konstantin On Tue, Jun 8, 2021 at 11:31 AM Till Rohrmann <trohrm...@apache.org> wrote: > 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 > > > > > > -- Konstantin Knauf https://twitter.com/snntrable https://github.com/knaufk
