I agree with Chesnay that we also used Blocker as a kind of reminder for
things which should happen but are not super time critical. Other examples
are for example the deprecation of APIs or changing of default values. I
admit that these examples could also be changed right away and wouldn't
benefi
FLINK-21152 is special because we usually know quite early that it must
be done (e.g., because we bump some dependency in flink-shaded at the
start of the release cycle), but only do it shortly before a release to
avoid wasting time on multiple flink-shaded release cycles for a single
Flink rel
My proposal does not have an answer for this.
Is "Blocker" often used for this, right now? What is special about
FLINK-21152 compared to other important bug fixes/features for the release
that makes it a Blocker?
It also ties a bit into the question of what "fixVersion" means. I think,
right now
That's a fair point, but then that raises the question how tasks are
documented that /must/ be done for a release /at some point/.
The current approach allows me to easily setup a signal for the Release
Manager that this ticket must be completed. How would that work in your
proposal?
On 3/26/2
Hi Chesnay,
a blocker is currently defined in the Flink Confluence as a "needs to be
resolved before a release (matched based on fix versions)" whereas I was
thinking of it as a "someone needs to stop their work to fix this" kind of
thing. In the proposal I shared a blocker is therefore defined as
FLINK-21152 is an example of a blocker issue that can remain stale for
months.
On 3/26/2021 8:46 AM, Konstantin Knauf wrote:
Hi Arvid,
I agree that this should never happen for blockers. My thinking was that if
an unassigned blocker is deprioritized after 1 day it also forces us to
find someon
Hi Arvid,
I agree that this should never happen for blockers. My thinking was that if
an unassigned blocker is deprioritized after 1 day it also forces us to
find someone to work on the blocker right away, which we should do anyway
if it is blocker.
Thanks,
Konstantin
On Fri, Mar 26, 2021 at 8:
+1 from my side.
I would have probably never deprioritized blockers automatically. Just
because there is no activity doesn't mean that the nature of the ticket
changes (blockers are quite special). However, as blockers are by
definition resolved with urgency, I also cannot imagine a blocker going
Hi everyone,
The discussion has stalled a bit on this thread. I would proceed to a vote
on the currently documented proposal tomorrow if there are no further
concerns or opinions.
Best,
Konstantin
On Fri, Mar 12, 2021 at 5:24 PM Konstantin Knauf wrote:
> Hi Leonard,
>
> Thank you for your fee
Hi Leonard,
Thank you for your feedback.
Re Notifications: The bot would write a comment that would notify assignee,
reporter and watchers. Probably, we could change the notifications not to
notify watchers on comments, but this would also affect regular comments.
Generally, I'd argue that if you
Thanks Konstantin for driving this topic.
Generally +1 for the proposal, I went through the doc and have two concerns
here.
Will the robot send all notifications to assignee/reporter/watchers ?
I’m a little worried about too many push messages. Eg, I watched some
issues that I want to k
Thanks for the updates, Konstantin.
The changes look good to me.
Minor:
- typo: The last two `auto-deprioritized-blocker` in rule 1 details should
be `auto-deprioritized-critical/major`.
Thank you~
Xintong Song
On Fri, Mar 5, 2021 at 7:33 PM Konstantin Knauf wrote:
> Hi everyone,
>
> Thank
Hi everyone,
Thank you for all the comments so far. As proposed, I have dropped the
"Trivial" Priority.
I also added another section "Rules in Detail" to the document adding some
concrete numbers & labels that implement the rules. As a TLDR, here is an
example of the flow for a "Blocker", that is
Thanks a lot for the proposal!
+1 for doing it!
On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
khachatryan.ro...@gmail.com> wrote:
> Hi Konstantin,
>
> I think we should try it out.
> Even if tickets don't work well it can be a good step towards managing
> technical debt in some other way,
Hi Konstantin,
I think we should try it out.
Even if tickets don't work well it can be a good step towards managing
technical debt in some other way, like wiki.
Thanks!
Regards,
Roman
On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz
wrote:
> I'd be fine with dropping the "Trivial" priority in
I'd be fine with dropping the "Trivial" priority in favour of "starter"
label.
Best,
Dawid
On 01/03/2021 11:53, Konstantin Knauf wrote:
> Hi Dawid,
>
> Thanks for the feedback. Do you think we should simply get rid of the
> "Trivial" priority then and use the "starter" label more aggressively?
>
Hi Roman,
thanks for your feedback. For the Technical Debt tickets the same rules as
for all other tickets would apply:
* Major+ indicates an active discussion or contribution.
* Minor is for everything else.
So, other issue types, too, do not imply an intention to work on it in the
near future.
Hi,
Thanks for the proposal Konstantin,
I like the ideas expressed there.
I am a bit concerned about the new issue type "Technical Debt". In contrast
to other issue types, it doesn't imply that someone will likely work on
that. So it can linger until the bot closes it.
Probably we need some rules
Hi Dawid,
Thanks for the feedback. Do you think we should simply get rid of the
"Trivial" priority then and use the "starter" label more aggressively?
Best,
Konstantin
On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz
wrote:
> Hi Konstantin,
>
> I also like the idea.
>
> Two comments:
>
> * yo
Hi Konstantin,
I also like the idea.
Two comments:
* you describe the "Trivial" priority as one that needs to be
implemented immediately. First of all it is not used to often, but I
think the way it works now is similar with a "starter" label. Tasks that
are not bugs, are easy to implement and w
Hi Xintong,
yes, such labels would make a lot of sense. I added a sentence to the
document.
Thanks,
Konstantin
On Mon, Mar 1, 2021 at 8:51 AM Xintong Song wrote:
> Thanks for driving this discussion, Konstantin.
>
> I like the idea of having a bot reminding reporter/assignee/watchers about
>
Thanks for driving this discussion, Konstantin.
I like the idea of having a bot reminding reporter/assignee/watchers about
inactive tickets and if needed downgrade/close them automatically.
My two cents:
We may have labels like "downgraded-by-bot" / "closed-by-bot", so that it's
easier to filter
Thanks for starting this discussion Konstantin. I like your proposal and
also the idea of automating the tedious parts of it via a bot.
Cheers,
Till
On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf wrote:
> Dear Flink Community,
>
> I would like to start a discussion on improving and to some ex
Dear Flink Community,
I would like to start a discussion on improving and to some extent simply
defining the way we work with Jira. Some aspects have been discussed a
while back [1], but I would like to go a bit beyond that with the following
goals in mind:
-
clearer communication and exp
24 matches
Mail list logo
