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
