I agree that we shouldn't discourage contributions. For me the main idea of the bot is not to clean up the JIRA but to improve our communication and expectation management with the community. There are many things we could do but for a lot of things we don't have the time and capacity. Then to say at some point that we won't do something is just being honest. This also shows when looking at the JIRA numbers of the merged commits. We very rarely resolve tickets which are older than x days and if we do, then we usually create a new ticket for the problem.
The fact that we see some tickets with available pull requests go stale is the symptom that we don't value them to be important enough or allocate enough time for external contributions imo. Otherwise, they would have gotten the required attention and been merged. In such a case, raising awareness by pinging the watchers of the respective ticket is probably better than silently ignoring the PR. Also adding labels to filter for these PRs should help to get them the required attention. But also here, it happens very rarely that we actually merge a PR that is older than y days. Ideally we avoid this situation altogether by only assigning contributors to tickets for which a committer has review capacity. However, this does not seem to always work. In some sense, the JIRA bot shows us the things, which fall through the cracks, more explicitly (which is probably not different than before). Of course we should try to find the time periods for when to ping or de-prioritize tickets that work best for the community. +1 for the proposed changes (extended time periods, "Not a Priority", default priority and fixVersion). @Piotr, I think we have the priorities defined here [1]. Maybe it is enough to share the link so that everyone can check whether her assumptions are correct. [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process Cheers, Till On Wed, Jun 30, 2021 at 10:59 AM Piotr Nowojski <pnowoj...@apache.org> wrote: > > * 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 > > >
