[DISCUSS] Feedback Collection Jira Bot

[Konstantin Knauf-4]

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-3]

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 <[hidden email]> 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

[phone]


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

[Till Rohrmann]

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

Cheers,
Till

On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <[hidden email]>
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 <[hidden email]>
> 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
>
> [phone]
>
>
> 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
>

[Robert Metzger]

+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 <[hidden email]> wrote:

> I like this idea. +1 for your proposal Konstantin.
>
> Cheers,
> Till
>
> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <[hidden email]
> >
> 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 <[hidden email]>
> > 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
> >
> > [phone]
> >
> >
> > 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-4]

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 <[hidden email]> 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 <[hidden email]>
> wrote:
>
> > I like this idea. +1 for your proposal Konstantin.
> >
> > Cheers,
> > Till
> >
> > On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
> [hidden email]
> > >
> > 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 <[hidden email]>
> > > 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
> > >
> > > [phone]
> > >
> > >
> > > 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

[Timo Walther-2]

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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>
>>> I like this idea. +1 for your proposal Konstantin.
>>>
>>> Cheers,
>>> Till
>>>
>>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
>> [hidden email]
>>>>
>>> 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 <[hidden email]>
>>>> 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
>>>>
>>>> [phone]
>>>>
>>>>
>>>> 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-4]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> >> wrote:
> >>
> >>> I like this idea. +1 for your proposal Konstantin.
> >>>
> >>> Cheers,
> >>> Till
> >>>
> >>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
> >> [hidden email]
> >>>>
> >>> 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 <[hidden email]>
> >>>> 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
> >>>>
> >>>> [phone]
> >>>>
> >>>>
> >>>> 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

[Arvid Heise-4]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > >> wrote:
> > >>
> > >>> I like this idea. +1 for your proposal Konstantin.
> > >>>
> > >>> Cheers,
> > >>> Till
> > >>>
> > >>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
> > >> [hidden email]
> > >>>>
> > >>> 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 <[hidden email]
> >
> > >>>> 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
> > >>>>
> > >>>> [phone]
> > >>>>
> > >>>>
> > >>>> 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
>

[Till Rohrmann]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> > > 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 <[hidden email]
> >
> > > >> wrote:
> > > >>
> > > >>> I like this idea. +1 for your proposal Konstantin.
> > > >>>
> > > >>> Cheers,
> > > >>> Till
> > > >>>
> > > >>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
> > > >> [hidden email]
> > > >>>>
> > > >>> 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 <
> [hidden email]
> > >
> > > >>>> 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
> > > >>>>
> > > >>>> [phone]
> > > >>>>
> > > >>>>
> > > >>>> 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-4]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > 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 <
> [hidden email]>
> > > > 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 <
> [hidden email]
> > >
> > > > >> wrote:
> > > > >>
> > > > >>> I like this idea. +1 for your proposal Konstantin.
> > > > >>>
> > > > >>> Cheers,
> > > > >>> Till
> > > > >>>
> > > > >>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
> > > > >> [hidden email]
> > > > >>>>
> > > > >>> 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 <
> > [hidden email]
> > > >
> > > > >>>> 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
> > > > >>>>
> > > > >>>> [phone]
> > > > >>>>
> > > > >>>>
> > > > >>>> 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

[Till Rohrmann]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
>> > 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 <[hidden email]>
>> > 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 <
>> [hidden email]>
>> > > > 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 <
>> [hidden email]
>> > >
>> > > > >> wrote:
>> > > > >>
>> > > > >>> I like this idea. +1 for your proposal Konstantin.
>> > > > >>>
>> > > > >>> Cheers,
>> > > > >>> Till
>> > > > >>>
>> > > > >>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
>> > > > >> [hidden email]
>> > > > >>>>
>> > > > >>> 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 <
>> > [hidden email]
>> > > >
>> > > > >>>> 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
>> > > > >>>>
>> > > > >>>> [phone]
>> > > > >>>>
>> > > > >>>>
>> > > > >>>> 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
>

[Robert Metzger]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]> 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 <[hidden email]>
> >> > 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 <[hidden email]>
> >> > 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 <
> >> [hidden email]>
> >> > > > 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 <
> >> [hidden email]
> >> > >
> >> > > > >> wrote:
> >> > > > >>
> >> > > > >>> I like this idea. +1 for your proposal Konstantin.
> >> > > > >>>
> >> > > > >>> Cheers,
> >> > > > >>> Till
> >> > > > >>>
> >> > > > >>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
> >> > > > >> [hidden email]
> >> > > > >>>>
> >> > > > >>> 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 <
> >> > [hidden email]
> >> > > >
> >> > > > >>>> 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
> >> > > > >>>>
> >> > > > >>>> [phone]
> >> > > > >>>>
> >> > > > >>>>
> >> > > > >>>> 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
> >
>

[Piotr Nowojski-5]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > 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 <[hidden email]> 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 <[hidden email]
> >
> > >> > 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 <[hidden email]
> >
> > >> > 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 <
> > >> [hidden email]>
> > >> > > > 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 <
> > >> [hidden email]
> > >> > >
> > >> > > > >> wrote:
> > >> > > > >>
> > >> > > > >>> I like this idea. +1 for your proposal Konstantin.
> > >> > > > >>>
> > >> > > > >>> Cheers,
> > >> > > > >>> Till
> > >> > > > >>>
> > >> > > > >>> On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
> > >> > > > >> [hidden email]
> > >> > > > >>>>
> > >> > > > >>> 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 <
> > >> > [hidden email]
> > >> > > >
> > >> > > > >>>> 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
> > >> > > > >>>>
> > >> > > > >>>> [phone]
> > >> > > > >>>>
> > >> > > > >>>>
> > >> > > > >>>> 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
> > >
> >
>