Hi Roman, thanks for your feedback. For the Technical Debt tickets the same rules as for all other tickets would apply:
* Major+ indicates an active discussion or contribution. * Minor is for everything else. So, other issue types, too, do not imply an intention to work on it in the near future. Take, for example, a user making a feature request or improvement proposal and us waiting to see if there are more users that would like to see this improvement. The advantage I see with a dedicated Technical Debt ticket type is that it encourages the community to document technical debt as part of their regular workflow without cluttering the "backlog". What do you think? Cheers, Konstantin On Mon, Mar 1, 2021 at 9:48 PM Roman Khachatryan <ro...@apache.org> wrote: > Hi, > > Thanks for the proposal Konstantin, > I like the ideas expressed there. > > I am a bit concerned about the new issue type "Technical Debt". In contrast > to other issue types, it doesn't imply that someone will likely work on > that. So it can linger until the bot closes it. > Probably we need some rules requiring a person opening such a ticket to > have an intention to work on it in the near future? > Another approach would be some wiki space. > > As for the trivial priority, I would remove it and (use labels where > appropriate) as you suggested. > > Regards, > Roman > > > On Mon, Mar 1, 2021 at 11:53 AM Konstantin Knauf <konstan...@ververica.com > > > 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 | 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 > > > -- Konstantin Knauf https://twitter.com/snntrable https://github.com/knaufk
