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 <[email protected]> 写道：
>
> 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 <[email protected]> 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 <[email protected]> wrote:
>>
>>> Thanks a lot for the proposal!
>>>
>>> +1 for doing it!
>>>
>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
>>> [email protected]> 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 <
>> [email protected]>
>>>> 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 <
>>>> [email protected]
>>>>>>
>>>>>> 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 <
>> [email protected]
>>>>
>>>>>>> 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 <
>>> [email protected]
>>>>>
>>>>>>>>> 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 <
>>>> [email protected]>
>>>>>>>>>> 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
>>
