Hi Konstantin,
thanks for starting this discussion. I was also about to provide some
feedback because I have the feeling that the bot is too aggressive at
the moment.
Even a 14 days interval is a short period of time for bigger efforts
that might include several subtasks. Currently, if we split an issue
into subtasks usually most subtasks are assigned to the same person. But
the bot requires us to update all subtasks again after 7 days. Could we
disable the bot for subtasks or extend the period to 30 days?
The core problem in the past was that we had issues laying around
untouched for years. Luckily, this is solved with the bot now. But going
from years to 7 days spams the mail box quite a bit.
Regards,
Timo
On 21.05.21 09:22, Konstantin Knauf wrote:
Hi Robert,
Could you elaborate on your comment on test instabilities? Would test
instabilities always get a fixVersion then?
Background: Test instabilities are supposed to be Critical. Critical
tickets are deprioritized if they are unassigned and have not received an
update for 14 days.
Cheers,
Konstantin
On Thu, May 20, 2021 at 9:34 AM Robert Metzger <rmetz...@apache.org> wrote:
+1
This would also cover test instabilities, which I personally believe should
not be auto-deprioritized until they've been analyzed.
On Wed, May 19, 2021 at 1:46 PM Till Rohrmann <trohrm...@apache.org>
wrote:
I like this idea. +1 for your proposal Konstantin.
Cheers,
Till
On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
konstan...@ververica.com
wrote:
Hi everyone,
Till and I recently discussed whether we should disable the
"stale-blocker", "stale-critical", "stale-major" and "stale-minor"
rules
for tickets that have a fixVersion set. This would allow people to plan
the
upcoming release without tickets being deprioritized by the bot during
the
release cycle.
From my point of view, this is a good idea as long as we can agree to
use
the "fixVersion" a bit more conservatively. What do I mean by that? If
you
would categorize tickets planned for an upcoming release into:
* Must Have
* Should Have
* Nice-To-Have
only "Must Have" and "Should Have" tickets should get a fixVersion.
From
my
observation, we currently often set the fixVersion if we just wished a
feature was included in an upcoming release. Similarly, I often see
bulk
changes of fixVersion that "roll over" many tickets to the next release
if
they have not made into the previous release although there is no
concrete
plan to fix them or they have even become obsolete by then. Excluding
those
from the bot would be counterproductive.
What do you think?
Cheers,
Konstantin
On Fri, Apr 23, 2021 at 2:25 PM Konstantin Knauf <kna...@apache.org>
wrote:
Hi everyone,
After some offline conversations, I think, it makes sense to already
open
this thread now in order to collect feedback and suggestions around
the
Jira Bot.
The following two changes I will do right away:
* increase "stale-assigned.stale-days" to 14 days (Marta, Stephan,
Nico
have provided feedback that this is too aggressive).
* exclude Sub-Tasks from all rules except the "stale-assigned" rule
(I
think, this was just an oversight in the original discussion.)
Keep it coming.
Cheers,
Konstantin
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk
--
Konstantin Knauf | Head of Product
+49 160 91394525
Follow us @VervericaData Ververica <https://www.ververica.com/>
--
Join Flink Forward <https://flink-forward.org/> - The Apache Flink
Conference
Stream Processing | Event Driven | Real Time
--
Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany
--
Ververica GmbH
Registered at Amtsgericht Charlottenburg: HRB 158244 B
Managing Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl
Anton
Wehner
