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> 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> 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> > >> 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> > >>> 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> 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> 写道： > >>>>>> > >>>>>> 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> > >>>>> 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
