[DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf <kn...@apache.org>]

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

Re: [DISCUSS] Feedback Collection Jira Bot

[Timo Walther <tw...@apache.org>]

Hi everyone,

let me also post some feedback here. As someone who monitors and 
maintains the SQL component JIRA issues, I'm quite unhappy with the 
current bot behavior. I'm watching quite a few issues and SQL has a lot 
of pretty major if not critical topics. My mailbox is full of bot 
messages every day. And I also heard from other users, that they kind of 
disappointed that the bot deprioritized their valuable feedback.

I agree with Stephan and Kurt, a project like Flink has often tickets 
that span months to years. It might be just ideas where we select more 
input or bugs where we don't have an immediate solution or need to wait 
for more reports.

`stale-critical only after 14 days` is still not enought time. I know 
critical issues that are open for 6 months already and I would like to 
avoid the work of updating them every two weeks. A reminder would be 
nice though.

How about:

Contributors can only open issues with minor priority

This would mean less work for the bot because only committers can raise 
the priority. We would not start automatic deprioriziation at all and 
avoid load on the committers to raise the priority again. We could let 
the bot send a periodic comment if the priority is still necessary.

Maybe this was mentioned before, the thread is already quite long. But 
let me know what you think?

Regards,
Timo

On 05.07.21 12:15, Konstantin Knauf wrote:
> 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 <pn...@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 <tr...@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 <pn...@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 <kn...@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 <yk...@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 <
>> beyond1920@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 <ko...@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 <
>>>>>>> pnowojski@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 <
>>>> chesnay@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 <
>>>>>>>>> pnowojski@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 <
>>>>>> rmetzger@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 <
>>>>>>>>>> trohrmann@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
>> <
>>>>>>>>>>> knaufk@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 <
>>>>>>>>>>> trohrmann@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 <
>>>>>>>> arvid@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
>>> <
>>>>>>>>>>>>>> knaufk@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
>> <
>>>>>>>>>>>>>> twalthr@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 <
>>>>>>>>>>>>>>>>>> rmetzger@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 <
>>>>>>>>>>>>>>>>>> trohrmann@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 <
>>>>>>>>>>>>>>>>>>>>>>> konstantin@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
>>>>>> <
>>>>>>>>>>>>>>>>>>> knaufk@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
>>>>>>
>>>>>
>>>>
>>>
>>
> 
> 

Re: [DISCUSS] Feedback Collection Jira Bot

[Piotr Nowojski <pn...@apache.org>]

> 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.

Finding if there already has been a ticket opened for the given issue is
not always easy. Finding the right ticket among 23086 is 7 times as
difficult/time consuming as among 3305 open tickets. If a piece of
knowledge/discussion is not easily accessible, it's effectively lost.

> 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.

There are tickets that are waiting to get enough traction (bugs,
improvements, ideas, test instabilities). I know plenty of those. If they
are being brought up frequently enough, they will finally get the needed
attention. Until this happens, I don't like to be losing the descriptions,
previous discussions and/or a frequency of past occurrences.

Can I ask, why do you think it makes sense to be closing those tickets
besides it "being clearer" to you? What use case is justifying this? And I
don't agree it's clearer. If the issue is still there, it shouldn't be in
the "CLOSED" state.

> 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.

I didn't count them, but I think stale critical -> stale major -> stale
minor -> auto closing I'm getting the most. If a ticket is not relevant
anymore I've learned to manually close it/clean up immediately once the
jira-bot pings about it regardless of the priority. But so far, I've closed
fewer tickets than I was forced to re-open. Maybe this is because I'm
tracking all of the tickets that are of interest to my team? Maybe others
are not doing that and that's why you are not seeing this problem that I'm
having?

But keep in mind. I don't mind about auto deprioritization. It's fair to
say that tickets get automatically deprioritised if they have no attention.
But why do we have to automatically close the least priority ones?

Maybe another idea. Instead of disabling closing the tickets via some
label, we could also achieve the same thing with a dedicated lowest
priority state "on hold"/"frozen".

Piotrek

śr., 23 cze 2021 o 10:17 Konstantin Knauf <ko...@ververica.com>
napisał(a):

> > 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 <pn...@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 <ch...@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 <pnowojski@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 <rm...@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 <
> trohrmann@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 <
> > knaufk@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 <
> > trohrmann@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 <
> > > >> knaufk@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 <
> > > >> twalthr@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 <
> > > >>>>>> rmetzger@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 <
> > > >>>>>> trohrmann@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 <
> > > >>>>>>>>>>> konstantin@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 <
> > > >>>>>>> knaufk@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
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf <kn...@apache.org>]

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 <pn...@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 <tr...@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 <pn...@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 <kn...@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 <yk...@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 <
> beyond1920@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 <ko...@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 <
> > > > > > pnowojski@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 <
> > > chesnay@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 <
> > > > > > > > pnowojski@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 <
> > > > > rmetzger@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 <
> > > > > > > > > trohrmann@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
> <
> > > > > > > > > > knaufk@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 <
> > > > > > > > > > trohrmann@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 <
> > > > > > > arvid@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
> > <
> > > > > > > > > > > >> knaufk@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
> <
> > > > > > > > > > > >> twalthr@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 <
> > > > > > > > > > > >>>>>> rmetzger@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 <
> > > > > > > > > > > >>>>>> trohrmann@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 <
> > > > > > > > > > > >>>>>>>>>>> konstantin@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
> > > > > <
> > > > > > > > > > > >>>>>>> knaufk@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

Re: [DISCUSS] Feedback Collection Jira Bot

[Piotr Nowojski <pn...@apache.org>]

+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 <tr...@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 <pn...@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 <kn...@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 <yk...@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 <beyond1920@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 <ko...@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 <
> > > > > pnowojski@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 <
> > chesnay@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 <
> > > > > > > pnowojski@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 <
> > > > rmetzger@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 <
> > > > > > > > trohrmann@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 <
> > > > > > > > > knaufk@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 <
> > > > > > > > > trohrmann@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 <
> > > > > > arvid@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
> <
> > > > > > > > > > >> knaufk@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 <
> > > > > > > > > > >> twalthr@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 <
> > > > > > > > > > >>>>>> rmetzger@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 <
> > > > > > > > > > >>>>>> trohrmann@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 <
> > > > > > > > > > >>>>>>>>>>> konstantin@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
> > > > <
> > > > > > > > > > >>>>>>> knaufk@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
> > > >
> > >
> >
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Stephan Ewen <se...@apache.org>]

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 <tr...@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 <pn...@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 <kn...@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 <yk...@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 <be...@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 <ko...@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 <
> > > > pnowojski@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 <
> chesnay@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 <
> > > > > > pnowojski@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 <
> > > rmetzger@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 <
> > > > > > > trohrmann@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 <
> > > > > > > > knaufk@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 <
> > > > > > > > trohrmann@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 <
> > > > > arvid@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 <
> > > > > > > > > >> knaufk@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 <
> > > > > > > > > >> twalthr@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 <
> > > > > > > > > >>>>>> rmetzger@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 <
> > > > > > > > > >>>>>> trohrmann@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 <
> > > > > > > > > >>>>>>>>>>> konstantin@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
> > > <
> > > > > > > > > >>>>>>> knaufk@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
> > >
> >
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Till Rohrmann <tr...@apache.org>]

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 <pn...@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 <kn...@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 <yk...@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 <be...@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 <ko...@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 <
> > > pnowojski@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 <ch...@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 <
> > > > > pnowojski@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 <
> > rmetzger@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 <
> > > > > > trohrmann@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 <
> > > > > > > knaufk@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 <
> > > > > > > trohrmann@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 <
> > > > arvid@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 <
> > > > > > > > >> knaufk@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 <
> > > > > > > > >> twalthr@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 <
> > > > > > > > >>>>>> rmetzger@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 <
> > > > > > > > >>>>>> trohrmann@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 <
> > > > > > > > >>>>>>>>>>> konstantin@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
> > <
> > > > > > > > >>>>>>> knaufk@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
> >
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Piotr Nowojski <pn...@apache.org>]

> * 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 <kn...@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 <yk...@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 <be...@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 <ko...@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 <
> > pnowojski@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 <ch...@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 <
> > > > pnowojski@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 <
> rmetzger@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 <
> > > > > trohrmann@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 <
> > > > > > knaufk@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 <
> > > > > > trohrmann@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 <
> > > arvid@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 <
> > > > > > > >> knaufk@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 <
> > > > > > > >> twalthr@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 <
> > > > > > > >>>>>> rmetzger@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 <
> > > > > > > >>>>>> trohrmann@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 <
> > > > > > > >>>>>>>>>>> konstantin@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
> <
> > > > > > > >>>>>>> knaufk@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
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf <kn...@apache.org>]

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 <yk...@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 <be...@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 <ko...@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 <
> pnowojski@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 <ch...@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 <
> > > pnowojski@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 <rm...@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 <
> > > > trohrmann@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 <
> > > > > knaufk@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 <
> > > > > trohrmann@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 <
> > arvid@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 <
> > > > > > >> knaufk@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 <
> > > > > > >> twalthr@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 <
> > > > > > >>>>>> rmetzger@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 <
> > > > > > >>>>>> trohrmann@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 <
> > > > > > >>>>>>>>>>> konstantin@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 <
> > > > > > >>>>>>> knaufk@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

Re: [DISCUSS] Feedback Collection Jira Bot

[Kurt Young <yk...@gmail.com>]

+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 <be...@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 <ko...@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 <pn...@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 <ch...@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 <
> > pnowojski@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 <rm...@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 <
> > > trohrmann@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 <
> > > > knaufk@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 <
> > > > trohrmann@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 <
> arvid@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 <
> > > > > >> knaufk@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 <
> > > > > >> twalthr@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 <
> > > > > >>>>>> rmetzger@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 <
> > > > > >>>>>> trohrmann@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 <
> > > > > >>>>>>>>>>> konstantin@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 <
> > > > > >>>>>>> knaufk@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
> > >
> >
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Stephan Ewen <se...@apache.org>]

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 <be...@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 <ko...@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 <pn...@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 <ch...@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 <
> pnowojski@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 <rm...@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 <
> > trohrmann@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 <
> > > knaufk@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 <
> > > trohrmann@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 <
> > > > >> knaufk@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 <
> > > > >> twalthr@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 <
> > > > >>>>>> rmetzger@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 <
> > > > >>>>>> trohrmann@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 <
> > > > >>>>>>>>>>> konstantin@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 <
> > > > >>>>>>> knaufk@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
> >
>

Re: [DISCUSS] Feedback Collection Jira Bot

[JING ZHANG <be...@gmail.com>]

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 <ko...@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 <pn...@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 <ch...@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 <pnowojski@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 <rm...@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 <
> trohrmann@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 <
> > knaufk@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 <
> > trohrmann@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 <
> > > >> knaufk@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 <
> > > >> twalthr@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 <
> > > >>>>>> rmetzger@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 <
> > > >>>>>> trohrmann@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 <
> > > >>>>>>>>>>> konstantin@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 <
> > > >>>>>>> knaufk@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
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf <ko...@ververica.com>]

> 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 <pn...@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 <ch...@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 <pn...@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 <rm...@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 <tr...@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 <
> knaufk@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 <
> trohrmann@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 <
> > >> knaufk@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 <
> > >> twalthr@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 <
> > >>>>>> rmetzger@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 <
> > >>>>>> trohrmann@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 <
> > >>>>>>>>>>> konstantin@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 <
> > >>>>>>> knaufk@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

Re: [DISCUSS] Feedback Collection Jira Bot

[Piotr Nowojski <pn...@apache.org>]

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 <ch...@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 <pn...@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 <rm...@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 <tr...@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 <kn...@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 <tr...@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 <
> >> knaufk@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 <
> >> twalthr@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 <
> >>>>>> rmetzger@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 <
> >>>>>> trohrmann@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 <
> >>>>>>>>>>> konstantin@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 <
> >>>>>>> knaufk@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
> >>>>>
> >
>
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Chesnay Schepler <ch...@apache.org>]

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 <pn...@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 <rm...@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 <tr...@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 <kn...@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 <tr...@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 <
>> knaufk@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 <
>> twalthr@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 <
>>>>>> rmetzger@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 <
>>>>>> trohrmann@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 <
>>>>>>>>>>> konstantin@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 <
>>>>>>> knaufk@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
>>>>>
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf <kn...@apache.org>]

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 <pn...@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 <rm...@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 <tr...@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 <kn...@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 <tr...@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 <
> knaufk@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 <
> twalthr@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 <
> > > >> rmetzger@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 <
> > > >> trohrmann@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 <
> > > >> > > > >> konstantin@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 <
> > > >> > knaufk@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

https://twitter.com/snntrable

https://github.com/knaufk

Re: [DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf <kn...@apache.org>]

Hi Piotr,

the bot does not close with "Won't fix", it closes with resolution
"Auto-Closed". It also says in a comment:

This issue was labeled "{warning_label}" {warning_days} days ago and has
not received any updates so I have gone ahead and closed it. If you are
still affected by this or would like to raise the priority of this ticket
please re-open, removing the label "{done_label}" and raise the ticket
priority accordingly.
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.

Cheers,

Konstantin



On Thu, Jun 17, 2021 at 2:17 PM Piotr Nowojski <pn...@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 <rm...@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 <tr...@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 <kn...@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 <tr...@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 <
> knaufk@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 <
> twalthr@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 <
> > > >> rmetzger@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 <
> > > >> trohrmann@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 <
> > > >> > > > >> konstantin@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 <
> > > >> > knaufk@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

https://twitter.com/snntrable

https://github.com/knaufk

Re: [DISCUSS] Feedback Collection Jira Bot

[Piotr Nowojski <pn...@apache.org>]

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 <rm...@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 <tr...@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 <kn...@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 <tr...@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 <knaufk@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 <twalthr@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 <
> > >> rmetzger@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 <
> > >> trohrmann@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 <
> > >> > > > >> konstantin@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 <
> > >> > knaufk@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
> > >
> >
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Robert Metzger <rm...@apache.org>]

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 <tr...@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 <kn...@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 <tr...@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 <kn...@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 <tw...@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 <
> >> rmetzger@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 <
> >> trohrmann@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 <
> >> > > > >> konstantin@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 <
> >> > knaufk@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
> >
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Till Rohrmann <tr...@apache.org>]

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 <kn...@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 <tr...@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 <kn...@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 <tw...@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 <
>> rmetzger@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 <
>> trohrmann@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 <
>> > > > >> konstantin@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 <
>> > knaufk@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
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf <kn...@apache.org>]

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 <tr...@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 <kn...@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 <tw...@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 <
> rmetzger@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 <
> trohrmann@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 <
> > > > >> konstantin@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 <
> > knaufk@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

Re: [DISCUSS] Feedback Collection Jira Bot

[Till Rohrmann <tr...@apache.org>]

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 <kn...@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 <tw...@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 <rm...@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 <trohrmann@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 <
> > > >> konstantin@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 <
> knaufk@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
> >
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Arvid Heise <ar...@apache.org>]

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 <kn...@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 <tw...@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 <rm...@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 <tr...@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 <
> > >> konstantin@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 <knaufk@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
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf <kn...@apache.org>]

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 <tw...@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 <rm...@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 <tr...@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 <
> >> konstantin@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 <kn...@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

Re: [DISCUSS] Feedback Collection Jira Bot

[Timo Walther <tw...@apache.org>]

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 <rm...@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 <tr...@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 <
>> konstantin@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 <kn...@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
>>>>
>>>
>>
> 
> 

Re: [DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf <kn...@apache.org>]

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 <rm...@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 <tr...@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 <
> konstantin@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 <kn...@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

Re: [DISCUSS] Feedback Collection Jira Bot

[Robert Metzger <rm...@apache.org>]

+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 <tr...@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 <konstantin@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 <kn...@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
> >
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Till Rohrmann <tr...@apache.org>]

I like this idea. +1 for your proposal Konstantin.

Cheers,
Till

On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <ko...@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 <kn...@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
>

Re: [DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf <ko...@ververica.com>]

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 <kn...@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