http://deprecated-apache-flink-mailing-list-archive.368.s1.nabble.com/DISCUSS-Feedback-Collection-Jira-Bot-tp50389p51172.html
One more idea for the bot. Could we have a label to exclude certain tickets
eventually replace DataSet. We would collect ideas over the next couple of
> 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
> > >>>>
> > >>>> +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>