Hi everyone,
let me also post some feedback here. As someone who monitors and
maintains the SQL component JIRA issues, I'm quite unhappy with the
current bot behavior. I'm watching quite a few issues and SQL has a lot
of pretty major if not critical topics. My mailbox is full of bot
messages every day. And I also heard from other users, that they kind of
disappointed that the bot deprioritized their valuable feedback.
I agree with Stephan and Kurt, a project like Flink has often tickets
that span months to years. It might be just ideas where we select more
input or bugs where we don't have an immediate solution or need to wait
for more reports.
`stale-critical only after 14 days` is still not enought time. I know
critical issues that are open for 6 months already and I would like to
avoid the work of updating them every two weeks. A reminder would be
nice though.
How about:
Contributors can only open issues with minor priority
This would mean less work for the bot because only committers can raise
the priority. We would not start automatic deprioriziation at all and
avoid load on the committers to raise the priority again. We could let
the bot send a periodic comment if the priority is still necessary.
Maybe this was mentioned before, the thread is already quite long. But
let me know what you think?
Regards,
Timo
On 05.07.21 12:15, Konstantin Knauf wrote:
Hi everyone,
ok, let's in addition try out not unassigning anyone from tickets. This
makes it the responsibility of the component maintainers to
periodically check for stale-unassigned tickets and bring them to a
resolution. We can monitor the situation (# of stale-unassigned tickets)
and if the number of open stale-unassigned tickets is ever increasing, we
need to revisit this topic.
For reference here are the tickets for the adjustments:
* https://issues.apache.org/jira/browse/FLINK-23207 (PR available)
* https://issues.apache.org/jira/browse/FLINK-23206 (blocked by INFRA)
* https://issues.apache.org/jira/browse/FLINK-23205 (merged)
* https://issues.apache.org/jira/browse/FLINK-23250 (open)
Cheers,
Konstantin
On Fri, Jul 2, 2021 at 9:43 AM Piotr Nowojski <pnowoj...@apache.org> wrote:
+1 for the unassignment remark from Stephan
Piotrek
czw., 1 lip 2021 o 12:35 Stephan Ewen <se...@apache.org> napisał(a):
It is true that the bot surfaces problems that are there (not enough
committer attention sometimes), but it also "rubs salt in the wound" of
contributors, and that is tricky.
We can try it out with the extended periods (although I think that in
reality we probably need even longer periods) and see how it goes.
One thing I would suggest is to never let the bot unassign issues. It
just
strikes me as very cold and respectless to be unassigned by a bot from an
issue in which I invested time and energy. (The committers don't even
take
the time to talk to me and explain why the contribution will not go
forward).
Unassignment should come from another person, possibly in response to a
ping from the bot. I think that makes a big difference in contributor
treatment.
On Wed, Jun 30, 2021 at 12:30 PM Till Rohrmann <trohrm...@apache.org>
wrote:
I agree that we shouldn't discourage contributions.
For me the main idea of the bot is not to clean up the JIRA but to
improve
our communication and expectation management with the community. There
are
many things we could do but for a lot of things we don't have the time
and
capacity. Then to say at some point that we won't do something is just
being honest. This also shows when looking at the JIRA numbers of the
merged commits. We very rarely resolve tickets which are older than x
days
and if we do, then we usually create a new ticket for the problem.
The fact that we see some tickets with available pull requests go stale
is
the symptom that we don't value them to be important enough or
allocate enough time for external contributions imo. Otherwise, they
would
have gotten the required attention and been merged. In such a case,
raising
awareness by pinging the watchers of the respective ticket is probably
better than silently ignoring the PR. Also adding labels to filter for
these PRs should help to get them the required attention. But also
here,
it
happens very rarely that we actually merge a PR that is older than y
days.
Ideally we avoid this situation altogether by only assigning
contributors
to tickets for which a committer has review capacity. However, this
does
not seem to always work.
In some sense, the JIRA bot shows us the things, which fall through the
cracks, more explicitly (which is probably not different than before).
Of
course we should try to find the time periods for when to ping or
de-prioritize tickets that work best for the community.
+1 for the proposed changes (extended time periods, "Not a Priority",
default priority and fixVersion).
@Piotr, I think we have the priorities defined here [1]. Maybe it is
enough
to share the link so that everyone can check whether her assumptions
are
correct.
[1]
https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process
Cheers,
Till
On Wed, Jun 30, 2021 at 10:59 AM Piotr Nowojski <pnowoj...@apache.org>
wrote:
* Introduce "Not a Priority" priority and stop closing tickets.
+1 for this one (I also like the name you proposed for this
Konstantin)
I also have no objections to other proposals that you summarised.
Just
a
remark, that independently of this discussion we might want to
revisit
or
reconfirm the priorities and their definition/interpretation across
all
contributors.
Best,
Piotrek
śr., 30 cze 2021 o 10:15 Konstantin Knauf <kna...@apache.org>
napisał(a):
Hi everyone,
Thank you for the additional comments and suggestions.
@Stephan, Kurt: I agree that we shouldn't discourage or dishearten
contributors, and probably 14 days until a ticket becomes
"stale-assigned"
are too few. That's why I've already proposed to increase that to
30
days.
Similarly the times for Major/Critical tickets can be increased.
From
my
perspective, the root causes are the following:
* tickets are opened with the wrong priority (see
https://cwiki.apache.org/confluence/display/FLINK/Flink+Jira+Process#FlinkJiraProcess-TicketsPriorities
).
Here it might help to change the default priority.
* committers don't have the time to review tickets or don't bring
community
contributions to a resolution. The Jira bot makes this fact more
visible.
Without the Jira Bot no external contributor would get more
attention,
and
no external contribution would be merged faster. Ideally, it'd be
the
opposite and committers would actively monitor tickets with labels
"stale-assigned" and "pull-request-available" in order to review
those
with
priority. That's also why I am not a fan of excluding tickets with
"pull-request-available" from the bot. The bot can help to make
these
tickets visible to reviewers.
@Jing Zhang: That's a problem. We should try to change the
permissions
accordingly or need to find a different solution.
@Piotr, Kurt: Instead of closing tickets, we could introduce an
additional
priority like "Not a Priority" to which we move tickets. No ticket
would
be
closed automatically.
Overall, the following changes could resolve most of the concerns,
I
believe:
* Ignore tickets with a fixVersion for all rules but the
stale-unassigned
role.
* We change the time intervals as follows, accepting reality a bit
more
;)
* stale-assigned only after 30 days (instead of 14 days)
* stale-critical only after 14 days (instead of 7 days)
* stale-major only after 60 days (instead of 30 days)
* Introduce "Not a Priority" priority and stop closing tickets.
* Change default priority for new tickets of Flink project to
"Minor"
The measures, I proposed above, still try to achieve the goals
mentioned
and agreed upon in the original discussion thread, which were the
following:
-
clearer communication and expectation management with the
community
-
a user or contributor should be able to judge the urgency of
a
ticket
by its priority
-
if a ticket is assigned to someone the expectation that
someone
is
working on it should hold
-
generally reduce noise in Jira
-
reduce overhead of committers to ask about status updates of
contributions or bug reports
-
“Are you still working on this?”
-
“Are you still interested in this?”
-
“Does this still happen on Flink 1.x?”
-
“Are you still experiencing this issue?”
-
“What is the status of the implementation”?
-
while still encouraging users to add new tickets and to leave
feedback
about existing tickets
Kurt, Stephan, if you'd like to change the bot to "just close very
old
tickets", I suggest you start a separate discussion and subsequent
voting
thread.
Best,
Konstantin
On Wed, Jun 30, 2021 at 9:01 AM Kurt Young <ykt...@gmail.com>
wrote:
+1 to Stephan's opinion, with just one minor difference. For my
experience
and a project
as big as Flink, picking up an issue created 1-2 years ago seems
normal
to
me. To be more
specific, during the blink planner merge, I created lots of clean
up
&
refactor issues, trying
to make the code be more clean. I haven't had a chance to resolve
all
these
but I think they are
still good improvements. Thus I would propose we don't close any
stall
issues for at least 2 years.
Best,
Kurt
On Wed, Jun 30, 2021 at 7:22 AM Stephan Ewen <se...@apache.org>
wrote:
Being a bit late to the party, and don't want to ask to change
everything,
just maybe some observation.
My main observation and concern is still that this puts
pressure
and
confusion on contributors, which are mostly blocked on
committers
for
reviews, or are taking tickets as multi-week projects. I think
it
is
not
a
great experience for contributors, when they are already unsure
why
their
work isn't getting the attention from committers that they
hoped
for,
to
then see issues unassigned or deprioritized automatically. I
think
we
really need to weigh this discouragement of contributors
against
the
desire
for a tidy ticket system.
I also think by now this isn't just a matter of phrasing the
bot's
message
correctly. Auto unassignment and deprioritization sends a
subtle
message
that jira resolution is a more important goal than paying
attention
to
contributors (at least I think that is how it will be perceived
by
many).
Back to the original motivation, to not have issues lying
around
forever,
ensuring there is closure eventually.
For that, even much longer intervals would be fine. Like
pinging
every
three months, closing after three pings - would resolve most
tickets
in a
year, which is not too bad in the scope of a project like
Flink.
Many
features/wishes easily move to two releases in the future,
which
is
almost
a year. We would get rid of long dead tickets and interfere
little
with
current tickets. Contributors can probably understand ticket
closing
after
a year of inactivity.
I am curious if a very simple bot that really just looks at
stale
issues
(no comment/change in three months), pings the
issue/reporter/assignee/watchers and closes it after three
pings
would
do
the job.
We would get out of the un-assigning business (which can send
very
tricky
signals) and would rely on reporters/assignees/watchers to
unassign
if
they
see that the contributor abandoned the issue. With a cadence of
three
months for pinging, this isn't much work for the ones that get
pinged.
Issues where we rely on faster handling are probably the ones
where
committers have a stake in getting those into an upcoming
release,
so
these
tend to be watched anyways.
On Wed, Jun 23, 2021 at 2:39 PM JING ZHANG <
beyond1...@gmail.com
wrote:
Hi Konstantin, Chesnay,
I would like it to not unassign people if a PR is open.
These
are
usually blocked by the reviewer, not the assignee, and
having
the
assignees now additionally having to update JIRA
periodically
is
a
bit
like rubbing salt into the wound.
I agree with Chesnay about not un-assign an issue if a PR is
open.
Besides, Could assignees remove the "stale-assigned" tag by
themself?
It
seems assignees have no permission to delete the tag if the
issue
is
not
created by themselves.
Best regards,
JING ZHANG
Konstantin Knauf <konstan...@ververica.com> 于2021年6月23日周三
下午4:17写道：
I agree there are such tickets, but I don't see how this
is
addressing
my
concerns. There are also tickets that just shouldn't be
closed
as I
described above. Why do you think that duplicating tickets
and
losing
discussions/knowledge is a good solution?
I don't understand why we are necessarily losing
discussion/knowledge.
The
tickets are still there, just in "Closed" state, which are
included
in
default Jira search. We could of course just add a label,
but
closing
seems
clearer to me given that likely this ticket will not get
comitter
attention
in the foreseeable future.
I would like to avoid having to constantly fight against
the
bot.
It's
already responsible for the majority of my daily emails,
with
quite
little
benefit for me personally. I initially thought that after
some
period
of
time it will settle down, but now I'm afraid it won't
happen.
Can you elaborate which rules you are running into mostly?
I'd
rather
like
to understand how we work right now and where this
conflicts
with
the
Jira
bot vs slowly disabling the jira bot via labels.
On Wed, Jun 23, 2021 at 10:00 AM Piotr Nowojski <
pnowoj...@apache.org>
wrote:
Hi Konstantin,
In my opinion it is important that we close tickets
eventually.
There
are
a
lot of tickets (bugs, improvements, tech debt) that
over
time
became
irrelevant, out-of-scope, irreproducible, etc. In my
experience,
these
tickets are usually not closed by anyone but the bot.
I agree there are such tickets, but I don't see how this
is
addressing
my
concerns. There are also tickets that just shouldn't be
closed
as I
described above. Why do you think that duplicating
tickets
and
losing
discussions/knowledge is a good solution?
I would like to avoid having to constantly fight against
the
bot.
It's
already responsible for the majority of my daily emails,
with
quite
little
benefit for me personally. I initially thought that after
some
period
of
time it will settle down, but now I'm afraid it won't
happen.
Can
we
add
some label to mark tickets to be ignored by the jira-bot?
Best,
Piotrek
śr., 23 cze 2021 o 09:40 Chesnay Schepler <
ches...@apache.org>
napisał(a):
I would like it to not unassign people if a PR is open.
These
are
usually blocked by the reviewer, not the assignee, and
having
the
assignees now additionally having to update JIRA
periodically
is
a
bit
like rubbing salt into the wound.
On 6/23/2021 7:52 AM, Konstantin Knauf wrote:
Hi everyone,
I was hoping for more feedback from other committers,
but
seems
like
this
is not happening, so here's my proposal for immediate
changes:
* Ignore tickets with a fixVersion for all rules but
the
stale-unassigned
role.
* We change the time intervals as follows, accepting
reality
a
bit
more
;)
* stale-assigned only after 30 days (instead of
14
days)
* stale-critical only after 14 days (instead of
7
days)
* stale-major only after 60 days (instead of 30
days)
Unless there are -1s, I'd implement the changes
Monday
next
week.
Cheers,
Konstantin
On Thu, Jun 17, 2021 at 2:17 PM Piotr Nowojski <
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
--
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
