Hi, I also think that the bot is a bit too aggressive/too quick with assigning stale issues/deprioritizing them, but that's not that big of a deal for me.
What bothers me much more is that it's closing minor issues automatically. Depriotising issues makes sense to me. If a wish for improvement or a bug report has been opened a long time ago, and they got no attention over the time, sure depriotize them. But closing them is IMO a bad idea. Bug might be minor, but if it's not fixed it's still there - it shouldn't be closed. Closing with "won't fix" should be done for very good reasons and very rarely. Same applies to improvements/wishes. Furthermore, very often descriptions and comments have a lot of value, and if we keep closing minor issues I'm afraid that we end up with: - more duplication. I doubt anyone will be looking for prior "closed" bug reports/improvement requests. Definitely I'm only looking for open tickets when looking if a ticket for XYZ already exists or not - we will be losing knowledge Piotrek śr., 16 cze 2021 o 15:12 Robert Metzger <rmetz...@apache.org> napisał(a): > Very sorry for the delayed response. > > Regarding tickets with the "test-instability" label (topic 1): I'm usually > assigning a fixVersion to the next release of the branch where the failure > occurred, when I'm opening a test failure ticket. Others seem to do that > too. Hence my comment that not checking tickets with a fixVersion set by > Flink bot is good (because test failures should always stay "Critical" > until we've understood what's going on) > I see that it is a bit contradicting that Critical test instabilities > receive no attention for 14 days, but that seems to be the norm given the > current number of incoming test instabilities. > > On Wed, Jun 16, 2021 at 2:05 PM Till Rohrmann <trohrm...@apache.org> > wrote: > > > Another example for category 4 would be the ticket where we collect > > breaking API changes for Flink 2.0 [1]. The idea behind this ticket is to > > collect things to consider when developing the next major version. > > Admittedly, we have never seen the benefits of collecting the breaking > > changes because we haven't started Flink 2.x yet. Also, it is not clear > how > > relevant these tickets are right now. > > > > [1] https://issues.apache.org/jira/browse/FLINK-3957 > > > > Cheers, > > Till > > > > On Wed, Jun 16, 2021 at 11:42 AM Konstantin Knauf <kna...@apache.org> > > wrote: > > > > > 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 > > > > > >
