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 it means something like "targeted for this release" ranging from "basically a must have" and "would be nice if someone picks it up". If "fixVersion" would mean "there is a concrete plan to have this in the release", it might be less of a problem. On Fri, Mar 26, 2021 at 11:03 AM Chesnay Schepler <ches...@apache.org> wrote: > 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/2021 9:18 AM, Konstantin Knauf wrote: > > 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 > "infrastructure > failures, bugs that block a release". With this definition FLINK-21152 > would not be blocker, or would it? Cheers, Konstantin > > On Fri, Mar 26, 2021 at 8:55 AM Chesnay Schepler <ches...@apache.org> > <ches...@apache.org> wrote: > > > 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 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:40 AM Arvid Heise <ar...@apache.org> > <ar...@apache.org> wrote: > > > +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 > completely stale, so we probably talk about something that never > > happens in > > reality. For other tickets, it makes sense. > > On Tue, Mar 23, 2021 at 8:09 AM Konstantin Knauf <kna...@apache.org> > <kna...@apache.org> > wrote: > > > 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 <kna...@apache.org> > <kna...@apache.org> > wrote: > > > 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 are an > assignee/reporter/watcher you want to know when the ticket is about to > become stale or deprioritized. > > Re Technical Debt: There is no getting around the fact that there is > technical debt. There is technical debt in every software project of > > the > > size and age of Apache Flink. The idea of the issue type is to make > > this > > explicit and to encourage developers to document technical debt, so > > that > > it > > can be more easily prioritized and eventually be addressed. For users, > > the > > advantage is to tell features and technical debt apart. Users are > > probably > > only interested in features that change the user-facing behavior of > > Apache > > Flink. I'd be curious to hear other opinions on whether developers > > would > > be > > reluctant to report technical debt publicly. > > Thanks, > > Konstantin > > On Tue, Mar 9, 2021 at 9:20 AM Leonard Xu <xbjt...@gmail.com> > <xbjt...@gmail.com> wrote: > > > 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 know about, but according to this rule, I > > will > > also receive lots of pushed messages. > Could we add push stratey for assignee/reporter/watcher > > role? > > For the proposed new issue type Technical Debt, I don't think > > developers > > are inclined to choose this kind of issue, and I don't like the name > > very > > much because it can be seen/reported by users. > > Best, > Leonard > > > 在 2021年3月8日，10:28，Xintong Song <tonysong...@gmail.com> > <tonysong...@gmail.com> 写道： > > 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 <kna...@apache.org> > <kna...@apache.org> > > wrote: > > 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 created and assigned > > to > > a > > user, but never receives any updates afterwards. > > Day > > Status > > Priority > > Labels > > 0 > > Open > > Blocker > > 7 > > Open > > Blocker > > stale-assigned > > 14 > > Open > > Blocker > > auto-unassigned > > 15 > > Open > > Blocker > > auto-unassigned, stale-blocker > > 22 > > Open > > Critical > > auto-unassigned, auto-deprioritized-blocker > > 29 > > Open > > Critical > > auto-unassigned, auto-deprioritized-blocker, stale-critical > > 36 > > Open > > Major > > auto-unassigned, auto-deprioritized-blocker, > > auto-deprioritized-critical > > 66 > > Open > > Major > > auto-unassigned, auto-deprioritized-blocker, > > auto-deprioritized-critical, > > stale-major > > 73 > > Open > > Minor > > auto-unassigned, auto-deprioritized-blocker, > > auto-deprioritized-critical, > > auto-deprioritized-major > > 263 > > Open > > Minor > > auto-unassigned, auto-deprioritized-blocker, > > auto-deprioritized-critical, > > auto-deprioritized-major, stale-minor > > 270 > > Closed > > Minor > > auto-unassigned, auto-deprioritized-blocker, > > auto-deprioritized-critical, > > auto-deprioritized-major, auto-closed > > I am looking forward to further comments and would otherwise > > proceed > > to a > > vote towards the end of next week. > > Cheers, > > Konstantin > > > On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rmetz...@apache.org > > wrote: > > 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, like wiki. > > Thanks! > > Regards, > Roman > > > On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz < > > dwysakow...@apache.org> > > wrote: > > > 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? > > Best, > > Konstantin > > On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz < > > dwysakow...@apache.org > > wrote: > > > 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 we think they are fine > > to > > be > > taken by newcomers. Therefore they do not fall in my mind into > "immediately" category. > > * I would still deprioritise test instabilities. I think there > > shouldn't > > be a problem with that. We do post links to all failures > > therefore > > it > > will automatically priortise the tasks according to failure > > frequencies. > > Best, > > Dawid > > On 01/03/2021 09:38, Konstantin Knauf wrote: > > 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 < > > tonysong...@gmail.com > > wrote: > > 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 and review tickets updated by the bot. > We may want to review such tickets (e.g., monthly) in case a > > valid > > ticket > > failed to draw the attention of relevant committers and the > > reporter > > doesn't know who to ping. > > Thank you~ > > Xintong Song > > > > On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann < > > trohrm...@apache.org > > wrote: > > > 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 < > > kna...@apache.org> > > wrote: > > > 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 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 > > > Please see the full proposal here: > > > > https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit# > > . > > The idea would be to discuss this proposal in this thread. > > If > > we > > come > > to > > a > > conclusion, I'd document the proposal in the wiki [2] and > > we > > would > > then > > vote on it (approval by "Lazy Majority"). > > Cheers, > > Konstantin > > [1] > > > > https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E > > [2] > > > > https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions > > -- > > Konstantin Knauf > https://twitter.com/snntrable > https://github.com/knaufk > > -- > > Konstantin Knauf > https://twitter.com/snntrable > https://github.com/knaufk > > -- > > 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
