[DISCUSS] Apache Flink Jira Process
Locked
12
12
Re: [DISCUSS] Apache Flink Jira Process
 
|
That's a fair point, but then that raises the question how tasks are
documented that /must/ be done for a release /at some point/. The current approach allows me to easily setup a signal for the Release Manager that this ticket must be completed. How would that work in your proposal? On 3/26/2021 9:18 AM, Konstantin Knauf wrote: > 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> >>>> 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 <[hidden email]> >>>>> 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 <[hidden email]> 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 <[hidden email]> 写道： >>>>>>>> >>>>>>>> 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 <[hidden email]> >>>>>>> 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 <[hidden email] >>>>>>> wrote: >>>>>>>>>> Thanks a lot for the proposal! >>>>>>>>>> >>>>>>>>>> +1 for doing it! >>>>>>>>>> >>>>>>>>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman < >>>>>>>>>> [hidden email]> 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 < >>>>>>>>> [hidden email]> >>>>>>>>>>> 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 < >>>>>>>>>>> [hidden email] >>>>>>>>>>>>> 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 < >>>>>>>>> [hidden email] >>>>>>>>>>>>>> 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 < >>>>>>>>>> [hidden email] >>>>>>>>>>>>>>>> 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 < >>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>>>> 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 >>>>> >> |
Re: [DISCUSS] Apache Flink Jira Process
|
|
My proposal does not have an answer for this.
Is "Blocker" often used for this, right now? What is special about FLINK-21152 compared to other important bug fixes/features for the release that makes it a Blocker? It also ties a bit into the question of what "fixVersion" means. I think, right now it means something like "targeted for this release" ranging from "basically a must have" and "would be nice if someone picks it up". If "fixVersion" would mean "there is a concrete plan to have this in the release", it might be less of a problem. On Fri, Mar 26, 2021 at 11:03 AM Chesnay Schepler <[hidden email]> wrote: > That's a fair point, but then that raises the question how tasks are > documented that *must* be done for a release *at some point*. > The current approach allows me to easily setup a signal for the Release > Manager that this ticket must be completed. How would that work in your > proposal? > > On 3/26/2021 9:18 AM, Konstantin Knauf wrote: > > 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 <[hidden email]> <[hidden email]> 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 <[hidden email]> <[hidden email]> 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 <[hidden email]> <[hidden email]> > 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 <[hidden email]> <[hidden email]> > 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 <[hidden email]> <[hidden email]> 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 <[hidden email]> <[hidden email]> 写道： > > 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 <[hidden email]> <[hidden email]> > > 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 <[hidden email] > > wrote: > > Thanks a lot for the proposal! > > +1 for doing it! > > On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <[hidden email]> 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 < > > [hidden email]> > > 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 < > > [hidden email] > > 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 < > > [hidden email] > > 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 < > > [hidden email] > > 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 < > > [hidden email]> > > 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 |
Re: [DISCUSS] Apache Flink Jira Process
|
|
FLINK-21152 is special because we usually know quite early that it must
be done (e.g., because we bump some dependency in flink-shaded at the start of the release cycle), but only do it shortly before a release to avoid wasting time on multiple flink-shaded release cycles for a single Flink release. I don't think there are many instances of such issues. On 3/26/2021 11:11 AM, Konstantin Knauf wrote: > My proposal does not have an answer for this. > > Is "Blocker" often used for this, right now? What is special about > FLINK-21152 compared to other important bug fixes/features for the > release that makes it a Blocker? > > It also ties a bit into the question of what "fixVersion" means. I > think, right now it means something like "targeted for this release" > ranging from "basically a must have" and "would be nice if someone > picks it up". If "fixVersion" would mean "there is a concrete plan to > have this in the release", it might be less of a problem. > > > > On Fri, Mar 26, 2021 at 11:03 AM Chesnay Schepler <[hidden email] > <mailto:[hidden email]>> wrote: > > That's a fair point, but then that raises the question how tasks > are documented that /must/ be done for a release /at some point/. > The current approach allows me to easily setup a signal for the > Release Manager that this ticket must be completed. How would that > work in your proposal? > > On 3/26/2021 9:18 AM, Konstantin Knauf wrote: >> 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<[hidden email]> <mailto:[hidden email]> 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<[hidden email]> <mailto:[hidden email]> 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<[hidden email]> <mailto:[hidden email]> >>>>> 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<[hidden email]> <mailto:[hidden email]> >>>>>> 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<[hidden email]> <mailto:[hidden email]> 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<[hidden email]> <mailto:[hidden email]> 写道： >>>>>>>>> >>>>>>>>> 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<[hidden email]> <mailto:[hidden email]> >>>>>>>> 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 <[hidden email] <mailto:[hidden email]> >>>>>>>> wrote: >>>>>>>>>>> Thanks a lot for the proposal! >>>>>>>>>>> >>>>>>>>>>> +1 for doing it! >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman < >>>>>>>>>>> [hidden email] <mailto:[hidden email]>> 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 < >>>>>>>>>> [hidden email] <mailto:[hidden email]>> >>>>>>>>>>>> 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 < >>>>>>>>>>>> [hidden email] <mailto:[hidden email]> >>>>>>>>>>>>>> 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 < >>>>>>>>>> [hidden email] <mailto:[hidden email]> >>>>>>>>>>>>>>> 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 < >>>>>>>>>>> [hidden email] <mailto:[hidden email]> >>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>> [hidden email] <mailto:[hidden email]>> >>>>>>>>>>>>>>>>>> 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# <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 <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 <https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Konstantin Knauf >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://github.com/knaufk <https://github.com/knaufk> >>>>>>>>>>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> Konstantin Knauf >>>>>>>>>> >>>>>>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable> >>>>>>>>>> >>>>>>>>>> https://github.com/knaufk <https://github.com/knaufk> >>>>>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Konstantin Knauf >>>>>>> >>>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable> >>>>>>> >>>>>>> https://github.com/knaufk <https://github.com/knaufk> >>>>>>> >>>>>> -- >>>>>> >>>>>> Konstantin Knauf >>>>>> >>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable> >>>>>> >>>>>> https://github.com/knaufk <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 > FlinkConference > > Stream Processing | Event Driven | Real Time > > -- > > Ververica GmbH| Invalidenstrasse 115, 10115 Berlin, Germany > > -- > > Ververica GmbHRegistered at Amtsgericht Charlottenburg: HRB 158244 > BManaging Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl > Anton Wehner |
Re: [DISCUSS] Apache Flink Jira Process
|
I agree with Chesnay that we also used Blocker as a kind of reminder for
things which should happen but are not super time critical. Other examples are for example the deprecation of APIs or changing of default values. I admit that these examples could also be changed right away and wouldn't benefit from postponing their change to a later date. If we change how we use fixVersion or introduce a new label, then this could be solved. Cheers, Till On Fri, Mar 26, 2021 at 11:24 AM Chesnay Schepler <[hidden email]> wrote: > FLINK-21152 is special because we usually know quite early that it must > be done (e.g., because we bump some dependency in flink-shaded at the > start of the release cycle), but only do it shortly before a release to > avoid wasting time on multiple flink-shaded release cycles for a single > Flink release. > > I don't think there are many instances of such issues. > > On 3/26/2021 11:11 AM, Konstantin Knauf wrote: > > My proposal does not have an answer for this. > > > > Is "Blocker" often used for this, right now? What is special about > > FLINK-21152 compared to other important bug fixes/features for the > > release that makes it a Blocker? > > > > It also ties a bit into the question of what "fixVersion" means. I > > think, right now it means something like "targeted for this release" > > ranging from "basically a must have" and "would be nice if someone > > picks it up". If "fixVersion" would mean "there is a concrete plan to > > have this in the release", it might be less of a problem. > > > > > > > > On Fri, Mar 26, 2021 at 11:03 AM Chesnay Schepler <[hidden email] > > <mailto:[hidden email]>> wrote: > > > > That's a fair point, but then that raises the question how tasks > > are documented that /must/ be done for a release /at some point/. > > The current approach allows me to easily setup a signal for the > > Release Manager that this ticket must be completed. How would that > > work in your proposal? > > > > On 3/26/2021 9:18 AM, Konstantin Knauf wrote: > >> 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<[hidden email]> > <mailto:[hidden email]> 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<[hidden email]> > <mailto:[hidden email]> 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< > [hidden email]> <mailto:[hidden email]> > >>>>> 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< > [hidden email]> <mailto:[hidden email]> > >>>>>> 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<[hidden email]> > <mailto:[hidden email]> 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<[hidden email]> > <mailto:[hidden email]> 写道： > >>>>>>>>> > >>>>>>>>> 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< > [hidden email]> <mailto:[hidden email]> > >>>>>>>> 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 < > [hidden email] <mailto:[hidden email]> > >>>>>>>> wrote: > >>>>>>>>>>> Thanks a lot for the proposal! > >>>>>>>>>>> > >>>>>>>>>>> +1 for doing it! > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman < > >>>>>>>>>>> [hidden email] <mailto: > [hidden email]>> 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 < > >>>>>>>>>> [hidden email] <mailto:[hidden email]>> > >>>>>>>>>>>> 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 < > >>>>>>>>>>>> [hidden email] <mailto:[hidden email]> > >>>>>>>>>>>>>> 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 < > >>>>>>>>>> [hidden email] <mailto:[hidden email]> > >>>>>>>>>>>>>>> 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 < > >>>>>>>>>>> [hidden email] <mailto:[hidden email]> > >>>>>>>>>>>>>>>>> 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 < > >>>>>>>>>>>> [hidden email] <mailto:[hidden email]>> > >>>>>>>>>>>>>>>>>> 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# > < > 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 > < > 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 > < > https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions > > > >>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Konstantin Knauf > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> https://twitter.com/snntrable < > https://twitter.com/snntrable> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> https://github.com/knaufk < > https://github.com/knaufk> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> > >>>>>>>>>> Konstantin Knauf > >>>>>>>>>> > >>>>>>>>>> https://twitter.com/snntrable < > https://twitter.com/snntrable> > >>>>>>>>>> > >>>>>>>>>> https://github.com/knaufk <https://github.com/knaufk> > >>>>>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Konstantin Knauf > >>>>>>> > >>>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable> > >>>>>>> > >>>>>>> https://github.com/knaufk <https://github.com/knaufk> > >>>>>>> > >>>>>> -- > >>>>>> > >>>>>> Konstantin Knauf > >>>>>> > >>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable> > >>>>>> > >>>>>> https://github.com/knaufk <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 > > FlinkConference > > > > Stream Processing | Event Driven | Real Time > > > > -- > > > > Ververica GmbH| Invalidenstrasse 115, 10115 Berlin, Germany > > > > -- > > > > Ververica GmbHRegistered at Amtsgericht Charlottenburg: HRB 158244 > > BManaging Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl > > Anton Wehner > > > |
«
Return to (DEPRECATED) Apache Flink Mailing List archive.
|
1 view|%1 views
| Free forum by Nabble | Edit this page |