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
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
+1 for the unassignment remark from Stephan
Piotrek
czw., 1 lip 2021 o 12:35 Stephan Ewen 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
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
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
> * 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
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
+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
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.
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
> 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.
Finding if there already has been a ticket opened for the given issue is
not always easy. Finding the right ticket among
> 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
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
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
Hi Piotr,
the bot does not close with "Won't fix", it closes with resolution
"Auto-Closed". It also says in a comment:
This issue was labeled "{warning_label}" {warning_days} days ago and has
not received any updates so I have gone ahead and closed it. If you are
still affected by this or would
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
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
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
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
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
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 wrote:
> One more idea for the bot. Could we have a label to exclude certain tickets
> from the life-cycle?
>
> I'm
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
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
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
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,
+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 wrote:
> I like this idea. +1 for your proposal Konstantin.
>
> Cheers,
> Till
>
> On Wed, May 19, 2021 at 1:30 PM
I like this idea. +1 for your proposal Konstantin.
Cheers,
Till
On Wed, May 19, 2021 at 1:30 PM Konstantin Knauf
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
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
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
29 matches
Mail list logo
