> I don't understand why we are necessarily losing discussion/knowledge. The > tickets are still there, just in "Closed" state, which are included in > default Jira search.
Finding if there already has been a ticket opened for the given issue is not always easy. Finding the right ticket among 23086 is 7 times as difficult/time consuming as among 3305 open tickets. If a piece of knowledge/discussion is not easily accessible, it's effectively lost. > We could of course just add a label, but closing seems > clearer to me given that likely this ticket will not get comitter attention > in the foreseeable future. There are tickets that are waiting to get enough traction (bugs, improvements, ideas, test instabilities). I know plenty of those. If they are being brought up frequently enough, they will finally get the needed attention. Until this happens, I don't like to be losing the descriptions, previous discussions and/or a frequency of past occurrences. Can I ask, why do you think it makes sense to be closing those tickets besides it "being clearer" to you? What use case is justifying this? And I don't agree it's clearer. If the issue is still there, it shouldn't be in the "CLOSED" state. > Can you elaborate which rules you are running into mostly? I'd rather like > to understand how we work right now and where this conflicts with the Jira > bot vs slowly disabling the jira bot via labels. I didn't count them, but I think stale critical -> stale major -> stale minor -> auto closing I'm getting the most. If a ticket is not relevant anymore I've learned to manually close it/clean up immediately once the jira-bot pings about it regardless of the priority. But so far, I've closed fewer tickets than I was forced to re-open. Maybe this is because I'm tracking all of the tickets that are of interest to my team? Maybe others are not doing that and that's why you are not seeing this problem that I'm having? But keep in mind. I don't mind about auto deprioritization. It's fair to say that tickets get automatically deprioritised if they have no attention. But why do we have to automatically close the least priority ones? Maybe another idea. Instead of disabling closing the tickets via some label, we could also achieve the same thing with a dedicated lowest priority state "on hold"/"frozen". Piotrek śr., 23 cze 2021 o 10:17 Konstantin Knauf <konstan...@ververica.com> napisał(a): > > I agree there are such tickets, but I don't see how this is addressing my > concerns. There are also tickets that just shouldn't be closed as I > described above. Why do you think that duplicating tickets and losing > discussions/knowledge is a good solution? > > I don't understand why we are necessarily losing discussion/knowledge. The > tickets are still there, just in "Closed" state, which are included in > default Jira search. We could of course just add a label, but closing seems > clearer to me given that likely this ticket will not get comitter attention > in the foreseeable future. > > > I would like to avoid having to constantly fight against the bot. It's > already responsible for the majority of my daily emails, with quite little > benefit for me personally. I initially thought that after some period of > time it will settle down, but now I'm afraid it won't happen. > > Can you elaborate which rules you are running into mostly? I'd rather like > to understand how we work right now and where this conflicts with the Jira > bot vs slowly disabling the jira bot via labels. > > On Wed, Jun 23, 2021 at 10:00 AM Piotr Nowojski <pnowoj...@apache.org> > wrote: > > > Hi Konstantin, > > > > > In my opinion it is important that we close tickets eventually. There > are > > a > > > lot of tickets (bugs, improvements, tech debt) that over time became > > > irrelevant, out-of-scope, irreproducible, etc. In my experience, these > > > tickets are usually not closed by anyone but the bot. > > > > I agree there are such tickets, but I don't see how this is addressing my > > concerns. There are also tickets that just shouldn't be closed as I > > described above. Why do you think that duplicating tickets and losing > > discussions/knowledge is a good solution? > > > > I would like to avoid having to constantly fight against the bot. It's > > already responsible for the majority of my daily emails, with quite > little > > benefit for me personally. I initially thought that after some period of > > time it will settle down, but now I'm afraid it won't happen. Can we add > > some label to mark tickets to be ignored by the jira-bot? > > > > Best, > > Piotrek > > > > śr., 23 cze 2021 o 09:40 Chesnay Schepler <ches...@apache.org> > napisał(a): > > > > > I would like it to not unassign people if a PR is open. These are > > > usually blocked by the reviewer, not the assignee, and having the > > > assignees now additionally having to update JIRA periodically is a bit > > > like rubbing salt into the wound. > > > > > > On 6/23/2021 7:52 AM, Konstantin Knauf wrote: > > > > Hi everyone, > > > > > > > > I was hoping for more feedback from other committers, but seems like > > this > > > > is not happening, so here's my proposal for immediate changes: > > > > > > > > * Ignore tickets with a fixVersion for all rules but the > > stale-unassigned > > > > role. > > > > > > > > * We change the time intervals as follows, accepting reality a bit > more > > > ;) > > > > > > > > * stale-assigned only after 30 days (instead of 14 days) > > > > * stale-critical only after 14 days (instead of 7 days) > > > > * stale-major only after 60 days (instead of 30 days) > > > > > > > > Unless there are -1s, I'd implement the changes Monday next week. > > > > > > > > Cheers, > > > > > > > > Konstantin > > > > > > > > On Thu, Jun 17, 2021 at 2:17 PM Piotr Nowojski <pnowoj...@apache.org > > > > > wrote: > > > > > > > >> 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 > > > >>>>> > > > > > > > > > > > > > > > -- > > 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 >
