> * Introduce "Not a Priority" priority and stop closing tickets.
+1 for this one (I also like the name you proposed for this Konstantin) I also have no objections to other proposals that you summarised. Just a remark, that independently of this discussion we might want to revisit or reconfirm the priorities and their definition/interpretation across all contributors. Best, Piotrek śr., 30 cze 2021 o 10:15 Konstantin Knauf <kna...@apache.org> napisał(a): > 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 >
