Hi everyone, ok, let's in addition try out not unassigning anyone from tickets. This makes it the responsibility of the component maintainers to periodically check for stale-unassigned tickets and bring them to a resolution. We can monitor the situation (# of stale-unassigned tickets) and if the number of open stale-unassigned tickets is ever increasing, we need to revisit this topic.
For reference here are the tickets for the adjustments: * https://issues.apache.org/jira/browse/FLINK-23207 (PR available) * https://issues.apache.org/jira/browse/FLINK-23206 (blocked by INFRA) * https://issues.apache.org/jira/browse/FLINK-23205 (merged) * https://issues.apache.org/jira/browse/FLINK-23250 (open) Cheers, Konstantin On Fri, Jul 2, 2021 at 9:43 AM Piotr Nowojski <pnowoj...@apache.org> wrote: > +1 for the unassignment remark from Stephan > > Piotrek > > czw., 1 lip 2021 o 12:35 Stephan Ewen <se...@apache.org> napisał(a): > > > It is true that the bot surfaces problems that are there (not enough > > committer attention sometimes), but it also "rubs salt in the wound" of > > contributors, and that is tricky. > > > > We can try it out with the extended periods (although I think that in > > reality we probably need even longer periods) and see how it goes. > > > > One thing I would suggest is to never let the bot unassign issues. It > just > > strikes me as very cold and respectless to be unassigned by a bot from an > > issue in which I invested time and energy. (The committers don't even > take > > the time to talk to me and explain why the contribution will not go > > forward). > > Unassignment should come from another person, possibly in response to a > > ping from the bot. I think that makes a big difference in contributor > > treatment. > > > > > > > > On Wed, Jun 30, 2021 at 12:30 PM Till Rohrmann <trohrm...@apache.org> > > wrote: > > > > > 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 > > > > > > > > > > > > > > > -- Konstantin Knauf https://twitter.com/snntrable https://github.com/knaufk
