[DISCUSS] Apache Flink Jira Process

[Konstantin Knauf-4]

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

[Till Rohrmann]

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
>

[Xintong Song]

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-4]

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

[dwysakowicz]

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-3]

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 | Head of Product

[phone]


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

[roman]

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 <[hidden email]>
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 | Head of Product
>
> [phone]
>
>
> 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-4]

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 <[hidden email]> 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 <[hidden email]
> >
> 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 | Head of Product
> >
> > [phone]
> >
> >
> > 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

[dwysakowicz]

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

[Khachatryan Roman]

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

[Robert Metzger]

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-4]

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

[Xintong Song]

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
>

[Leonard Xu]

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-4]

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-4]

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

[Arvid Heise-4]

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

[Konstantin Knauf-4]

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

--

Konstantin Knauf

https://twitter.com/snntrable

https://github.com/knaufk

[Chesnay Schepler-3]

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

[Konstantin Knauf-3]

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

--

Konstantin Knauf | Head of Product

[phone]


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