Hi everyone, Thank you for the additional comments and suggestions.
@Stephan, Kurt: I agree that we shouldn't discourage or dishearten contributors, and probably 14 days until a ticket becomes "stale-assigned" are too few. That's why I've already proposed to increase that to 30 days. Similarly the times for Major/Critical tickets can be increased. From my perspective, the root causes are the following: * tickets are opened with the wrong priority (see https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process#FlinkJiraProcess-TicketsPriorities). Here it might help to change the default priority. * committers don't have the time to review tickets or don't bring community contributions to a resolution. The Jira bot makes this fact more visible. Without the Jira Bot no external contributor would get more attention, and no external contribution would be merged faster. Ideally, it'd be the opposite and committers would actively monitor tickets with labels "stale-assigned" and "pull-request-available" in order to review those with priority. That's also why I am not a fan of excluding tickets with "pull-request-available" from the bot. The bot can help to make these tickets visible to reviewers. @Jing Zhang: That's a problem. We should try to change the permissions accordingly or need to find a different solution. @Piotr, Kurt: Instead of closing tickets, we could introduce an additional priority like "Not a Priority" to which we move tickets. No ticket would be closed automatically. Overall, the following changes could resolve most of the concerns, I believe: * 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) * Introduce "Not a Priority" priority and stop closing tickets. * Change default priority for new tickets of Flink project to "Minor" The measures, I proposed above, still try to achieve the goals mentioned and agreed upon in the original discussion thread, which were the following: - clearer communication and expectation management with the community - a user or contributor should be able to judge the urgency of a ticket by its priority - if a ticket is assigned to someone the expectation that someone is working on it should hold - generally reduce noise in Jira - reduce overhead of committers to ask about status updates of contributions or bug reports - “Are you still working on this?” - “Are you still interested in this?” - “Does this still happen on Flink 1.x?” - “Are you still experiencing this issue?” - “What is the status of the implementation”? - while still encouraging users to add new tickets and to leave feedback about existing tickets Kurt, Stephan, if you'd like to change the bot to "just close very old tickets", I suggest you start a separate discussion and subsequent voting thread. Best, Konstantin On Wed, Jun 30, 2021 at 9:01 AM Kurt Young <ykt...@gmail.com> wrote: > +1 to Stephan's opinion, with just one minor difference. For my experience > and a project > as big as Flink, picking up an issue created 1-2 years ago seems normal to > me. To be more > specific, during the blink planner merge, I created lots of clean up & > refactor issues, trying > to make the code be more clean. I haven't had a chance to resolve all these > but I think they are > still good improvements. Thus I would propose we don't close any stall > issues for at least 2 years. > > Best, > Kurt > > > On Wed, Jun 30, 2021 at 7:22 AM Stephan Ewen <se...@apache.org> wrote: > > > Being a bit late to the party, and don't want to ask to change > everything, > > just maybe some observation. > > > > My main observation and concern is still that this puts pressure and > > confusion on contributors, which are mostly blocked on committers for > > reviews, or are taking tickets as multi-week projects. I think it is not > a > > great experience for contributors, when they are already unsure why their > > work isn't getting the attention from committers that they hoped for, to > > then see issues unassigned or deprioritized automatically. I think we > > really need to weigh this discouragement of contributors against the > desire > > for a tidy ticket system. > > I also think by now this isn't just a matter of phrasing the bot's > message > > correctly. Auto unassignment and deprioritization sends a subtle message > > that jira resolution is a more important goal than paying attention to > > contributors (at least I think that is how it will be perceived by many). > > > > Back to the original motivation, to not have issues lying around forever, > > ensuring there is closure eventually. > > For that, even much longer intervals would be fine. Like pinging every > > three months, closing after three pings - would resolve most tickets in a > > year, which is not too bad in the scope of a project like Flink. Many > > features/wishes easily move to two releases in the future, which is > almost > > a year. We would get rid of long dead tickets and interfere little with > > current tickets. Contributors can probably understand ticket closing > after > > a year of inactivity. > > > > I am curious if a very simple bot that really just looks at stale issues > > (no comment/change in three months), pings the > > issue/reporter/assignee/watchers and closes it after three pings would do > > the job. > > We would get out of the un-assigning business (which can send very tricky > > signals) and would rely on reporters/assignees/watchers to unassign if > they > > see that the contributor abandoned the issue. With a cadence of three > > months for pinging, this isn't much work for the ones that get pinged. > > > > Issues where we rely on faster handling are probably the ones where > > committers have a stake in getting those into an upcoming release, so > these > > tend to be watched anyways. > > > > On Wed, Jun 23, 2021 at 2:39 PM JING ZHANG <beyond1...@gmail.com> wrote: > > > > > 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 > > > > > > > > > > -- Konstantin Knauf https://twitter.com/snntrable https://github.com/knaufk
