+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 >
