Hi Konstantin, Chesnay, > 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.
I agree with Chesnay about not un-assign an issue if a PR is open. Besides, Could assignees remove the "stale-assigned" tag by themself? It seems assignees have no permission to delete the tag if the issue is not created by themselves. Best regards, JING ZHANG Konstantin Knauf <konstan...@ververica.com> 于2021年6月23日周三 下午4:17写道： > > 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 >
