I would like it to not unassign people if a PR is open. These are
usually blocked by the reviewer, not the assignee, and having the
assignees now additionally having to update JIRA periodically is a bit
like rubbing salt into the wound.
On 6/23/2021 7:52 AM, Konstantin Knauf wrote:
Hi everyone,
I was hoping for more feedback from other committers, but seems like this
is not happening, so here's my proposal for immediate changes:
* Ignore tickets with a fixVersion for all rules but the stale-unassigned
role.
* We change the time intervals as follows, accepting reality a bit more ;)
* stale-assigned only after 30 days (instead of 14 days)
* stale-critical only after 14 days (instead of 7 days)
* stale-major only after 60 days (instead of 30 days)
Unless there are -1s, I'd implement the changes Monday next week.
Cheers,
Konstantin
On Thu, Jun 17, 2021 at 2:17 PM Piotr Nowojski <pnowoj...@apache.org> wrote:
Hi,
I also think that the bot is a bit too aggressive/too quick with assigning
stale issues/deprioritizing them, but that's not that big of a deal for me.
What bothers me much more is that it's closing minor issues automatically.
Depriotising issues makes sense to me. If a wish for improvement or a bug
report has been opened a long time ago, and they got no attention over the
time, sure depriotize them. But closing them is IMO a bad idea. Bug might
be minor, but if it's not fixed it's still there - it shouldn't be closed.
Closing with "won't fix" should be done for very good reasons and very
rarely. Same applies to improvements/wishes. Furthermore, very often
descriptions and comments have a lot of value, and if we keep closing minor
issues I'm afraid that we end up with:
- more duplication. I doubt anyone will be looking for prior "closed" bug
reports/improvement requests. Definitely I'm only looking for open tickets
when looking if a ticket for XYZ already exists or not
- we will be losing knowledge
Piotrek
śr., 16 cze 2021 o 15:12 Robert Metzger <rmetz...@apache.org> napisał(a):
Very sorry for the delayed response.
Regarding tickets with the "test-instability" label (topic 1): I'm
usually
assigning a fixVersion to the next release of the branch where the
failure
occurred, when I'm opening a test failure ticket. Others seem to do that
too. Hence my comment that not checking tickets with a fixVersion set by
Flink bot is good (because test failures should always stay "Critical"
until we've understood what's going on)
I see that it is a bit contradicting that Critical test instabilities
receive no attention for 14 days, but that seems to be the norm given the
current number of incoming test instabilities.
On Wed, Jun 16, 2021 at 2:05 PM Till Rohrmann <trohrm...@apache.org>
wrote:
Another example for category 4 would be the ticket where we collect
breaking API changes for Flink 2.0 [1]. The idea behind this ticket is
to
collect things to consider when developing the next major version.
Admittedly, we have never seen the benefits of collecting the breaking
changes because we haven't started Flink 2.x yet. Also, it is not clear
how
relevant these tickets are right now.
[1] https://issues.apache.org/jira/browse/FLINK-3957
Cheers,
Till
On Wed, Jun 16, 2021 at 11:42 AM Konstantin Knauf <kna...@apache.org>
wrote:
Hi everyone,
thank you for all the feedback so far. I believe we have four
different
topics by now:
1 about *test-instability tickets* raised by Robert. Waiting for
feedback
by Robert.
2 about *aggressiveness of stale-assigned *rule raised by Timo.
Waiting
for feedback by Timo and others.
3 about *excluding issues with a fixVersion* raised by Konstantin,
Till.
Waiting for more feedback by the community as it involves general
changes
to how we deal with fixVersion.
4 about *excluding issues with a specific-label* raised by Arvid.
I've already written something about 1-3. Regarding 4:
How do we make sure that these don't become stale? I think, there
have
been a few "long-term efforts" in the past that never got the
attention
that we initially wanted. Is this just about the ability to collect
tickets
under an umbrella to document a future effort? Maybe for the example
of
DataStream replacing DataSet how would this look like in Jira?
Cheers,
Konstantin
On Tue, Jun 8, 2021 at 11:31 AM Till Rohrmann <trohrm...@apache.org>
wrote:
I like this idea. It would then be the responsibility of the
component
maintainers to manage the lifecycle explicitly.
Cheers,
Till
On Mon, Jun 7, 2021 at 1:48 PM Arvid Heise <ar...@apache.org>
wrote:
One more idea for the bot. Could we have a label to exclude
certain
tickets
from the life-cycle?
I'm thinking about long-term tickets such as improving DataStream
to
eventually replace DataSet. We would collect ideas over the next
couple
of
weeks without any visible progress on the implementation.
On Fri, May 21, 2021 at 2:06 PM Konstantin Knauf <
kna...@apache.org
wrote:
Hi Timo,
Thanks for joining the discussion. All rules except the
unassigned
rule
do
not apply to Sub-Tasks actually (like deprioritization,
closing).
Additionally, activity on a Sub-Taks counts as activity for the
parent.
So,
the parent ticket would not be touched by the bot as long as
there
is
a
single Sub-Task that has a discussion or an update. If you
experience
something different, this is a bug.
Is there a reason why it is important to assign all Sub-Tasks to
the
same
person immediately? I am not sure if this kind "reserving
tickets"
is
a
good idea in general to be honest.
Cheers,
Konstantin
On Fri, May 21, 2021 at 12:00 PM Timo Walther <
twal...@apache.org
wrote:
Hi Konstantin,
thanks for starting this discussion. I was also about to
provide
some
feedback because I have the feeling that the bot is too
aggressive
at
the moment.
Even a 14 days interval is a short period of time for bigger
efforts
that might include several subtasks. Currently, if we split an
issue
into subtasks usually most subtasks are assigned to the same
person.
But
the bot requires us to update all subtasks again after 7 days.
Could we
disable the bot for subtasks or extend the period to 30 days?
The core problem in the past was that we had issues laying
around
untouched for years. Luckily, this is solved with the bot now.
But
going
from years to 7 days spams the mail box quite a bit.
Regards,
Timo
On 21.05.21 09:22, Konstantin Knauf wrote:
Hi Robert,
Could you elaborate on your comment on test instabilities?
Would
test
instabilities always get a fixVersion then?
Background: Test instabilities are supposed to be Critical.
Critical
tickets are deprioritized if they are unassigned and have
not
received
an
update for 14 days.
Cheers,
Konstantin
On Thu, May 20, 2021 at 9:34 AM Robert Metzger <
rmetz...@apache.org>
wrote:
+1
This would also cover test instabilities, which I
personally
believe
should
not be auto-deprioritized until they've been analyzed.
On Wed, May 19, 2021 at 1:46 PM Till Rohrmann <
trohrm...@apache.org
wrote:
I like this idea. +1 for your proposal Konstantin.
Cheers,
Till
On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf <
konstan...@ververica.com
wrote:
Hi everyone,
Till and I recently discussed whether we should disable
the
"stale-blocker", "stale-critical", "stale-major" and
"stale-minor"
rules
for tickets that have a fixVersion set. This would allow
people to
plan
the
upcoming release without tickets being deprioritized by
the
bot
during
the
release cycle.
From my point of view, this is a good idea as long as we
can
agree
to
use
the "fixVersion" a bit more conservatively. What do I
mean
by
that?
If
you
would categorize tickets planned for an upcoming release
into:
* Must Have
* Should Have
* Nice-To-Have
only "Must Have" and "Should Have" tickets should get a
fixVersion.
From
my
observation, we currently often set the fixVersion if we
just
wished a
feature was included in an upcoming release. Similarly, I
often
see
bulk
changes of fixVersion that "roll over" many tickets to
the
next
release
if
they have not made into the previous release although
there
is
no
concrete
plan to fix them or they have even become obsolete by
then.
Excluding
those
from the bot would be counterproductive.
What do you think?
Cheers,
Konstantin
On Fri, Apr 23, 2021 at 2:25 PM Konstantin Knauf <
kna...@apache.org
wrote:
Hi everyone,
After some offline conversations, I think, it makes
sense
to
already
open
this thread now in order to collect feedback and
suggestions
around
the
Jira Bot.
The following two changes I will do right away:
* increase "stale-assigned.stale-days" to 14 days
(Marta,
Stephan,
Nico
have provided feedback that this is too aggressive).
* exclude Sub-Tasks from all rules except the
"stale-assigned"
rule
(I
think, this was just an oversight in the original
discussion.)
Keep it coming.
Cheers,
Konstantin
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk
--
Konstantin Knauf | Head of Product
+49 160 91394525
Follow us @VervericaData Ververica <
https://www.ververica.com/
--
Join Flink Forward <https://flink-forward.org/> - The
Apache
Flink
Conference
Stream Processing | Event Driven | Real Time
--
Ververica GmbH | Invalidenstrasse 115, 10115 Berlin,
Germany
--
Ververica GmbH
Registered at Amtsgericht Charlottenburg: HRB 158244 B
Managing Directors: Yip Park Tung Jason, Jinwei (Kevin)
Zhang,
Karl
Anton
Wehner
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk
