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 >
