You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Xintong Song <to...@gmail.com> on 2021/03/01 07:51:04 UTC
Re: [DISCUSS] Apache Flink Jira Process
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 <tr...@apache.org> wrote:
> Thanks for starting this discussion Konstantin. I like your proposal and
> also the idea of automating the tedious parts of it via a bot.
>
> Cheers,
> Till
>
> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <kn...@apache.org>
> wrote:
>
> > Dear Flink Community,
> >
> > I would like to start a discussion on improving and to some extent simply
> > defining the way we work with Jira. Some aspects have been discussed a
> > while back [1], but I would like to go a bit beyond that with the
> following
> > goals in mind:
> >
> >
> > -
> >
> > clearer communication and expectation management with the community
> > -
> >
> > a user or contributor should be able to judge the urgency of a
> ticket
> > by its priority
> > -
> >
> > if a ticket is assigned to someone the expectation that someone is
> > working on it should hold
> > -
> >
> > generally reduce noise in Jira
> > -
> >
> > reduce overhead of committers to ask about status updates of
> > contributions or bug reports
> > -
> >
> > “Are you still working on this?”
> > -
> >
> > “Are you still interested in this?”
> > -
> >
> > “Does this still happen on Flink 1.x?”
> > -
> >
> > “Are you still experiencing this issue?”
> > -
> >
> > “What is the status of the implementation”?
> > -
> >
> > while still encouraging users to add new tickets and to leave feedback
> > about existing tickets
> >
> >
> > Please see the full proposal here:
> >
> >
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> > .
> >
> > The idea would be to discuss this proposal in this thread. If we come to
> a
> > conclusion, I'd document the proposal in the wiki [2] and we would then
> > vote on it (approval by "Lazy Majority").
> >
> > Cheers,
> >
> > Konstantin
> >
> > [1]
> >
> >
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> > [2]
> >
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> >
> > --
> >
> > Konstantin Knauf
> >
> > https://twitter.com/snntrable
> >
> > https://github.com/knaufk
> >
>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Till Rohrmann <tr...@apache.org>.
I agree with Chesnay that we also used Blocker as a kind of reminder for
things which should happen but are not super time critical. Other examples
are for example the deprecation of APIs or changing of default values. I
admit that these examples could also be changed right away and wouldn't
benefit from postponing their change to a later date.
If we change how we use fixVersion or introduce a new label, then this
could be solved.
Cheers,
Till
On Fri, Mar 26, 2021 at 11:24 AM Chesnay Schepler <ch...@apache.org>
wrote:
> FLINK-21152 is special because we usually know quite early that it must
> be done (e.g., because we bump some dependency in flink-shaded at the
> start of the release cycle), but only do it shortly before a release to
> avoid wasting time on multiple flink-shaded release cycles for a single
> Flink release.
>
> I don't think there are many instances of such issues.
>
> On 3/26/2021 11:11 AM, Konstantin Knauf wrote:
> > My proposal does not have an answer for this.
> >
> > Is "Blocker" often used for this, right now? What is special about
> > FLINK-21152 compared to other important bug fixes/features for the
> > release that makes it a Blocker?
> >
> > It also ties a bit into the question of what "fixVersion" means. I
> > think, right now it means something like "targeted for this release"
> > ranging from "basically a must have" and "would be nice if someone
> > picks it up". If "fixVersion" would mean "there is a concrete plan to
> > have this in the release", it might be less of a problem.
> >
> >
> >
> > On Fri, Mar 26, 2021 at 11:03 AM Chesnay Schepler <chesnay@apache.org
> > <ma...@apache.org>> wrote:
> >
> > That's a fair point, but then that raises the question how tasks
> > are documented that /must/ be done for a release /at some point/.
> > The current approach allows me to easily setup a signal for the
> > Release Manager that this ticket must be completed. How would that
> > work in your proposal?
> >
> > On 3/26/2021 9:18 AM, Konstantin Knauf wrote:
> >> Hi Chesnay,
> >>
> >> a blocker is currently defined in the Flink Confluence as a "needs
> to be
> >> resolved before a release (matched based on fix versions)" whereas
> I was
> >> thinking of it as a "someone needs to stop their work to fix this"
> kind of
> >> thing. In the proposal I shared a blocker is therefore defined as
> >> "infrastructure
> >> failures, bugs that block a release". With this definition
> FLINK-21152
> >> would not be blocker, or would it? Cheers, Konstantin
> >>
> >> On Fri, Mar 26, 2021 at 8:55 AM Chesnay Schepler<ch...@apache.org>
> <ma...@apache.org> 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<ar...@apache.org>
> <ma...@apache.org> 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<
> knaufk@apache.org> <ma...@apache.org>
> >>>>> 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<
> knaufk@apache.org> <ma...@apache.org>
> >>>>>> 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<xb...@gmail.com>
> <ma...@gmail.com> 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<to...@gmail.com>
> <ma...@gmail.com> 写道：
> >>>>>>>>>
> >>>>>>>>> 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<
> knaufk@apache.org> <ma...@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>>> Hi everyone,
> >>>>>>>>>>
> >>>>>>>>>> Thank you for all the comments so far. As proposed, I have
> dropped
> >>>>>> the
> >>>>>>>>>> "Trivial" Priority.
> >>>>>>>>>>
> >>>>>>>>>> I also added another section "Rules in Detail" to the
> document
> >>>>> adding
> >>>>>>>> some
> >>>>>>>>>> concrete numbers & labels that implement the rules. As a
> TLDR, here
> >>>>>> is
> >>>>>>>> an
> >>>>>>>>>> example of the flow for a "Blocker", that is created and
> assigned
> >>>>> to
> >>>>>> a
> >>>>>>>>>> user, but never receives any updates afterwards.
> >>>>>>>>>>
> >>>>>>>>>> Day
> >>>>>>>>>>
> >>>>>>>>>> Status
> >>>>>>>>>>
> >>>>>>>>>> Priority
> >>>>>>>>>>
> >>>>>>>>>> Labels
> >>>>>>>>>>
> >>>>>>>>>> 0
> >>>>>>>>>>
> >>>>>>>>>> Open
> >>>>>>>>>>
> >>>>>>>>>> Blocker
> >>>>>>>>>>
> >>>>>>>>>> 7
> >>>>>>>>>>
> >>>>>>>>>> Open
> >>>>>>>>>>
> >>>>>>>>>> Blocker
> >>>>>>>>>>
> >>>>>>>>>> stale-assigned
> >>>>>>>>>>
> >>>>>>>>>> 14
> >>>>>>>>>>
> >>>>>>>>>> Open
> >>>>>>>>>>
> >>>>>>>>>> Blocker
> >>>>>>>>>>
> >>>>>>>>>> auto-unassigned
> >>>>>>>>>>
> >>>>>>>>>> 15
> >>>>>>>>>>
> >>>>>>>>>> Open
> >>>>>>>>>>
> >>>>>>>>>> Blocker
> >>>>>>>>>>
> >>>>>>>>>> auto-unassigned, stale-blocker
> >>>>>>>>>>
> >>>>>>>>>> 22
> >>>>>>>>>>
> >>>>>>>>>> Open
> >>>>>>>>>>
> >>>>>>>>>> Critical
> >>>>>>>>>>
> >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker
> >>>>>>>>>>
> >>>>>>>>>> 29
> >>>>>>>>>>
> >>>>>>>>>> Open
> >>>>>>>>>>
> >>>>>>>>>> Critical
> >>>>>>>>>>
> >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker, stale-critical
> >>>>>>>>>>
> >>>>>>>>>> 36
> >>>>>>>>>>
> >>>>>>>>>> Open
> >>>>>>>>>>
> >>>>>>>>>> Major
> >>>>>>>>>>
> >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
> >>>>>>>> auto-deprioritized-critical
> >>>>>>>>>> 66
> >>>>>>>>>>
> >>>>>>>>>> Open
> >>>>>>>>>>
> >>>>>>>>>> Major
> >>>>>>>>>>
> >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
> >>>>>>>> auto-deprioritized-critical,
> >>>>>>>>>> stale-major
> >>>>>>>>>>
> >>>>>>>>>> 73
> >>>>>>>>>>
> >>>>>>>>>> Open
> >>>>>>>>>>
> >>>>>>>>>> Minor
> >>>>>>>>>>
> >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
> >>>>>>>> auto-deprioritized-critical,
> >>>>>>>>>> auto-deprioritized-major
> >>>>>>>>>>
> >>>>>>>>>> 263
> >>>>>>>>>>
> >>>>>>>>>> Open
> >>>>>>>>>>
> >>>>>>>>>> Minor
> >>>>>>>>>>
> >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
> >>>>>>>> auto-deprioritized-critical,
> >>>>>>>>>> auto-deprioritized-major, stale-minor
> >>>>>>>>>>
> >>>>>>>>>> 270
> >>>>>>>>>>
> >>>>>>>>>> Closed
> >>>>>>>>>>
> >>>>>>>>>> Minor
> >>>>>>>>>>
> >>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
> >>>>>>>> auto-deprioritized-critical,
> >>>>>>>>>> auto-deprioritized-major, auto-closed
> >>>>>>>>>>
> >>>>>>>>>> I am looking forward to further comments and would otherwise
> >>>>> proceed
> >>>>>>>> to a
> >>>>>>>>>> vote towards the end of next week.
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>>
> >>>>>>>>>> Konstantin
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <
> rmetzger@apache.org <ma...@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>>>> Thanks a lot for the proposal!
> >>>>>>>>>>>
> >>>>>>>>>>> +1 for doing it!
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
> >>>>>>>>>>> khachatryan.roman@gmail.com <mailto:
> khachatryan.roman@gmail.com>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Konstantin,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think we should try it out.
> >>>>>>>>>>>> Even if tickets don't work well it can be a good step
> towards
> >>>>>>>> managing
> >>>>>>>>>>>> technical debt in some other way, like wiki.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regards,
> >>>>>>>>>>>> Roman
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
> >>>>>>>>>> dwysakowicz@apache.org <ma...@apache.org>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I'd be fine with dropping the "Trivial" priority in
> favour of
> >>>>>>>>>> "starter"
> >>>>>>>>>>>>> label.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Dawid
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 01/03/2021 11:53, Konstantin Knauf wrote:
> >>>>>>>>>>>>>> Hi Dawid,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks for the feedback. Do you think we should simply
> get rid
> >>>>> of
> >>>>>>>>>> the
> >>>>>>>>>>>>>> "Trivial" priority then and use the "starter" label more
> >>>>>>>>>>> aggressively?
> >>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Konstantin
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
> >>>>>>>>>>>> dwysakowicz@apache.org <ma...@apache.org>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hi Konstantin,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I also like the idea.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Two comments:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> * you describe the "Trivial" priority as one that
> needs to be
> >>>>>>>>>>>>>>> implemented immediately. First of all it is not used
> to often,
> >>>>>>>>>> but I
> >>>>>>>>>>>>>>> think the way it works now is similar with a "starter"
> label.
> >>>>>>>>>> Tasks
> >>>>>>>>>>>> that
> >>>>>>>>>>>>>>> are not bugs, are easy to implement and we think they
> are fine
> >>>>>> to
> >>>>>>>>>> be
> >>>>>>>>>>>>>>> taken by newcomers. Therefore they do not fall in my
> mind into
> >>>>>>>>>>>>>>> "immediately" category.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> * I would still deprioritise test instabilities. I
> think there
> >>>>>>>>>>>> shouldn't
> >>>>>>>>>>>>>>> be a problem with that. We do post links to all
> failures
> >>>>>> therefore
> >>>>>>>>>>> it
> >>>>>>>>>>>>>>> will automatically priortise the tasks according to
> failure
> >>>>>>>>>>>> frequencies.
> >>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Dawid
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote:
> >>>>>>>>>>>>>>>> Hi Xintong,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> yes, such labels would make a lot of sense. I added a
> >>>>> sentence
> >>>>>> to
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>>> document.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Konstantin
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
> >>>>>>>>>> tonysong820@gmail.com <ma...@gmail.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>> Thanks for driving this discussion, Konstantin.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I like the idea of having a bot reminding
> >>>>>>>>>>> reporter/assignee/watchers
> >>>>>>>>>>>>>>> about
> >>>>>>>>>>>>>>>>> inactive tickets and if needed downgrade/close them
> >>>>>>>>>> automatically.
> >>>>>>>>>>>>>>>>> My two cents:
> >>>>>>>>>>>>>>>>> We may have labels like "downgraded-by-bot" /
> >>>>> "closed-by-bot",
> >>>>>>>>>> so
> >>>>>>>>>>>> that
> >>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>> easier to filter and review tickets updated by the
> bot.
> >>>>>>>>>>>>>>>>> We may want to review such tickets (e.g., monthly)
> in case a
> >>>>>>>>>> valid
> >>>>>>>>>>>>>>> ticket
> >>>>>>>>>>>>>>>>> failed to draw the attention of relevant committers
> and the
> >>>>>>>>>>> reporter
> >>>>>>>>>>>>>>>>> doesn't know who to ping.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Thank you~
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Xintong Song
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
> >>>>>>>>>>> trohrmann@apache.org <ma...@apache.org>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thanks for starting this discussion Konstantin. I
> like your
> >>>>>>>>>>>> proposal
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>> also the idea of automating the tedious parts of it
> via a
> >>>>>> bot.
> >>>>>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>>>>> Till
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
> >>>>>>>>>>>> knaufk@apache.org <ma...@apache.org>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Dear Flink Community,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I would like to start a discussion on improving
> and to
> >>>>> some
> >>>>>>>>>>> extent
> >>>>>>>>>>>>>>>>> simply
> >>>>>>>>>>>>>>>>>>> defining the way we work with Jira. Some aspects
> have been
> >>>>>>>>>>>>> discussed a
> >>>>>>>>>>>>>>>>>>> while back [1], but I would like to go a bit
> beyond that
> >>>>>> with
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>>>> goals in mind:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> clearer communication and expectation
> management with
> >>>>> the
> >>>>>>>>>>>>> community
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> a user or contributor should be able to
> judge the
> >>>>>>>>>> urgency
> >>>>>>>>>>>> of a
> >>>>>>>>>>>>>>>>>> ticket
> >>>>>>>>>>>>>>>>>>> by its priority
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> if a ticket is assigned to someone the
> expectation
> >>>>> that
> >>>>>>>>>>>>> someone
> >>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>> working on it should hold
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> generally reduce noise in Jira
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> reduce overhead of committers to ask about
> status
> >>>>> updates
> >>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>> contributions or bug reports
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> “Are you still working on this?”
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> “Are you still interested in this?”
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> “Does this still happen on Flink 1.x?”
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> “Are you still experiencing this issue?”
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> “What is the status of the implementation”?
> >>>>>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> while still encouraging users to add new
> tickets and to
> >>>>>>>>>> leave
> >>>>>>>>>>>>>>>>> feedback
> >>>>>>>>>>>>>>>>>>> about existing tickets
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Please see the full proposal here:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> <
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> >
> >>>>>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The idea would be to discuss this proposal in this
> thread.
> >>>>>> If
> >>>>>>>>>> we
> >>>>>>>>>>>>> come
> >>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>> conclusion, I'd document the proposal in the wiki
> [2] and
> >>>>> we
> >>>>>>>>>>> would
> >>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>>> vote on it (approval by "Lazy Majority").
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Konstantin
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> <
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> >
> >>>>>>>>>>>>>>>>>>> [2]
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> <
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> >
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Konstantin Knauf
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> https://twitter.com/snntrable <
> https://twitter.com/snntrable>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> https://github.com/knaufk <
> https://github.com/knaufk>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>>
> >>>>>>>>>> Konstantin Knauf
> >>>>>>>>>>
> >>>>>>>>>> https://twitter.com/snntrable <
> https://twitter.com/snntrable>
> >>>>>>>>>>
> >>>>>>>>>> https://github.com/knaufk <https://github.com/knaufk>
> >>>>>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Konstantin Knauf
> >>>>>>>
> >>>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable>
> >>>>>>>
> >>>>>>> https://github.com/knaufk <https://github.com/knaufk>
> >>>>>>>
> >>>>>> --
> >>>>>>
> >>>>>> Konstantin Knauf
> >>>>>>
> >>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable>
> >>>>>>
> >>>>>> https://github.com/knaufk <https://github.com/knaufk>
> >>>>>>
> >
> >
> >
> > --
> >
> > Konstantin Knauf| Head of Product
> >
> > +49 160 91394525
> >
> >
> > Follow us @VervericaData Ververica <https://www.ververica.com/>
> >
> >
> > --
> >
> > Join Flink Forward <https://flink-forward.org/>- The Apache
> > FlinkConference
> >
> > Stream Processing | Event Driven | Real Time
> >
> > --
> >
> > Ververica GmbH| Invalidenstrasse 115, 10115 Berlin, Germany
> >
> > --
> >
> > Ververica GmbHRegistered at Amtsgericht Charlottenburg: HRB 158244
> > BManaging Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl
> > Anton Wehner
>
>
>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Chesnay Schepler <ch...@apache.org>.
FLINK-21152 is special because we usually know quite early that it must
be done (e.g., because we bump some dependency in flink-shaded at the
start of the release cycle), but only do it shortly before a release to
avoid wasting time on multiple flink-shaded release cycles for a single
Flink release.
I don't think there are many instances of such issues.
On 3/26/2021 11:11 AM, Konstantin Knauf wrote:
> My proposal does not have an answer for this.
>
> Is "Blocker" often used for this, right now? What is special about
> FLINK-21152 compared to other important bug fixes/features for the
> release that makes it a Blocker?
>
> It also ties a bit into the question of what "fixVersion" means. I
> think, right now it means something like "targeted for this release"
> ranging from "basically a must have" and "would be nice if someone
> picks it up". If "fixVersion" would mean "there is a concrete plan to
> have this in the release", it might be less of a problem.
>
>
>
> On Fri, Mar 26, 2021 at 11:03 AM Chesnay Schepler <chesnay@apache.org
> <ma...@apache.org>> wrote:
>
> That's a fair point, but then that raises the question how tasks
> are documented that /must/ be done for a release /at some point/.
> The current approach allows me to easily setup a signal for the
> Release Manager that this ticket must be completed. How would that
> work in your proposal?
>
> On 3/26/2021 9:18 AM, Konstantin Knauf wrote:
>> Hi Chesnay,
>>
>> a blocker is currently defined in the Flink Confluence as a "needs to be
>> resolved before a release (matched based on fix versions)" whereas I was
>> thinking of it as a "someone needs to stop their work to fix this" kind of
>> thing. In the proposal I shared a blocker is therefore defined as
>> "infrastructure
>> failures, bugs that block a release". With this definition FLINK-21152
>> would not be blocker, or would it? Cheers, Konstantin
>>
>> On Fri, Mar 26, 2021 at 8:55 AM Chesnay Schepler<ch...@apache.org> <ma...@apache.org> 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<ar...@apache.org> <ma...@apache.org> 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<kn...@apache.org> <ma...@apache.org>
>>>>> 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<kn...@apache.org> <ma...@apache.org>
>>>>>> 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<xb...@gmail.com> <ma...@gmail.com> 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<to...@gmail.com> <ma...@gmail.com> 写道：
>>>>>>>>>
>>>>>>>>> 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<kn...@apache.org> <ma...@apache.org>
>>>>>>>> wrote:
>>>>>>>>>> Hi everyone,
>>>>>>>>>>
>>>>>>>>>> Thank you for all the comments so far. As proposed, I have dropped
>>>>>> the
>>>>>>>>>> "Trivial" Priority.
>>>>>>>>>>
>>>>>>>>>> I also added another section "Rules in Detail" to the document
>>>>> adding
>>>>>>>> some
>>>>>>>>>> concrete numbers & labels that implement the rules. As a TLDR, here
>>>>>> is
>>>>>>>> an
>>>>>>>>>> example of the flow for a "Blocker", that is created and assigned
>>>>> to
>>>>>> a
>>>>>>>>>> user, but never receives any updates afterwards.
>>>>>>>>>>
>>>>>>>>>> Day
>>>>>>>>>>
>>>>>>>>>> Status
>>>>>>>>>>
>>>>>>>>>> Priority
>>>>>>>>>>
>>>>>>>>>> Labels
>>>>>>>>>>
>>>>>>>>>> 0
>>>>>>>>>>
>>>>>>>>>> Open
>>>>>>>>>>
>>>>>>>>>> Blocker
>>>>>>>>>>
>>>>>>>>>> 7
>>>>>>>>>>
>>>>>>>>>> Open
>>>>>>>>>>
>>>>>>>>>> Blocker
>>>>>>>>>>
>>>>>>>>>> stale-assigned
>>>>>>>>>>
>>>>>>>>>> 14
>>>>>>>>>>
>>>>>>>>>> Open
>>>>>>>>>>
>>>>>>>>>> Blocker
>>>>>>>>>>
>>>>>>>>>> auto-unassigned
>>>>>>>>>>
>>>>>>>>>> 15
>>>>>>>>>>
>>>>>>>>>> Open
>>>>>>>>>>
>>>>>>>>>> Blocker
>>>>>>>>>>
>>>>>>>>>> auto-unassigned, stale-blocker
>>>>>>>>>>
>>>>>>>>>> 22
>>>>>>>>>>
>>>>>>>>>> Open
>>>>>>>>>>
>>>>>>>>>> Critical
>>>>>>>>>>
>>>>>>>>>> auto-unassigned, auto-deprioritized-blocker
>>>>>>>>>>
>>>>>>>>>> 29
>>>>>>>>>>
>>>>>>>>>> Open
>>>>>>>>>>
>>>>>>>>>> Critical
>>>>>>>>>>
>>>>>>>>>> auto-unassigned, auto-deprioritized-blocker, stale-critical
>>>>>>>>>>
>>>>>>>>>> 36
>>>>>>>>>>
>>>>>>>>>> Open
>>>>>>>>>>
>>>>>>>>>> Major
>>>>>>>>>>
>>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>>>>> auto-deprioritized-critical
>>>>>>>>>> 66
>>>>>>>>>>
>>>>>>>>>> Open
>>>>>>>>>>
>>>>>>>>>> Major
>>>>>>>>>>
>>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>>>>> auto-deprioritized-critical,
>>>>>>>>>> stale-major
>>>>>>>>>>
>>>>>>>>>> 73
>>>>>>>>>>
>>>>>>>>>> Open
>>>>>>>>>>
>>>>>>>>>> Minor
>>>>>>>>>>
>>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>>>>> auto-deprioritized-critical,
>>>>>>>>>> auto-deprioritized-major
>>>>>>>>>>
>>>>>>>>>> 263
>>>>>>>>>>
>>>>>>>>>> Open
>>>>>>>>>>
>>>>>>>>>> Minor
>>>>>>>>>>
>>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>>>>> auto-deprioritized-critical,
>>>>>>>>>> auto-deprioritized-major, stale-minor
>>>>>>>>>>
>>>>>>>>>> 270
>>>>>>>>>>
>>>>>>>>>> Closed
>>>>>>>>>>
>>>>>>>>>> Minor
>>>>>>>>>>
>>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>>>>> auto-deprioritized-critical,
>>>>>>>>>> auto-deprioritized-major, auto-closed
>>>>>>>>>>
>>>>>>>>>> I am looking forward to further comments and would otherwise
>>>>> proceed
>>>>>>>> to a
>>>>>>>>>> vote towards the end of next week.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Konstantin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rmetzger@apache.org <ma...@apache.org>
>>>>>>>> wrote:
>>>>>>>>>>> Thanks a lot for the proposal!
>>>>>>>>>>>
>>>>>>>>>>> +1 for doing it!
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
>>>>>>>>>>> khachatryan.roman@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Konstantin,
>>>>>>>>>>>>
>>>>>>>>>>>> I think we should try it out.
>>>>>>>>>>>> Even if tickets don't work well it can be a good step towards
>>>>>>>> managing
>>>>>>>>>>>> technical debt in some other way, like wiki.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Roman
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
>>>>>>>>>> dwysakowicz@apache.org <ma...@apache.org>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I'd be fine with dropping the "Trivial" priority in favour of
>>>>>>>>>> "starter"
>>>>>>>>>>>>> label.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dawid
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 01/03/2021 11:53, Konstantin Knauf wrote:
>>>>>>>>>>>>>> Hi Dawid,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the feedback. Do you think we should simply get rid
>>>>> of
>>>>>>>>>> the
>>>>>>>>>>>>>> "Trivial" priority then and use the "starter" label more
>>>>>>>>>>> aggressively?
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
>>>>>>>>>>>> dwysakowicz@apache.org <ma...@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Konstantin,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I also like the idea.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Two comments:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * you describe the "Trivial" priority as one that needs to be
>>>>>>>>>>>>>>> implemented immediately. First of all it is not used to often,
>>>>>>>>>> but I
>>>>>>>>>>>>>>> think the way it works now is similar with a "starter" label.
>>>>>>>>>> Tasks
>>>>>>>>>>>> that
>>>>>>>>>>>>>>> are not bugs, are easy to implement and we think they are fine
>>>>>> to
>>>>>>>>>> be
>>>>>>>>>>>>>>> taken by newcomers. Therefore they do not fall in my mind into
>>>>>>>>>>>>>>> "immediately" category.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * I would still deprioritise test instabilities. I think there
>>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>>> be a problem with that. We do post links to all failures
>>>>>> therefore
>>>>>>>>>>> it
>>>>>>>>>>>>>>> will automatically priortise the tasks according to failure
>>>>>>>>>>>> frequencies.
>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Dawid
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote:
>>>>>>>>>>>>>>>> Hi Xintong,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> yes, such labels would make a lot of sense. I added a
>>>>> sentence
>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>>>>>>> document.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
>>>>>>>>>> tonysong820@gmail.com <ma...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Thanks for driving this discussion, Konstantin.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I like the idea of having a bot reminding
>>>>>>>>>>> reporter/assignee/watchers
>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>> inactive tickets and if needed downgrade/close them
>>>>>>>>>> automatically.
>>>>>>>>>>>>>>>>> My two cents:
>>>>>>>>>>>>>>>>> We may have labels like "downgraded-by-bot" /
>>>>> "closed-by-bot",
>>>>>>>>>> so
>>>>>>>>>>>> that
>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>> easier to filter and review tickets updated by the bot.
>>>>>>>>>>>>>>>>> We may want to review such tickets (e.g., monthly) in case a
>>>>>>>>>> valid
>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>> failed to draw the attention of relevant committers and the
>>>>>>>>>>> reporter
>>>>>>>>>>>>>>>>> doesn't know who to ping.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you~
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Xintong Song
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
>>>>>>>>>>> trohrmann@apache.org <ma...@apache.org>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks for starting this discussion Konstantin. I like your
>>>>>>>>>>>> proposal
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> also the idea of automating the tedious parts of it via a
>>>>>> bot.
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>> Till
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
>>>>>>>>>>>> knaufk@apache.org <ma...@apache.org>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Dear Flink Community,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I would like to start a discussion on improving and to
>>>>> some
>>>>>>>>>>> extent
>>>>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>>>>>>> defining the way we work with Jira. Some aspects have been
>>>>>>>>>>>>> discussed a
>>>>>>>>>>>>>>>>>>> while back [1], but I would like to go a bit beyond that
>>>>>> with
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>> goals in mind:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> clearer communication and expectation management with
>>>>> the
>>>>>>>>>>>>> community
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> a user or contributor should be able to judge the
>>>>>>>>>> urgency
>>>>>>>>>>>> of a
>>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>>> by its priority
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> if a ticket is assigned to someone the expectation
>>>>> that
>>>>>>>>>>>>> someone
>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> working on it should hold
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> generally reduce noise in Jira
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> reduce overhead of committers to ask about status
>>>>> updates
>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> contributions or bug reports
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> “Are you still working on this?”
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> “Are you still interested in this?”
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> “Does this still happen on Flink 1.x?”
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> “Are you still experiencing this issue?”
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> “What is the status of the implementation”?
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> while still encouraging users to add new tickets and to
>>>>>>>>>> leave
>>>>>>>>>>>>>>>>> feedback
>>>>>>>>>>>>>>>>>>> about existing tickets
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Please see the full proposal here:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit# <https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#>
>>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The idea would be to discuss this proposal in this thread.
>>>>>> If
>>>>>>>>>> we
>>>>>>>>>>>>> come
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>> conclusion, I'd document the proposal in the wiki [2] and
>>>>> we
>>>>>>>>>>> would
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>>> vote on it (approval by "Lazy Majority").
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E <https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E>
>>>>>>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions <https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Konstantin Knauf
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://github.com/knaufk <https://github.com/knaufk>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Konstantin Knauf
>>>>>>>>>>
>>>>>>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable>
>>>>>>>>>>
>>>>>>>>>> https://github.com/knaufk <https://github.com/knaufk>
>>>>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Konstantin Knauf
>>>>>>>
>>>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable>
>>>>>>>
>>>>>>> https://github.com/knaufk <https://github.com/knaufk>
>>>>>>>
>>>>>> --
>>>>>>
>>>>>> Konstantin Knauf
>>>>>>
>>>>>> https://twitter.com/snntrable <https://twitter.com/snntrable>
>>>>>>
>>>>>> https://github.com/knaufk <https://github.com/knaufk>
>>>>>>
>
>
>
> --
>
> Konstantin Knauf| Head of Product
>
> +49 160 91394525
>
>
> Follow us @VervericaData Ververica <https://www.ververica.com/>
>
>
> --
>
> Join Flink Forward <https://flink-forward.org/>- The Apache
> FlinkConference
>
> Stream Processing | Event Driven | Real Time
>
> --
>
> Ververica GmbH| Invalidenstrasse 115, 10115 Berlin, Germany
>
> --
>
> Ververica GmbHRegistered at Amtsgericht Charlottenburg: HRB 158244
> BManaging Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl
> Anton Wehner
Re: [DISCUSS] Apache Flink Jira Process
Posted by Konstantin Knauf <ko...@ververica.com>.
My proposal does not have an answer for this.
Is "Blocker" often used for this, right now? What is special about
FLINK-21152 compared to other important bug fixes/features for the release
that makes it a Blocker?
It also ties a bit into the question of what "fixVersion" means. I think,
right now it means something like "targeted for this release" ranging from
"basically a must have" and "would be nice if someone picks it up". If
"fixVersion" would mean "there is a concrete plan to have this in the
release", it might be less of a problem.
On Fri, Mar 26, 2021 at 11:03 AM Chesnay Schepler <ch...@apache.org>
wrote:
> That's a fair point, but then that raises the question how tasks are
> documented that *must* be done for a release *at some point*.
> The current approach allows me to easily setup a signal for the Release
> Manager that this ticket must be completed. How would that work in your
> proposal?
>
> On 3/26/2021 9:18 AM, Konstantin Knauf wrote:
>
> Hi Chesnay,
>
> a blocker is currently defined in the Flink Confluence as a "needs to be
> resolved before a release (matched based on fix versions)" whereas I was
> thinking of it as a "someone needs to stop their work to fix this" kind of
> thing. In the proposal I shared a blocker is therefore defined as
> "infrastructure
> failures, bugs that block a release". With this definition FLINK-21152
> would not be blocker, or would it? Cheers, Konstantin
>
> On Fri, Mar 26, 2021 at 8:55 AM Chesnay Schepler <ch...@apache.org> <ch...@apache.org> 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 <ar...@apache.org> <ar...@apache.org> 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 <kn...@apache.org> <kn...@apache.org>
> 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 <kn...@apache.org> <kn...@apache.org>
> 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 <xb...@gmail.com> <xb...@gmail.com> 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 <to...@gmail.com> <to...@gmail.com> 写道：
>
> 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 <kn...@apache.org> <kn...@apache.org>
>
> wrote:
>
> Hi everyone,
>
> Thank you for all the comments so far. As proposed, I have dropped
>
> the
>
> "Trivial" Priority.
>
> I also added another section "Rules in Detail" to the document
>
> adding
>
> some
>
> concrete numbers & labels that implement the rules. As a TLDR, here
>
> is
>
> an
>
> example of the flow for a "Blocker", that is created and assigned
>
> to
>
> a
>
> user, but never receives any updates afterwards.
>
> Day
>
> Status
>
> Priority
>
> Labels
>
> 0
>
> Open
>
> Blocker
>
> 7
>
> Open
>
> Blocker
>
> stale-assigned
>
> 14
>
> Open
>
> Blocker
>
> auto-unassigned
>
> 15
>
> Open
>
> Blocker
>
> auto-unassigned, stale-blocker
>
> 22
>
> Open
>
> Critical
>
> auto-unassigned, auto-deprioritized-blocker
>
> 29
>
> Open
>
> Critical
>
> auto-unassigned, auto-deprioritized-blocker, stale-critical
>
> 36
>
> Open
>
> Major
>
> auto-unassigned, auto-deprioritized-blocker,
>
> auto-deprioritized-critical
>
> 66
>
> Open
>
> Major
>
> auto-unassigned, auto-deprioritized-blocker,
>
> auto-deprioritized-critical,
>
> stale-major
>
> 73
>
> Open
>
> Minor
>
> auto-unassigned, auto-deprioritized-blocker,
>
> auto-deprioritized-critical,
>
> auto-deprioritized-major
>
> 263
>
> Open
>
> Minor
>
> auto-unassigned, auto-deprioritized-blocker,
>
> auto-deprioritized-critical,
>
> auto-deprioritized-major, stale-minor
>
> 270
>
> Closed
>
> Minor
>
> auto-unassigned, auto-deprioritized-blocker,
>
> auto-deprioritized-critical,
>
> auto-deprioritized-major, auto-closed
>
> I am looking forward to further comments and would otherwise
>
> proceed
>
> to a
>
> vote towards the end of next week.
>
> Cheers,
>
> Konstantin
>
>
> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rmetzger@apache.org
>
> wrote:
>
> Thanks a lot for the proposal!
>
> +1 for doing it!
>
> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <kh...@gmail.com> wrote:
>
>
> Hi Konstantin,
>
> I think we should try it out.
> Even if tickets don't work well it can be a good step towards
>
> managing
>
> technical debt in some other way, like wiki.
>
> Thanks!
>
> Regards,
> Roman
>
>
> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
>
> dwysakowicz@apache.org>
>
> wrote:
>
>
> I'd be fine with dropping the "Trivial" priority in favour of
>
> "starter"
>
> label.
>
> Best,
>
> Dawid
>
> On 01/03/2021 11:53, Konstantin Knauf wrote:
>
> Hi Dawid,
>
> Thanks for the feedback. Do you think we should simply get rid
>
> of
>
> the
>
> "Trivial" priority then and use the "starter" label more
>
> aggressively?
>
> Best,
>
> Konstantin
>
> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
>
> dwysakowicz@apache.org
>
> wrote:
>
>
> Hi Konstantin,
>
> I also like the idea.
>
> Two comments:
>
> * you describe the "Trivial" priority as one that needs to be
> implemented immediately. First of all it is not used to often,
>
> but I
>
> think the way it works now is similar with a "starter" label.
>
> Tasks
>
> that
>
> are not bugs, are easy to implement and we think they are fine
>
> to
>
> be
>
> taken by newcomers. Therefore they do not fall in my mind into
> "immediately" category.
>
> * I would still deprioritise test instabilities. I think there
>
> shouldn't
>
> be a problem with that. We do post links to all failures
>
> therefore
>
> it
>
> will automatically priortise the tasks according to failure
>
> frequencies.
>
> Best,
>
> Dawid
>
> On 01/03/2021 09:38, Konstantin Knauf wrote:
>
> Hi Xintong,
>
> yes, such labels would make a lot of sense. I added a
>
> sentence
>
> to
>
> the
>
> document.
>
> Thanks,
>
> Konstantin
>
> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
>
> tonysong820@gmail.com
>
> wrote:
>
> Thanks for driving this discussion, Konstantin.
>
> I like the idea of having a bot reminding
>
> reporter/assignee/watchers
>
> about
>
> inactive tickets and if needed downgrade/close them
>
> automatically.
>
> My two cents:
> We may have labels like "downgraded-by-bot" /
>
> "closed-by-bot",
>
> so
>
> that
>
> it's
>
> easier to filter and review tickets updated by the bot.
> We may want to review such tickets (e.g., monthly) in case a
>
> valid
>
> ticket
>
> failed to draw the attention of relevant committers and the
>
> reporter
>
> doesn't know who to ping.
>
> Thank you~
>
> Xintong Song
>
>
>
> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
>
> trohrmann@apache.org
>
> wrote:
>
>
> Thanks for starting this discussion Konstantin. I like your
>
> proposal
>
> and
>
> also the idea of automating the tedious parts of it via a
>
> bot.
>
> Cheers,
> Till
>
> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
>
> knaufk@apache.org>
>
> wrote:
>
>
> Dear Flink Community,
>
> I would like to start a discussion on improving and to
>
> some
>
> extent
>
> simply
>
> defining the way we work with Jira. Some aspects have been
>
> discussed a
>
> while back [1], but I would like to go a bit beyond that
>
> with
>
> the
>
> following
>
> goals in mind:
>
>
> -
>
> clearer communication and expectation management with
>
> the
>
> community
>
> -
>
> a user or contributor should be able to judge the
>
> urgency
>
> of a
>
> ticket
>
> by its priority
> -
>
> if a ticket is assigned to someone the expectation
>
> that
>
> someone
>
> is
>
> working on it should hold
> -
>
> generally reduce noise in Jira
> -
>
> reduce overhead of committers to ask about status
>
> updates
>
> of
>
> contributions or bug reports
> -
>
> “Are you still working on this?”
> -
>
> “Are you still interested in this?”
> -
>
> “Does this still happen on Flink 1.x?”
> -
>
> “Are you still experiencing this issue?”
> -
>
> “What is the status of the implementation”?
> -
>
> while still encouraging users to add new tickets and to
>
> leave
>
> feedback
>
> about existing tickets
>
>
> Please see the full proposal here:
>
>
>
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
>
> .
>
> The idea would be to discuss this proposal in this thread.
>
> If
>
> we
>
> come
>
> to
>
> a
>
> conclusion, I'd document the proposal in the wiki [2] and
>
> we
>
> would
>
> then
>
> vote on it (approval by "Lazy Majority").
>
> Cheers,
>
> Konstantin
>
> [1]
>
>
>
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
>
> [2]
>
>
>
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
>
> --
>
> Konstantin Knauf
> https://twitter.com/snntrable
> https://github.com/knaufk
>
> --
>
> Konstantin Knauf
> https://twitter.com/snntrable
> https://github.com/knaufk
>
> --
>
> Konstantin Knauf
> https://twitter.com/snntrable
> https://github.com/knaufk
>
> --
>
> Konstantin Knauf
> https://twitter.com/snntrable
> https://github.com/knaufk
>
>
>
--
Konstantin Knauf | Head of Product
+49 160 91394525
Follow us @VervericaData Ververica <https://www.ververica.com/>
--
Join Flink Forward <https://flink-forward.org/> - The Apache Flink
Conference
Stream Processing | Event Driven | Real Time
--
Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany
--
Ververica GmbH
Registered at Amtsgericht Charlottenburg: HRB 158244 B
Managing Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl Anton
Wehner
Re: [DISCUSS] Apache Flink Jira Process
Posted by Chesnay Schepler <ch...@apache.org>.
That's a fair point, but then that raises the question how tasks are
documented that /must/ be done for a release /at some point/.
The current approach allows me to easily setup a signal for the Release
Manager that this ticket must be completed. How would that work in your
proposal?
On 3/26/2021 9:18 AM, Konstantin Knauf wrote:
> Hi Chesnay,
>
> a blocker is currently defined in the Flink Confluence as a "needs to be
> resolved before a release (matched based on fix versions)" whereas I was
> thinking of it as a "someone needs to stop their work to fix this" kind of
> thing. In the proposal I shared a blocker is therefore defined as
> "infrastructure
> failures, bugs that block a release". With this definition FLINK-21152
> would not be blocker, or would it? Cheers, Konstantin
>
> On Fri, Mar 26, 2021 at 8:55 AM Chesnay Schepler <ch...@apache.org> 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 <ar...@apache.org> 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 <kn...@apache.org>
>>>> 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 <kn...@apache.org>
>>>>> 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 <xb...@gmail.com> 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 <to...@gmail.com> 写道：
>>>>>>>>
>>>>>>>> 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 <kn...@apache.org>
>>>>>>> wrote:
>>>>>>>>> Hi everyone,
>>>>>>>>>
>>>>>>>>> Thank you for all the comments so far. As proposed, I have dropped
>>>>> the
>>>>>>>>> "Trivial" Priority.
>>>>>>>>>
>>>>>>>>> I also added another section "Rules in Detail" to the document
>>>> adding
>>>>>>> some
>>>>>>>>> concrete numbers & labels that implement the rules. As a TLDR, here
>>>>> is
>>>>>>> an
>>>>>>>>> example of the flow for a "Blocker", that is created and assigned
>>>> to
>>>>> a
>>>>>>>>> user, but never receives any updates afterwards.
>>>>>>>>>
>>>>>>>>> Day
>>>>>>>>>
>>>>>>>>> Status
>>>>>>>>>
>>>>>>>>> Priority
>>>>>>>>>
>>>>>>>>> Labels
>>>>>>>>>
>>>>>>>>> 0
>>>>>>>>>
>>>>>>>>> Open
>>>>>>>>>
>>>>>>>>> Blocker
>>>>>>>>>
>>>>>>>>> 7
>>>>>>>>>
>>>>>>>>> Open
>>>>>>>>>
>>>>>>>>> Blocker
>>>>>>>>>
>>>>>>>>> stale-assigned
>>>>>>>>>
>>>>>>>>> 14
>>>>>>>>>
>>>>>>>>> Open
>>>>>>>>>
>>>>>>>>> Blocker
>>>>>>>>>
>>>>>>>>> auto-unassigned
>>>>>>>>>
>>>>>>>>> 15
>>>>>>>>>
>>>>>>>>> Open
>>>>>>>>>
>>>>>>>>> Blocker
>>>>>>>>>
>>>>>>>>> auto-unassigned, stale-blocker
>>>>>>>>>
>>>>>>>>> 22
>>>>>>>>>
>>>>>>>>> Open
>>>>>>>>>
>>>>>>>>> Critical
>>>>>>>>>
>>>>>>>>> auto-unassigned, auto-deprioritized-blocker
>>>>>>>>>
>>>>>>>>> 29
>>>>>>>>>
>>>>>>>>> Open
>>>>>>>>>
>>>>>>>>> Critical
>>>>>>>>>
>>>>>>>>> auto-unassigned, auto-deprioritized-blocker, stale-critical
>>>>>>>>>
>>>>>>>>> 36
>>>>>>>>>
>>>>>>>>> Open
>>>>>>>>>
>>>>>>>>> Major
>>>>>>>>>
>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>>>> auto-deprioritized-critical
>>>>>>>>> 66
>>>>>>>>>
>>>>>>>>> Open
>>>>>>>>>
>>>>>>>>> Major
>>>>>>>>>
>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>>>> auto-deprioritized-critical,
>>>>>>>>> stale-major
>>>>>>>>>
>>>>>>>>> 73
>>>>>>>>>
>>>>>>>>> Open
>>>>>>>>>
>>>>>>>>> Minor
>>>>>>>>>
>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>>>> auto-deprioritized-critical,
>>>>>>>>> auto-deprioritized-major
>>>>>>>>>
>>>>>>>>> 263
>>>>>>>>>
>>>>>>>>> Open
>>>>>>>>>
>>>>>>>>> Minor
>>>>>>>>>
>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>>>> auto-deprioritized-critical,
>>>>>>>>> auto-deprioritized-major, stale-minor
>>>>>>>>>
>>>>>>>>> 270
>>>>>>>>>
>>>>>>>>> Closed
>>>>>>>>>
>>>>>>>>> Minor
>>>>>>>>>
>>>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>>>> auto-deprioritized-critical,
>>>>>>>>> auto-deprioritized-major, auto-closed
>>>>>>>>>
>>>>>>>>> I am looking forward to further comments and would otherwise
>>>> proceed
>>>>>>> to a
>>>>>>>>> vote towards the end of next week.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Konstantin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rmetzger@apache.org
>>>>>>> wrote:
>>>>>>>>>> Thanks a lot for the proposal!
>>>>>>>>>>
>>>>>>>>>> +1 for doing it!
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
>>>>>>>>>> khachatryan.roman@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Konstantin,
>>>>>>>>>>>
>>>>>>>>>>> I think we should try it out.
>>>>>>>>>>> Even if tickets don't work well it can be a good step towards
>>>>>>> managing
>>>>>>>>>>> technical debt in some other way, like wiki.
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Roman
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
>>>>>>>>> dwysakowicz@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I'd be fine with dropping the "Trivial" priority in favour of
>>>>>>>>> "starter"
>>>>>>>>>>>> label.
>>>>>>>>>>>>
>>>>>>>>>>>> Best,
>>>>>>>>>>>>
>>>>>>>>>>>> Dawid
>>>>>>>>>>>>
>>>>>>>>>>>> On 01/03/2021 11:53, Konstantin Knauf wrote:
>>>>>>>>>>>>> Hi Dawid,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the feedback. Do you think we should simply get rid
>>>> of
>>>>>>>>> the
>>>>>>>>>>>>> "Trivial" priority then and use the "starter" label more
>>>>>>>>>> aggressively?
>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
>>>>>>>>>>> dwysakowicz@apache.org
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Konstantin,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I also like the idea.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Two comments:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * you describe the "Trivial" priority as one that needs to be
>>>>>>>>>>>>>> implemented immediately. First of all it is not used to often,
>>>>>>>>> but I
>>>>>>>>>>>>>> think the way it works now is similar with a "starter" label.
>>>>>>>>> Tasks
>>>>>>>>>>> that
>>>>>>>>>>>>>> are not bugs, are easy to implement and we think they are fine
>>>>> to
>>>>>>>>> be
>>>>>>>>>>>>>> taken by newcomers. Therefore they do not fall in my mind into
>>>>>>>>>>>>>> "immediately" category.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * I would still deprioritise test instabilities. I think there
>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>> be a problem with that. We do post links to all failures
>>>>> therefore
>>>>>>>>>> it
>>>>>>>>>>>>>> will automatically priortise the tasks according to failure
>>>>>>>>>>> frequencies.
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dawid
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote:
>>>>>>>>>>>>>>> Hi Xintong,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> yes, such labels would make a lot of sense. I added a
>>>> sentence
>>>>> to
>>>>>>>>>> the
>>>>>>>>>>>>>>> document.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
>>>>>>>>> tonysong820@gmail.com
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> Thanks for driving this discussion, Konstantin.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I like the idea of having a bot reminding
>>>>>>>>>> reporter/assignee/watchers
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> inactive tickets and if needed downgrade/close them
>>>>>>>>> automatically.
>>>>>>>>>>>>>>>> My two cents:
>>>>>>>>>>>>>>>> We may have labels like "downgraded-by-bot" /
>>>> "closed-by-bot",
>>>>>>>>> so
>>>>>>>>>>> that
>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>> easier to filter and review tickets updated by the bot.
>>>>>>>>>>>>>>>> We may want to review such tickets (e.g., monthly) in case a
>>>>>>>>> valid
>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>> failed to draw the attention of relevant committers and the
>>>>>>>>>> reporter
>>>>>>>>>>>>>>>> doesn't know who to ping.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you~
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Xintong Song
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
>>>>>>>>>> trohrmann@apache.org
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for starting this discussion Konstantin. I like your
>>>>>>>>>>> proposal
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> also the idea of automating the tedious parts of it via a
>>>>> bot.
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Till
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
>>>>>>>>>>> knaufk@apache.org>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Dear Flink Community,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I would like to start a discussion on improving and to
>>>> some
>>>>>>>>>> extent
>>>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>>>>>> defining the way we work with Jira. Some aspects have been
>>>>>>>>>>>> discussed a
>>>>>>>>>>>>>>>>>> while back [1], but I would like to go a bit beyond that
>>>>> with
>>>>>>>>>> the
>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>> goals in mind:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> clearer communication and expectation management with
>>>> the
>>>>>>>>>>>> community
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> a user or contributor should be able to judge the
>>>>>>>>> urgency
>>>>>>>>>>> of a
>>>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>>>> by its priority
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> if a ticket is assigned to someone the expectation
>>>> that
>>>>>>>>>>>> someone
>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>> working on it should hold
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> generally reduce noise in Jira
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> reduce overhead of committers to ask about status
>>>> updates
>>>>>>>>> of
>>>>>>>>>>>>>>>>>> contributions or bug reports
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> “Are you still working on this?”
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> “Are you still interested in this?”
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> “Does this still happen on Flink 1.x?”
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> “Are you still experiencing this issue?”
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> “What is the status of the implementation”?
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> while still encouraging users to add new tickets and to
>>>>>>>>> leave
>>>>>>>>>>>>>>>> feedback
>>>>>>>>>>>>>>>>>> about existing tickets
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please see the full proposal here:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The idea would be to discuss this proposal in this thread.
>>>>> If
>>>>>>>>> we
>>>>>>>>>>>> come
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> conclusion, I'd document the proposal in the wiki [2] and
>>>> we
>>>>>>>>>> would
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>> vote on it (approval by "Lazy Majority").
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
>>>>>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Konstantin Knauf
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://twitter.com/snntrable
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://github.com/knaufk
>>>>>>>>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Konstantin Knauf
>>>>>>>>>
>>>>>>>>> https://twitter.com/snntrable
>>>>>>>>>
>>>>>>>>> https://github.com/knaufk
>>>>>>>>>
>>>>>> --
>>>>>>
>>>>>> Konstantin Knauf
>>>>>>
>>>>>> https://twitter.com/snntrable
>>>>>>
>>>>>> https://github.com/knaufk
>>>>>>
>>>>> --
>>>>>
>>>>> Konstantin Knauf
>>>>>
>>>>> https://twitter.com/snntrable
>>>>>
>>>>> https://github.com/knaufk
>>>>>
>>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Konstantin Knauf <ko...@ververica.com>.
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 <ch...@apache.org> 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 <ar...@apache.org> 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 <kn...@apache.org>
> >> 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 <kn...@apache.org>
> >>> 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 <xb...@gmail.com> 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 <to...@gmail.com> 写道：
> >>>>>>
> >>>>>> 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 <kn...@apache.org>
> >>>>> wrote:
> >>>>>>> Hi everyone,
> >>>>>>>
> >>>>>>> Thank you for all the comments so far. As proposed, I have dropped
> >>> the
> >>>>>>> "Trivial" Priority.
> >>>>>>>
> >>>>>>> I also added another section "Rules in Detail" to the document
> >> adding
> >>>>> some
> >>>>>>> concrete numbers & labels that implement the rules. As a TLDR, here
> >>> is
> >>>>> an
> >>>>>>> example of the flow for a "Blocker", that is created and assigned
> >> to
> >>> a
> >>>>>>> user, but never receives any updates afterwards.
> >>>>>>>
> >>>>>>> Day
> >>>>>>>
> >>>>>>> Status
> >>>>>>>
> >>>>>>> Priority
> >>>>>>>
> >>>>>>> Labels
> >>>>>>>
> >>>>>>> 0
> >>>>>>>
> >>>>>>> Open
> >>>>>>>
> >>>>>>> Blocker
> >>>>>>>
> >>>>>>> 7
> >>>>>>>
> >>>>>>> Open
> >>>>>>>
> >>>>>>> Blocker
> >>>>>>>
> >>>>>>> stale-assigned
> >>>>>>>
> >>>>>>> 14
> >>>>>>>
> >>>>>>> Open
> >>>>>>>
> >>>>>>> Blocker
> >>>>>>>
> >>>>>>> auto-unassigned
> >>>>>>>
> >>>>>>> 15
> >>>>>>>
> >>>>>>> Open
> >>>>>>>
> >>>>>>> Blocker
> >>>>>>>
> >>>>>>> auto-unassigned, stale-blocker
> >>>>>>>
> >>>>>>> 22
> >>>>>>>
> >>>>>>> Open
> >>>>>>>
> >>>>>>> Critical
> >>>>>>>
> >>>>>>> auto-unassigned, auto-deprioritized-blocker
> >>>>>>>
> >>>>>>> 29
> >>>>>>>
> >>>>>>> Open
> >>>>>>>
> >>>>>>> Critical
> >>>>>>>
> >>>>>>> auto-unassigned, auto-deprioritized-blocker, stale-critical
> >>>>>>>
> >>>>>>> 36
> >>>>>>>
> >>>>>>> Open
> >>>>>>>
> >>>>>>> Major
> >>>>>>>
> >>>>>>> auto-unassigned, auto-deprioritized-blocker,
> >>>>> auto-deprioritized-critical
> >>>>>>> 66
> >>>>>>>
> >>>>>>> Open
> >>>>>>>
> >>>>>>> Major
> >>>>>>>
> >>>>>>> auto-unassigned, auto-deprioritized-blocker,
> >>>>> auto-deprioritized-critical,
> >>>>>>> stale-major
> >>>>>>>
> >>>>>>> 73
> >>>>>>>
> >>>>>>> Open
> >>>>>>>
> >>>>>>> Minor
> >>>>>>>
> >>>>>>> auto-unassigned, auto-deprioritized-blocker,
> >>>>> auto-deprioritized-critical,
> >>>>>>> auto-deprioritized-major
> >>>>>>>
> >>>>>>> 263
> >>>>>>>
> >>>>>>> Open
> >>>>>>>
> >>>>>>> Minor
> >>>>>>>
> >>>>>>> auto-unassigned, auto-deprioritized-blocker,
> >>>>> auto-deprioritized-critical,
> >>>>>>> auto-deprioritized-major, stale-minor
> >>>>>>>
> >>>>>>> 270
> >>>>>>>
> >>>>>>> Closed
> >>>>>>>
> >>>>>>> Minor
> >>>>>>>
> >>>>>>> auto-unassigned, auto-deprioritized-blocker,
> >>>>> auto-deprioritized-critical,
> >>>>>>> auto-deprioritized-major, auto-closed
> >>>>>>>
> >>>>>>> I am looking forward to further comments and would otherwise
> >> proceed
> >>>>> to a
> >>>>>>> vote towards the end of next week.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>>
> >>>>>>> Konstantin
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rmetzger@apache.org
> >>>>> wrote:
> >>>>>>>> Thanks a lot for the proposal!
> >>>>>>>>
> >>>>>>>> +1 for doing it!
> >>>>>>>>
> >>>>>>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
> >>>>>>>> khachatryan.roman@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Konstantin,
> >>>>>>>>>
> >>>>>>>>> I think we should try it out.
> >>>>>>>>> Even if tickets don't work well it can be a good step towards
> >>>>> managing
> >>>>>>>>> technical debt in some other way, like wiki.
> >>>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Roman
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
> >>>>>>> dwysakowicz@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I'd be fine with dropping the "Trivial" priority in favour of
> >>>>>>> "starter"
> >>>>>>>>>> label.
> >>>>>>>>>>
> >>>>>>>>>> Best,
> >>>>>>>>>>
> >>>>>>>>>> Dawid
> >>>>>>>>>>
> >>>>>>>>>> On 01/03/2021 11:53, Konstantin Knauf wrote:
> >>>>>>>>>>> Hi Dawid,
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks for the feedback. Do you think we should simply get rid
> >> of
> >>>>>>> the
> >>>>>>>>>>> "Trivial" priority then and use the "starter" label more
> >>>>>>>> aggressively?
> >>>>>>>>>>> Best,
> >>>>>>>>>>>
> >>>>>>>>>>> Konstantin
> >>>>>>>>>>>
> >>>>>>>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
> >>>>>>>>> dwysakowicz@apache.org
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Konstantin,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I also like the idea.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Two comments:
> >>>>>>>>>>>>
> >>>>>>>>>>>> * you describe the "Trivial" priority as one that needs to be
> >>>>>>>>>>>> implemented immediately. First of all it is not used to often,
> >>>>>>> but I
> >>>>>>>>>>>> think the way it works now is similar with a "starter" label.
> >>>>>>> Tasks
> >>>>>>>>> that
> >>>>>>>>>>>> are not bugs, are easy to implement and we think they are fine
> >>> to
> >>>>>>> be
> >>>>>>>>>>>> taken by newcomers. Therefore they do not fall in my mind into
> >>>>>>>>>>>> "immediately" category.
> >>>>>>>>>>>>
> >>>>>>>>>>>> * I would still deprioritise test instabilities. I think there
> >>>>>>>>> shouldn't
> >>>>>>>>>>>> be a problem with that. We do post links to all failures
> >>> therefore
> >>>>>>>> it
> >>>>>>>>>>>> will automatically priortise the tasks according to failure
> >>>>>>>>> frequencies.
> >>>>>>>>>>>> Best,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Dawid
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote:
> >>>>>>>>>>>>> Hi Xintong,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> yes, such labels would make a lot of sense. I added a
> >> sentence
> >>> to
> >>>>>>>> the
> >>>>>>>>>>>>> document.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Konstantin
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
> >>>>>>> tonysong820@gmail.com
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> Thanks for driving this discussion, Konstantin.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I like the idea of having a bot reminding
> >>>>>>>> reporter/assignee/watchers
> >>>>>>>>>>>> about
> >>>>>>>>>>>>>> inactive tickets and if needed downgrade/close them
> >>>>>>> automatically.
> >>>>>>>>>>>>>> My two cents:
> >>>>>>>>>>>>>> We may have labels like "downgraded-by-bot" /
> >> "closed-by-bot",
> >>>>>>> so
> >>>>>>>>> that
> >>>>>>>>>>>> it's
> >>>>>>>>>>>>>> easier to filter and review tickets updated by the bot.
> >>>>>>>>>>>>>> We may want to review such tickets (e.g., monthly) in case a
> >>>>>>> valid
> >>>>>>>>>>>> ticket
> >>>>>>>>>>>>>> failed to draw the attention of relevant committers and the
> >>>>>>>> reporter
> >>>>>>>>>>>>>> doesn't know who to ping.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thank you~
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Xintong Song
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
> >>>>>>>> trohrmann@apache.org
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks for starting this discussion Konstantin. I like your
> >>>>>>>>> proposal
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>> also the idea of automating the tedious parts of it via a
> >>> bot.
> >>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>> Till
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
> >>>>>>>>> knaufk@apache.org>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Dear Flink Community,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I would like to start a discussion on improving and to
> >> some
> >>>>>>>> extent
> >>>>>>>>>>>>>> simply
> >>>>>>>>>>>>>>>> defining the way we work with Jira. Some aspects have been
> >>>>>>>>>> discussed a
> >>>>>>>>>>>>>>>> while back [1], but I would like to go a bit beyond that
> >>> with
> >>>>>>>> the
> >>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>> goals in mind:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> clearer communication and expectation management with
> >> the
> >>>>>>>>>> community
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> a user or contributor should be able to judge the
> >>>>>>> urgency
> >>>>>>>>> of a
> >>>>>>>>>>>>>>> ticket
> >>>>>>>>>>>>>>>> by its priority
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> if a ticket is assigned to someone the expectation
> >> that
> >>>>>>>>>> someone
> >>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>> working on it should hold
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> generally reduce noise in Jira
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> reduce overhead of committers to ask about status
> >> updates
> >>>>>>> of
> >>>>>>>>>>>>>>>> contributions or bug reports
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> “Are you still working on this?”
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> “Are you still interested in this?”
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> “Does this still happen on Flink 1.x?”
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> “Are you still experiencing this issue?”
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> “What is the status of the implementation”?
> >>>>>>>>>>>>>>>> -
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> while still encouraging users to add new tickets and to
> >>>>>>> leave
> >>>>>>>>>>>>>> feedback
> >>>>>>>>>>>>>>>> about existing tickets
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Please see the full proposal here:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> >>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The idea would be to discuss this proposal in this thread.
> >>> If
> >>>>>>> we
> >>>>>>>>>> come
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>> conclusion, I'd document the proposal in the wiki [2] and
> >> we
> >>>>>>>> would
> >>>>>>>>>>>> then
> >>>>>>>>>>>>>>>> vote on it (approval by "Lazy Majority").
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Konstantin
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> >>>>>>>>>>>>>>>> [2]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Konstantin Knauf
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> https://twitter.com/snntrable
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> https://github.com/knaufk
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Konstantin Knauf
> >>>>>>>
> >>>>>>> https://twitter.com/snntrable
> >>>>>>>
> >>>>>>> https://github.com/knaufk
> >>>>>>>
> >>>>>
> >>>> --
> >>>>
> >>>> Konstantin Knauf
> >>>>
> >>>> https://twitter.com/snntrable
> >>>>
> >>>> https://github.com/knaufk
> >>>>
> >>>
> >>> --
> >>>
> >>> Konstantin Knauf
> >>>
> >>> https://twitter.com/snntrable
> >>>
> >>> https://github.com/knaufk
> >>>
> >
>
>
--
Konstantin Knauf | Head of Product
+49 160 91394525
Follow us @VervericaData Ververica <https://www.ververica.com/>
--
Join Flink Forward <https://flink-forward.org/> - The Apache Flink
Conference
Stream Processing | Event Driven | Real Time
--
Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany
--
Ververica GmbH
Registered at Amtsgericht Charlottenburg: HRB 158244 B
Managing Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl Anton
Wehner
Re: [DISCUSS] Apache Flink Jira Process
Posted by Chesnay Schepler <ch...@apache.org>.
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 <ar...@apache.org> 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 <kn...@apache.org>
>> 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 <kn...@apache.org>
>>> 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 <xb...@gmail.com> 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 <to...@gmail.com> 写道：
>>>>>>
>>>>>> 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 <kn...@apache.org>
>>>>> wrote:
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> Thank you for all the comments so far. As proposed, I have dropped
>>> the
>>>>>>> "Trivial" Priority.
>>>>>>>
>>>>>>> I also added another section "Rules in Detail" to the document
>> adding
>>>>> some
>>>>>>> concrete numbers & labels that implement the rules. As a TLDR, here
>>> is
>>>>> an
>>>>>>> example of the flow for a "Blocker", that is created and assigned
>> to
>>> a
>>>>>>> user, but never receives any updates afterwards.
>>>>>>>
>>>>>>> Day
>>>>>>>
>>>>>>> Status
>>>>>>>
>>>>>>> Priority
>>>>>>>
>>>>>>> Labels
>>>>>>>
>>>>>>> 0
>>>>>>>
>>>>>>> Open
>>>>>>>
>>>>>>> Blocker
>>>>>>>
>>>>>>> 7
>>>>>>>
>>>>>>> Open
>>>>>>>
>>>>>>> Blocker
>>>>>>>
>>>>>>> stale-assigned
>>>>>>>
>>>>>>> 14
>>>>>>>
>>>>>>> Open
>>>>>>>
>>>>>>> Blocker
>>>>>>>
>>>>>>> auto-unassigned
>>>>>>>
>>>>>>> 15
>>>>>>>
>>>>>>> Open
>>>>>>>
>>>>>>> Blocker
>>>>>>>
>>>>>>> auto-unassigned, stale-blocker
>>>>>>>
>>>>>>> 22
>>>>>>>
>>>>>>> Open
>>>>>>>
>>>>>>> Critical
>>>>>>>
>>>>>>> auto-unassigned, auto-deprioritized-blocker
>>>>>>>
>>>>>>> 29
>>>>>>>
>>>>>>> Open
>>>>>>>
>>>>>>> Critical
>>>>>>>
>>>>>>> auto-unassigned, auto-deprioritized-blocker, stale-critical
>>>>>>>
>>>>>>> 36
>>>>>>>
>>>>>>> Open
>>>>>>>
>>>>>>> Major
>>>>>>>
>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>> auto-deprioritized-critical
>>>>>>> 66
>>>>>>>
>>>>>>> Open
>>>>>>>
>>>>>>> Major
>>>>>>>
>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>> auto-deprioritized-critical,
>>>>>>> stale-major
>>>>>>>
>>>>>>> 73
>>>>>>>
>>>>>>> Open
>>>>>>>
>>>>>>> Minor
>>>>>>>
>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>> auto-deprioritized-critical,
>>>>>>> auto-deprioritized-major
>>>>>>>
>>>>>>> 263
>>>>>>>
>>>>>>> Open
>>>>>>>
>>>>>>> Minor
>>>>>>>
>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>> auto-deprioritized-critical,
>>>>>>> auto-deprioritized-major, stale-minor
>>>>>>>
>>>>>>> 270
>>>>>>>
>>>>>>> Closed
>>>>>>>
>>>>>>> Minor
>>>>>>>
>>>>>>> auto-unassigned, auto-deprioritized-blocker,
>>>>> auto-deprioritized-critical,
>>>>>>> auto-deprioritized-major, auto-closed
>>>>>>>
>>>>>>> I am looking forward to further comments and would otherwise
>> proceed
>>>>> to a
>>>>>>> vote towards the end of next week.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Konstantin
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rmetzger@apache.org
>>>>> wrote:
>>>>>>>> Thanks a lot for the proposal!
>>>>>>>>
>>>>>>>> +1 for doing it!
>>>>>>>>
>>>>>>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
>>>>>>>> khachatryan.roman@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Konstantin,
>>>>>>>>>
>>>>>>>>> I think we should try it out.
>>>>>>>>> Even if tickets don't work well it can be a good step towards
>>>>> managing
>>>>>>>>> technical debt in some other way, like wiki.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Roman
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
>>>>>>> dwysakowicz@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I'd be fine with dropping the "Trivial" priority in favour of
>>>>>>> "starter"
>>>>>>>>>> label.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>>
>>>>>>>>>> Dawid
>>>>>>>>>>
>>>>>>>>>> On 01/03/2021 11:53, Konstantin Knauf wrote:
>>>>>>>>>>> Hi Dawid,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the feedback. Do you think we should simply get rid
>> of
>>>>>>> the
>>>>>>>>>>> "Trivial" priority then and use the "starter" label more
>>>>>>>> aggressively?
>>>>>>>>>>> Best,
>>>>>>>>>>>
>>>>>>>>>>> Konstantin
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
>>>>>>>>> dwysakowicz@apache.org
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Konstantin,
>>>>>>>>>>>>
>>>>>>>>>>>> I also like the idea.
>>>>>>>>>>>>
>>>>>>>>>>>> Two comments:
>>>>>>>>>>>>
>>>>>>>>>>>> * you describe the "Trivial" priority as one that needs to be
>>>>>>>>>>>> implemented immediately. First of all it is not used to often,
>>>>>>> but I
>>>>>>>>>>>> think the way it works now is similar with a "starter" label.
>>>>>>> Tasks
>>>>>>>>> that
>>>>>>>>>>>> are not bugs, are easy to implement and we think they are fine
>>> to
>>>>>>> be
>>>>>>>>>>>> taken by newcomers. Therefore they do not fall in my mind into
>>>>>>>>>>>> "immediately" category.
>>>>>>>>>>>>
>>>>>>>>>>>> * I would still deprioritise test instabilities. I think there
>>>>>>>>> shouldn't
>>>>>>>>>>>> be a problem with that. We do post links to all failures
>>> therefore
>>>>>>>> it
>>>>>>>>>>>> will automatically priortise the tasks according to failure
>>>>>>>>> frequencies.
>>>>>>>>>>>> Best,
>>>>>>>>>>>>
>>>>>>>>>>>> Dawid
>>>>>>>>>>>>
>>>>>>>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote:
>>>>>>>>>>>>> Hi Xintong,
>>>>>>>>>>>>>
>>>>>>>>>>>>> yes, such labels would make a lot of sense. I added a
>> sentence
>>> to
>>>>>>>> the
>>>>>>>>>>>>> document.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
>>>>>>> tonysong820@gmail.com
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Thanks for driving this discussion, Konstantin.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I like the idea of having a bot reminding
>>>>>>>> reporter/assignee/watchers
>>>>>>>>>>>> about
>>>>>>>>>>>>>> inactive tickets and if needed downgrade/close them
>>>>>>> automatically.
>>>>>>>>>>>>>> My two cents:
>>>>>>>>>>>>>> We may have labels like "downgraded-by-bot" /
>> "closed-by-bot",
>>>>>>> so
>>>>>>>>> that
>>>>>>>>>>>> it's
>>>>>>>>>>>>>> easier to filter and review tickets updated by the bot.
>>>>>>>>>>>>>> We may want to review such tickets (e.g., monthly) in case a
>>>>>>> valid
>>>>>>>>>>>> ticket
>>>>>>>>>>>>>> failed to draw the attention of relevant committers and the
>>>>>>>> reporter
>>>>>>>>>>>>>> doesn't know who to ping.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you~
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Xintong Song
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
>>>>>>>> trohrmann@apache.org
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for starting this discussion Konstantin. I like your
>>>>>>>>> proposal
>>>>>>>>>>>> and
>>>>>>>>>>>>>>> also the idea of automating the tedious parts of it via a
>>> bot.
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Till
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
>>>>>>>>> knaufk@apache.org>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Dear Flink Community,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would like to start a discussion on improving and to
>> some
>>>>>>>> extent
>>>>>>>>>>>>>> simply
>>>>>>>>>>>>>>>> defining the way we work with Jira. Some aspects have been
>>>>>>>>>> discussed a
>>>>>>>>>>>>>>>> while back [1], but I would like to go a bit beyond that
>>> with
>>>>>>>> the
>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>> goals in mind:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> clearer communication and expectation management with
>> the
>>>>>>>>>> community
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> a user or contributor should be able to judge the
>>>>>>> urgency
>>>>>>>>> of a
>>>>>>>>>>>>>>> ticket
>>>>>>>>>>>>>>>> by its priority
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> if a ticket is assigned to someone the expectation
>> that
>>>>>>>>>> someone
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> working on it should hold
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> generally reduce noise in Jira
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> reduce overhead of committers to ask about status
>> updates
>>>>>>> of
>>>>>>>>>>>>>>>> contributions or bug reports
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> “Are you still working on this?”
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> “Are you still interested in this?”
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> “Does this still happen on Flink 1.x?”
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> “Are you still experiencing this issue?”
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> “What is the status of the implementation”?
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> while still encouraging users to add new tickets and to
>>>>>>> leave
>>>>>>>>>>>>>> feedback
>>>>>>>>>>>>>>>> about existing tickets
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please see the full proposal here:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The idea would be to discuss this proposal in this thread.
>>> If
>>>>>>> we
>>>>>>>>>> come
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> conclusion, I'd document the proposal in the wiki [2] and
>> we
>>>>>>>> would
>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> vote on it (approval by "Lazy Majority").
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Konstantin
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
>>>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Konstantin Knauf
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://twitter.com/snntrable
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://github.com/knaufk
>>>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Konstantin Knauf
>>>>>>>
>>>>>>> https://twitter.com/snntrable
>>>>>>>
>>>>>>> https://github.com/knaufk
>>>>>>>
>>>>>
>>>> --
>>>>
>>>> Konstantin Knauf
>>>>
>>>> https://twitter.com/snntrable
>>>>
>>>> https://github.com/knaufk
>>>>
>>>
>>> --
>>>
>>> Konstantin Knauf
>>>
>>> https://twitter.com/snntrable
>>>
>>> https://github.com/knaufk
>>>
>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Konstantin Knauf <kn...@apache.org>.
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 <ar...@apache.org> 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 <kn...@apache.org>
> 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 <kn...@apache.org>
> > 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 <xb...@gmail.com> 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 <to...@gmail.com> 写道：
> > >> >
> > >> > 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 <kn...@apache.org>
> > >> wrote:
> > >> >
> > >> >> Hi everyone,
> > >> >>
> > >> >> Thank you for all the comments so far. As proposed, I have dropped
> > the
> > >> >> "Trivial" Priority.
> > >> >>
> > >> >> I also added another section "Rules in Detail" to the document
> adding
> > >> some
> > >> >> concrete numbers & labels that implement the rules. As a TLDR, here
> > is
> > >> an
> > >> >> example of the flow for a "Blocker", that is created and assigned
> to
> > a
> > >> >> user, but never receives any updates afterwards.
> > >> >>
> > >> >> Day
> > >> >>
> > >> >> Status
> > >> >>
> > >> >> Priority
> > >> >>
> > >> >> Labels
> > >> >>
> > >> >> 0
> > >> >>
> > >> >> Open
> > >> >>
> > >> >> Blocker
> > >> >>
> > >> >> 7
> > >> >>
> > >> >> Open
> > >> >>
> > >> >> Blocker
> > >> >>
> > >> >> stale-assigned
> > >> >>
> > >> >> 14
> > >> >>
> > >> >> Open
> > >> >>
> > >> >> Blocker
> > >> >>
> > >> >> auto-unassigned
> > >> >>
> > >> >> 15
> > >> >>
> > >> >> Open
> > >> >>
> > >> >> Blocker
> > >> >>
> > >> >> auto-unassigned, stale-blocker
> > >> >>
> > >> >> 22
> > >> >>
> > >> >> Open
> > >> >>
> > >> >> Critical
> > >> >>
> > >> >> auto-unassigned, auto-deprioritized-blocker
> > >> >>
> > >> >> 29
> > >> >>
> > >> >> Open
> > >> >>
> > >> >> Critical
> > >> >>
> > >> >> auto-unassigned, auto-deprioritized-blocker, stale-critical
> > >> >>
> > >> >> 36
> > >> >>
> > >> >> Open
> > >> >>
> > >> >> Major
> > >> >>
> > >> >> auto-unassigned, auto-deprioritized-blocker,
> > >> auto-deprioritized-critical
> > >> >>
> > >> >> 66
> > >> >>
> > >> >> Open
> > >> >>
> > >> >> Major
> > >> >>
> > >> >> auto-unassigned, auto-deprioritized-blocker,
> > >> auto-deprioritized-critical,
> > >> >> stale-major
> > >> >>
> > >> >> 73
> > >> >>
> > >> >> Open
> > >> >>
> > >> >> Minor
> > >> >>
> > >> >> auto-unassigned, auto-deprioritized-blocker,
> > >> auto-deprioritized-critical,
> > >> >> auto-deprioritized-major
> > >> >>
> > >> >> 263
> > >> >>
> > >> >> Open
> > >> >>
> > >> >> Minor
> > >> >>
> > >> >> auto-unassigned, auto-deprioritized-blocker,
> > >> auto-deprioritized-critical,
> > >> >> auto-deprioritized-major, stale-minor
> > >> >>
> > >> >> 270
> > >> >>
> > >> >> Closed
> > >> >>
> > >> >> Minor
> > >> >>
> > >> >> auto-unassigned, auto-deprioritized-blocker,
> > >> auto-deprioritized-critical,
> > >> >> auto-deprioritized-major, auto-closed
> > >> >>
> > >> >> I am looking forward to further comments and would otherwise
> proceed
> > >> to a
> > >> >> vote towards the end of next week.
> > >> >>
> > >> >> Cheers,
> > >> >>
> > >> >> Konstantin
> > >> >>
> > >> >>
> > >> >> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rmetzger@apache.org
> >
> > >> wrote:
> > >> >>
> > >> >>> Thanks a lot for the proposal!
> > >> >>>
> > >> >>> +1 for doing it!
> > >> >>>
> > >> >>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
> > >> >>> khachatryan.roman@gmail.com> wrote:
> > >> >>>
> > >> >>>> Hi Konstantin,
> > >> >>>>
> > >> >>>> I think we should try it out.
> > >> >>>> Even if tickets don't work well it can be a good step towards
> > >> managing
> > >> >>>> technical debt in some other way, like wiki.
> > >> >>>>
> > >> >>>> Thanks!
> > >> >>>>
> > >> >>>> Regards,
> > >> >>>> Roman
> > >> >>>>
> > >> >>>>
> > >> >>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
> > >> >> dwysakowicz@apache.org>
> > >> >>>> wrote:
> > >> >>>>
> > >> >>>>> I'd be fine with dropping the "Trivial" priority in favour of
> > >> >> "starter"
> > >> >>>>> label.
> > >> >>>>>
> > >> >>>>> Best,
> > >> >>>>>
> > >> >>>>> Dawid
> > >> >>>>>
> > >> >>>>> On 01/03/2021 11:53, Konstantin Knauf wrote:
> > >> >>>>>> Hi Dawid,
> > >> >>>>>>
> > >> >>>>>> Thanks for the feedback. Do you think we should simply get rid
> of
> > >> >> the
> > >> >>>>>> "Trivial" priority then and use the "starter" label more
> > >> >>> aggressively?
> > >> >>>>>>
> > >> >>>>>> Best,
> > >> >>>>>>
> > >> >>>>>> Konstantin
> > >> >>>>>>
> > >> >>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
> > >> >>>> dwysakowicz@apache.org
> > >> >>>>>>
> > >> >>>>>> wrote:
> > >> >>>>>>
> > >> >>>>>>> Hi Konstantin,
> > >> >>>>>>>
> > >> >>>>>>> I also like the idea.
> > >> >>>>>>>
> > >> >>>>>>> Two comments:
> > >> >>>>>>>
> > >> >>>>>>> * you describe the "Trivial" priority as one that needs to be
> > >> >>>>>>> implemented immediately. First of all it is not used to often,
> > >> >> but I
> > >> >>>>>>> think the way it works now is similar with a "starter" label.
> > >> >> Tasks
> > >> >>>> that
> > >> >>>>>>> are not bugs, are easy to implement and we think they are fine
> > to
> > >> >> be
> > >> >>>>>>> taken by newcomers. Therefore they do not fall in my mind into
> > >> >>>>>>> "immediately" category.
> > >> >>>>>>>
> > >> >>>>>>> * I would still deprioritise test instabilities. I think there
> > >> >>>> shouldn't
> > >> >>>>>>> be a problem with that. We do post links to all failures
> > therefore
> > >> >>> it
> > >> >>>>>>> will automatically priortise the tasks according to failure
> > >> >>>> frequencies.
> > >> >>>>>>>
> > >> >>>>>>> Best,
> > >> >>>>>>>
> > >> >>>>>>> Dawid
> > >> >>>>>>>
> > >> >>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote:
> > >> >>>>>>>> Hi Xintong,
> > >> >>>>>>>>
> > >> >>>>>>>> yes, such labels would make a lot of sense. I added a
> sentence
> > to
> > >> >>> the
> > >> >>>>>>>> document.
> > >> >>>>>>>>
> > >> >>>>>>>> Thanks,
> > >> >>>>>>>>
> > >> >>>>>>>> Konstantin
> > >> >>>>>>>>
> > >> >>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
> > >> >> tonysong820@gmail.com
> > >> >>>>
> > >> >>>>>>> wrote:
> > >> >>>>>>>>> Thanks for driving this discussion, Konstantin.
> > >> >>>>>>>>>
> > >> >>>>>>>>> I like the idea of having a bot reminding
> > >> >>> reporter/assignee/watchers
> > >> >>>>>>> about
> > >> >>>>>>>>> inactive tickets and if needed downgrade/close them
> > >> >> automatically.
> > >> >>>>>>>>>
> > >> >>>>>>>>> My two cents:
> > >> >>>>>>>>> We may have labels like "downgraded-by-bot" /
> "closed-by-bot",
> > >> >> so
> > >> >>>> that
> > >> >>>>>>> it's
> > >> >>>>>>>>> easier to filter and review tickets updated by the bot.
> > >> >>>>>>>>> We may want to review such tickets (e.g., monthly) in case a
> > >> >> valid
> > >> >>>>>>> ticket
> > >> >>>>>>>>> failed to draw the attention of relevant committers and the
> > >> >>> reporter
> > >> >>>>>>>>> doesn't know who to ping.
> > >> >>>>>>>>>
> > >> >>>>>>>>> Thank you~
> > >> >>>>>>>>>
> > >> >>>>>>>>> Xintong Song
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>>
> > >> >>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
> > >> >>> trohrmann@apache.org
> > >> >>>>>
> > >> >>>>>>>>> wrote:
> > >> >>>>>>>>>
> > >> >>>>>>>>>> Thanks for starting this discussion Konstantin. I like your
> > >> >>>> proposal
> > >> >>>>>>> and
> > >> >>>>>>>>>> also the idea of automating the tedious parts of it via a
> > bot.
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> Cheers,
> > >> >>>>>>>>>> Till
> > >> >>>>>>>>>>
> > >> >>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
> > >> >>>> knaufk@apache.org>
> > >> >>>>>>>>>> wrote:
> > >> >>>>>>>>>>
> > >> >>>>>>>>>>> Dear Flink Community,
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> I would like to start a discussion on improving and to
> some
> > >> >>> extent
> > >> >>>>>>>>> simply
> > >> >>>>>>>>>>> defining the way we work with Jira. Some aspects have been
> > >> >>>>> discussed a
> > >> >>>>>>>>>>> while back [1], but I would like to go a bit beyond that
> > with
> > >> >>> the
> > >> >>>>>>>>>> following
> > >> >>>>>>>>>>> goals in mind:
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> clearer communication and expectation management with
> the
> > >> >>>>> community
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> a user or contributor should be able to judge the
> > >> >> urgency
> > >> >>>> of a
> > >> >>>>>>>>>> ticket
> > >> >>>>>>>>>>> by its priority
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> if a ticket is assigned to someone the expectation
> that
> > >> >>>>> someone
> > >> >>>>>>>>> is
> > >> >>>>>>>>>>> working on it should hold
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> generally reduce noise in Jira
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> reduce overhead of committers to ask about status
> updates
> > >> >> of
> > >> >>>>>>>>>>> contributions or bug reports
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> “Are you still working on this?”
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> “Are you still interested in this?”
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> “Does this still happen on Flink 1.x?”
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> “Are you still experiencing this issue?”
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> “What is the status of the implementation”?
> > >> >>>>>>>>>>> -
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> while still encouraging users to add new tickets and to
> > >> >> leave
> > >> >>>>>>>>> feedback
> > >> >>>>>>>>>>> about existing tickets
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> Please see the full proposal here:
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> > >> >>>>>>>>>>> .
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> The idea would be to discuss this proposal in this thread.
> > If
> > >> >> we
> > >> >>>>> come
> > >> >>>>>>>>> to
> > >> >>>>>>>>>> a
> > >> >>>>>>>>>>> conclusion, I'd document the proposal in the wiki [2] and
> we
> > >> >>> would
> > >> >>>>>>> then
> > >> >>>>>>>>>>> vote on it (approval by "Lazy Majority").
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> Cheers,
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> Konstantin
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> [1]
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> > >> >>>>>>>>>>> [2]
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>>
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> > >> >>>>>>>>>>> --
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> Konstantin Knauf
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> https://twitter.com/snntrable
> > >> >>>>>>>>>>>
> > >> >>>>>>>>>>> https://github.com/knaufk
> > >> >>>>>>>>>>>
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >> >>
> > >> >> --
> > >> >>
> > >> >> Konstantin Knauf
> > >> >>
> > >> >> https://twitter.com/snntrable
> > >> >>
> > >> >> https://github.com/knaufk
> > >> >>
> > >>
> > >>
> > >
> > > --
> > >
> > > Konstantin Knauf
> > >
> > > https://twitter.com/snntrable
> > >
> > > https://github.com/knaufk
> > >
> >
> >
> > --
> >
> > Konstantin Knauf
> >
> > https://twitter.com/snntrable
> >
> > https://github.com/knaufk
> >
>
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk
Re: [DISCUSS] Apache Flink Jira Process
Posted by Arvid Heise <ar...@apache.org>.
+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 <kn...@apache.org> 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 <kn...@apache.org>
> 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 <xb...@gmail.com> 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 <to...@gmail.com> 写道：
> >> >
> >> > 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 <kn...@apache.org>
> >> wrote:
> >> >
> >> >> Hi everyone,
> >> >>
> >> >> Thank you for all the comments so far. As proposed, I have dropped
> the
> >> >> "Trivial" Priority.
> >> >>
> >> >> I also added another section "Rules in Detail" to the document adding
> >> some
> >> >> concrete numbers & labels that implement the rules. As a TLDR, here
> is
> >> an
> >> >> example of the flow for a "Blocker", that is created and assigned to
> a
> >> >> user, but never receives any updates afterwards.
> >> >>
> >> >> Day
> >> >>
> >> >> Status
> >> >>
> >> >> Priority
> >> >>
> >> >> Labels
> >> >>
> >> >> 0
> >> >>
> >> >> Open
> >> >>
> >> >> Blocker
> >> >>
> >> >> 7
> >> >>
> >> >> Open
> >> >>
> >> >> Blocker
> >> >>
> >> >> stale-assigned
> >> >>
> >> >> 14
> >> >>
> >> >> Open
> >> >>
> >> >> Blocker
> >> >>
> >> >> auto-unassigned
> >> >>
> >> >> 15
> >> >>
> >> >> Open
> >> >>
> >> >> Blocker
> >> >>
> >> >> auto-unassigned, stale-blocker
> >> >>
> >> >> 22
> >> >>
> >> >> Open
> >> >>
> >> >> Critical
> >> >>
> >> >> auto-unassigned, auto-deprioritized-blocker
> >> >>
> >> >> 29
> >> >>
> >> >> Open
> >> >>
> >> >> Critical
> >> >>
> >> >> auto-unassigned, auto-deprioritized-blocker, stale-critical
> >> >>
> >> >> 36
> >> >>
> >> >> Open
> >> >>
> >> >> Major
> >> >>
> >> >> auto-unassigned, auto-deprioritized-blocker,
> >> auto-deprioritized-critical
> >> >>
> >> >> 66
> >> >>
> >> >> Open
> >> >>
> >> >> Major
> >> >>
> >> >> auto-unassigned, auto-deprioritized-blocker,
> >> auto-deprioritized-critical,
> >> >> stale-major
> >> >>
> >> >> 73
> >> >>
> >> >> Open
> >> >>
> >> >> Minor
> >> >>
> >> >> auto-unassigned, auto-deprioritized-blocker,
> >> auto-deprioritized-critical,
> >> >> auto-deprioritized-major
> >> >>
> >> >> 263
> >> >>
> >> >> Open
> >> >>
> >> >> Minor
> >> >>
> >> >> auto-unassigned, auto-deprioritized-blocker,
> >> auto-deprioritized-critical,
> >> >> auto-deprioritized-major, stale-minor
> >> >>
> >> >> 270
> >> >>
> >> >> Closed
> >> >>
> >> >> Minor
> >> >>
> >> >> auto-unassigned, auto-deprioritized-blocker,
> >> auto-deprioritized-critical,
> >> >> auto-deprioritized-major, auto-closed
> >> >>
> >> >> I am looking forward to further comments and would otherwise proceed
> >> to a
> >> >> vote towards the end of next week.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Konstantin
> >> >>
> >> >>
> >> >> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rm...@apache.org>
> >> wrote:
> >> >>
> >> >>> Thanks a lot for the proposal!
> >> >>>
> >> >>> +1 for doing it!
> >> >>>
> >> >>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
> >> >>> khachatryan.roman@gmail.com> wrote:
> >> >>>
> >> >>>> Hi Konstantin,
> >> >>>>
> >> >>>> I think we should try it out.
> >> >>>> Even if tickets don't work well it can be a good step towards
> >> managing
> >> >>>> technical debt in some other way, like wiki.
> >> >>>>
> >> >>>> Thanks!
> >> >>>>
> >> >>>> Regards,
> >> >>>> Roman
> >> >>>>
> >> >>>>
> >> >>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
> >> >> dwysakowicz@apache.org>
> >> >>>> wrote:
> >> >>>>
> >> >>>>> I'd be fine with dropping the "Trivial" priority in favour of
> >> >> "starter"
> >> >>>>> label.
> >> >>>>>
> >> >>>>> Best,
> >> >>>>>
> >> >>>>> Dawid
> >> >>>>>
> >> >>>>> On 01/03/2021 11:53, Konstantin Knauf wrote:
> >> >>>>>> Hi Dawid,
> >> >>>>>>
> >> >>>>>> Thanks for the feedback. Do you think we should simply get rid of
> >> >> the
> >> >>>>>> "Trivial" priority then and use the "starter" label more
> >> >>> aggressively?
> >> >>>>>>
> >> >>>>>> Best,
> >> >>>>>>
> >> >>>>>> Konstantin
> >> >>>>>>
> >> >>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
> >> >>>> dwysakowicz@apache.org
> >> >>>>>>
> >> >>>>>> wrote:
> >> >>>>>>
> >> >>>>>>> Hi Konstantin,
> >> >>>>>>>
> >> >>>>>>> I also like the idea.
> >> >>>>>>>
> >> >>>>>>> Two comments:
> >> >>>>>>>
> >> >>>>>>> * you describe the "Trivial" priority as one that needs to be
> >> >>>>>>> implemented immediately. First of all it is not used to often,
> >> >> but I
> >> >>>>>>> think the way it works now is similar with a "starter" label.
> >> >> Tasks
> >> >>>> that
> >> >>>>>>> are not bugs, are easy to implement and we think they are fine
> to
> >> >> be
> >> >>>>>>> taken by newcomers. Therefore they do not fall in my mind into
> >> >>>>>>> "immediately" category.
> >> >>>>>>>
> >> >>>>>>> * I would still deprioritise test instabilities. I think there
> >> >>>> shouldn't
> >> >>>>>>> be a problem with that. We do post links to all failures
> therefore
> >> >>> it
> >> >>>>>>> will automatically priortise the tasks according to failure
> >> >>>> frequencies.
> >> >>>>>>>
> >> >>>>>>> Best,
> >> >>>>>>>
> >> >>>>>>> Dawid
> >> >>>>>>>
> >> >>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote:
> >> >>>>>>>> Hi Xintong,
> >> >>>>>>>>
> >> >>>>>>>> yes, such labels would make a lot of sense. I added a sentence
> to
> >> >>> the
> >> >>>>>>>> document.
> >> >>>>>>>>
> >> >>>>>>>> Thanks,
> >> >>>>>>>>
> >> >>>>>>>> Konstantin
> >> >>>>>>>>
> >> >>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
> >> >> tonysong820@gmail.com
> >> >>>>
> >> >>>>>>> wrote:
> >> >>>>>>>>> Thanks for driving this discussion, Konstantin.
> >> >>>>>>>>>
> >> >>>>>>>>> I like the idea of having a bot reminding
> >> >>> reporter/assignee/watchers
> >> >>>>>>> about
> >> >>>>>>>>> inactive tickets and if needed downgrade/close them
> >> >> automatically.
> >> >>>>>>>>>
> >> >>>>>>>>> My two cents:
> >> >>>>>>>>> We may have labels like "downgraded-by-bot" / "closed-by-bot",
> >> >> so
> >> >>>> that
> >> >>>>>>> it's
> >> >>>>>>>>> easier to filter and review tickets updated by the bot.
> >> >>>>>>>>> We may want to review such tickets (e.g., monthly) in case a
> >> >> valid
> >> >>>>>>> ticket
> >> >>>>>>>>> failed to draw the attention of relevant committers and the
> >> >>> reporter
> >> >>>>>>>>> doesn't know who to ping.
> >> >>>>>>>>>
> >> >>>>>>>>> Thank you~
> >> >>>>>>>>>
> >> >>>>>>>>> Xintong Song
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
> >> >>> trohrmann@apache.org
> >> >>>>>
> >> >>>>>>>>> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>>> Thanks for starting this discussion Konstantin. I like your
> >> >>>> proposal
> >> >>>>>>> and
> >> >>>>>>>>>> also the idea of automating the tedious parts of it via a
> bot.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Cheers,
> >> >>>>>>>>>> Till
> >> >>>>>>>>>>
> >> >>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
> >> >>>> knaufk@apache.org>
> >> >>>>>>>>>> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> Dear Flink Community,
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> I would like to start a discussion on improving and to some
> >> >>> extent
> >> >>>>>>>>> simply
> >> >>>>>>>>>>> defining the way we work with Jira. Some aspects have been
> >> >>>>> discussed a
> >> >>>>>>>>>>> while back [1], but I would like to go a bit beyond that
> with
> >> >>> the
> >> >>>>>>>>>> following
> >> >>>>>>>>>>> goals in mind:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> clearer communication and expectation management with the
> >> >>>>> community
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> a user or contributor should be able to judge the
> >> >> urgency
> >> >>>> of a
> >> >>>>>>>>>> ticket
> >> >>>>>>>>>>> by its priority
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> if a ticket is assigned to someone the expectation that
> >> >>>>> someone
> >> >>>>>>>>> is
> >> >>>>>>>>>>> working on it should hold
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> generally reduce noise in Jira
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> reduce overhead of committers to ask about status updates
> >> >> of
> >> >>>>>>>>>>> contributions or bug reports
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> “Are you still working on this?”
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> “Are you still interested in this?”
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> “Does this still happen on Flink 1.x?”
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> “Are you still experiencing this issue?”
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> “What is the status of the implementation”?
> >> >>>>>>>>>>> -
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> while still encouraging users to add new tickets and to
> >> >> leave
> >> >>>>>>>>> feedback
> >> >>>>>>>>>>> about existing tickets
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Please see the full proposal here:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> >> >>>>>>>>>>> .
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> The idea would be to discuss this proposal in this thread.
> If
> >> >> we
> >> >>>>> come
> >> >>>>>>>>> to
> >> >>>>>>>>>> a
> >> >>>>>>>>>>> conclusion, I'd document the proposal in the wiki [2] and we
> >> >>> would
> >> >>>>>>> then
> >> >>>>>>>>>>> vote on it (approval by "Lazy Majority").
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Cheers,
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Konstantin
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> [1]
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> >> >>>>>>>>>>> [2]
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> >> >>>>>>>>>>> --
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> Konstantin Knauf
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> https://twitter.com/snntrable
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> https://github.com/knaufk
> >> >>>>>>>>>>>
> >> >>>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Konstantin Knauf
> >> >>
> >> >> https://twitter.com/snntrable
> >> >>
> >> >> https://github.com/knaufk
> >> >>
> >>
> >>
> >
> > --
> >
> > Konstantin Knauf
> >
> > https://twitter.com/snntrable
> >
> > https://github.com/knaufk
> >
>
>
> --
>
> Konstantin Knauf
>
> https://twitter.com/snntrable
>
> https://github.com/knaufk
>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Konstantin Knauf <kn...@apache.org>.
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 <kn...@apache.org> 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 <xb...@gmail.com> 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 <to...@gmail.com> 写道：
>> >
>> > 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 <kn...@apache.org>
>> wrote:
>> >
>> >> Hi everyone,
>> >>
>> >> Thank you for all the comments so far. As proposed, I have dropped the
>> >> "Trivial" Priority.
>> >>
>> >> I also added another section "Rules in Detail" to the document adding
>> some
>> >> concrete numbers & labels that implement the rules. As a TLDR, here is
>> an
>> >> example of the flow for a "Blocker", that is created and assigned to a
>> >> user, but never receives any updates afterwards.
>> >>
>> >> Day
>> >>
>> >> Status
>> >>
>> >> Priority
>> >>
>> >> Labels
>> >>
>> >> 0
>> >>
>> >> Open
>> >>
>> >> Blocker
>> >>
>> >> 7
>> >>
>> >> Open
>> >>
>> >> Blocker
>> >>
>> >> stale-assigned
>> >>
>> >> 14
>> >>
>> >> Open
>> >>
>> >> Blocker
>> >>
>> >> auto-unassigned
>> >>
>> >> 15
>> >>
>> >> Open
>> >>
>> >> Blocker
>> >>
>> >> auto-unassigned, stale-blocker
>> >>
>> >> 22
>> >>
>> >> Open
>> >>
>> >> Critical
>> >>
>> >> auto-unassigned, auto-deprioritized-blocker
>> >>
>> >> 29
>> >>
>> >> Open
>> >>
>> >> Critical
>> >>
>> >> auto-unassigned, auto-deprioritized-blocker, stale-critical
>> >>
>> >> 36
>> >>
>> >> Open
>> >>
>> >> Major
>> >>
>> >> auto-unassigned, auto-deprioritized-blocker,
>> auto-deprioritized-critical
>> >>
>> >> 66
>> >>
>> >> Open
>> >>
>> >> Major
>> >>
>> >> auto-unassigned, auto-deprioritized-blocker,
>> auto-deprioritized-critical,
>> >> stale-major
>> >>
>> >> 73
>> >>
>> >> Open
>> >>
>> >> Minor
>> >>
>> >> auto-unassigned, auto-deprioritized-blocker,
>> auto-deprioritized-critical,
>> >> auto-deprioritized-major
>> >>
>> >> 263
>> >>
>> >> Open
>> >>
>> >> Minor
>> >>
>> >> auto-unassigned, auto-deprioritized-blocker,
>> auto-deprioritized-critical,
>> >> auto-deprioritized-major, stale-minor
>> >>
>> >> 270
>> >>
>> >> Closed
>> >>
>> >> Minor
>> >>
>> >> auto-unassigned, auto-deprioritized-blocker,
>> auto-deprioritized-critical,
>> >> auto-deprioritized-major, auto-closed
>> >>
>> >> I am looking forward to further comments and would otherwise proceed
>> to a
>> >> vote towards the end of next week.
>> >>
>> >> Cheers,
>> >>
>> >> Konstantin
>> >>
>> >>
>> >> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rm...@apache.org>
>> wrote:
>> >>
>> >>> Thanks a lot for the proposal!
>> >>>
>> >>> +1 for doing it!
>> >>>
>> >>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
>> >>> khachatryan.roman@gmail.com> wrote:
>> >>>
>> >>>> Hi Konstantin,
>> >>>>
>> >>>> I think we should try it out.
>> >>>> Even if tickets don't work well it can be a good step towards
>> managing
>> >>>> technical debt in some other way, like wiki.
>> >>>>
>> >>>> Thanks!
>> >>>>
>> >>>> Regards,
>> >>>> Roman
>> >>>>
>> >>>>
>> >>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
>> >> dwysakowicz@apache.org>
>> >>>> wrote:
>> >>>>
>> >>>>> I'd be fine with dropping the "Trivial" priority in favour of
>> >> "starter"
>> >>>>> label.
>> >>>>>
>> >>>>> Best,
>> >>>>>
>> >>>>> Dawid
>> >>>>>
>> >>>>> On 01/03/2021 11:53, Konstantin Knauf wrote:
>> >>>>>> Hi Dawid,
>> >>>>>>
>> >>>>>> Thanks for the feedback. Do you think we should simply get rid of
>> >> the
>> >>>>>> "Trivial" priority then and use the "starter" label more
>> >>> aggressively?
>> >>>>>>
>> >>>>>> Best,
>> >>>>>>
>> >>>>>> Konstantin
>> >>>>>>
>> >>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
>> >>>> dwysakowicz@apache.org
>> >>>>>>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> Hi Konstantin,
>> >>>>>>>
>> >>>>>>> I also like the idea.
>> >>>>>>>
>> >>>>>>> Two comments:
>> >>>>>>>
>> >>>>>>> * you describe the "Trivial" priority as one that needs to be
>> >>>>>>> implemented immediately. First of all it is not used to often,
>> >> but I
>> >>>>>>> think the way it works now is similar with a "starter" label.
>> >> Tasks
>> >>>> that
>> >>>>>>> are not bugs, are easy to implement and we think they are fine to
>> >> be
>> >>>>>>> taken by newcomers. Therefore they do not fall in my mind into
>> >>>>>>> "immediately" category.
>> >>>>>>>
>> >>>>>>> * I would still deprioritise test instabilities. I think there
>> >>>> shouldn't
>> >>>>>>> be a problem with that. We do post links to all failures therefore
>> >>> it
>> >>>>>>> will automatically priortise the tasks according to failure
>> >>>> frequencies.
>> >>>>>>>
>> >>>>>>> Best,
>> >>>>>>>
>> >>>>>>> Dawid
>> >>>>>>>
>> >>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote:
>> >>>>>>>> Hi Xintong,
>> >>>>>>>>
>> >>>>>>>> yes, such labels would make a lot of sense. I added a sentence to
>> >>> the
>> >>>>>>>> document.
>> >>>>>>>>
>> >>>>>>>> Thanks,
>> >>>>>>>>
>> >>>>>>>> Konstantin
>> >>>>>>>>
>> >>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
>> >> tonysong820@gmail.com
>> >>>>
>> >>>>>>> wrote:
>> >>>>>>>>> Thanks for driving this discussion, Konstantin.
>> >>>>>>>>>
>> >>>>>>>>> I like the idea of having a bot reminding
>> >>> reporter/assignee/watchers
>> >>>>>>> about
>> >>>>>>>>> inactive tickets and if needed downgrade/close them
>> >> automatically.
>> >>>>>>>>>
>> >>>>>>>>> My two cents:
>> >>>>>>>>> We may have labels like "downgraded-by-bot" / "closed-by-bot",
>> >> so
>> >>>> that
>> >>>>>>> it's
>> >>>>>>>>> easier to filter and review tickets updated by the bot.
>> >>>>>>>>> We may want to review such tickets (e.g., monthly) in case a
>> >> valid
>> >>>>>>> ticket
>> >>>>>>>>> failed to draw the attention of relevant committers and the
>> >>> reporter
>> >>>>>>>>> doesn't know who to ping.
>> >>>>>>>>>
>> >>>>>>>>> Thank you~
>> >>>>>>>>>
>> >>>>>>>>> Xintong Song
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
>> >>> trohrmann@apache.org
>> >>>>>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Thanks for starting this discussion Konstantin. I like your
>> >>>> proposal
>> >>>>>>> and
>> >>>>>>>>>> also the idea of automating the tedious parts of it via a bot.
>> >>>>>>>>>>
>> >>>>>>>>>> Cheers,
>> >>>>>>>>>> Till
>> >>>>>>>>>>
>> >>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
>> >>>> knaufk@apache.org>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Dear Flink Community,
>> >>>>>>>>>>>
>> >>>>>>>>>>> I would like to start a discussion on improving and to some
>> >>> extent
>> >>>>>>>>> simply
>> >>>>>>>>>>> defining the way we work with Jira. Some aspects have been
>> >>>>> discussed a
>> >>>>>>>>>>> while back [1], but I would like to go a bit beyond that with
>> >>> the
>> >>>>>>>>>> following
>> >>>>>>>>>>> goals in mind:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> clearer communication and expectation management with the
>> >>>>> community
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> a user or contributor should be able to judge the
>> >> urgency
>> >>>> of a
>> >>>>>>>>>> ticket
>> >>>>>>>>>>> by its priority
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> if a ticket is assigned to someone the expectation that
>> >>>>> someone
>> >>>>>>>>> is
>> >>>>>>>>>>> working on it should hold
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> generally reduce noise in Jira
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> reduce overhead of committers to ask about status updates
>> >> of
>> >>>>>>>>>>> contributions or bug reports
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> “Are you still working on this?”
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> “Are you still interested in this?”
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> “Does this still happen on Flink 1.x?”
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> “Are you still experiencing this issue?”
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> “What is the status of the implementation”?
>> >>>>>>>>>>> -
>> >>>>>>>>>>>
>> >>>>>>>>>>> while still encouraging users to add new tickets and to
>> >> leave
>> >>>>>>>>> feedback
>> >>>>>>>>>>> about existing tickets
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Please see the full proposal here:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
>> >>>>>>>>>>> .
>> >>>>>>>>>>>
>> >>>>>>>>>>> The idea would be to discuss this proposal in this thread. If
>> >> we
>> >>>>> come
>> >>>>>>>>> to
>> >>>>>>>>>> a
>> >>>>>>>>>>> conclusion, I'd document the proposal in the wiki [2] and we
>> >>> would
>> >>>>>>> then
>> >>>>>>>>>>> vote on it (approval by "Lazy Majority").
>> >>>>>>>>>>>
>> >>>>>>>>>>> Cheers,
>> >>>>>>>>>>>
>> >>>>>>>>>>> Konstantin
>> >>>>>>>>>>>
>> >>>>>>>>>>> [1]
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
>> >>>>>>>>>>> [2]
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
>> >>>>>>>>>>> --
>> >>>>>>>>>>>
>> >>>>>>>>>>> Konstantin Knauf
>> >>>>>>>>>>>
>> >>>>>>>>>>> https://twitter.com/snntrable
>> >>>>>>>>>>>
>> >>>>>>>>>>> https://github.com/knaufk
>> >>>>>>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> Konstantin Knauf
>> >>
>> >> https://twitter.com/snntrable
>> >>
>> >> https://github.com/knaufk
>> >>
>>
>>
>
> --
>
> Konstantin Knauf
>
> https://twitter.com/snntrable
>
> https://github.com/knaufk
>
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk
Re: [DISCUSS] Apache Flink Jira Process
Posted by Konstantin Knauf <kn...@apache.org>.
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 <xb...@gmail.com> 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 <to...@gmail.com> 写道：
> >
> > 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 <kn...@apache.org>
> wrote:
> >
> >> Hi everyone,
> >>
> >> Thank you for all the comments so far. As proposed, I have dropped the
> >> "Trivial" Priority.
> >>
> >> I also added another section "Rules in Detail" to the document adding
> some
> >> concrete numbers & labels that implement the rules. As a TLDR, here is
> an
> >> example of the flow for a "Blocker", that is created and assigned to a
> >> user, but never receives any updates afterwards.
> >>
> >> Day
> >>
> >> Status
> >>
> >> Priority
> >>
> >> Labels
> >>
> >> 0
> >>
> >> Open
> >>
> >> Blocker
> >>
> >> 7
> >>
> >> Open
> >>
> >> Blocker
> >>
> >> stale-assigned
> >>
> >> 14
> >>
> >> Open
> >>
> >> Blocker
> >>
> >> auto-unassigned
> >>
> >> 15
> >>
> >> Open
> >>
> >> Blocker
> >>
> >> auto-unassigned, stale-blocker
> >>
> >> 22
> >>
> >> Open
> >>
> >> Critical
> >>
> >> auto-unassigned, auto-deprioritized-blocker
> >>
> >> 29
> >>
> >> Open
> >>
> >> Critical
> >>
> >> auto-unassigned, auto-deprioritized-blocker, stale-critical
> >>
> >> 36
> >>
> >> Open
> >>
> >> Major
> >>
> >> auto-unassigned, auto-deprioritized-blocker,
> auto-deprioritized-critical
> >>
> >> 66
> >>
> >> Open
> >>
> >> Major
> >>
> >> auto-unassigned, auto-deprioritized-blocker,
> auto-deprioritized-critical,
> >> stale-major
> >>
> >> 73
> >>
> >> Open
> >>
> >> Minor
> >>
> >> auto-unassigned, auto-deprioritized-blocker,
> auto-deprioritized-critical,
> >> auto-deprioritized-major
> >>
> >> 263
> >>
> >> Open
> >>
> >> Minor
> >>
> >> auto-unassigned, auto-deprioritized-blocker,
> auto-deprioritized-critical,
> >> auto-deprioritized-major, stale-minor
> >>
> >> 270
> >>
> >> Closed
> >>
> >> Minor
> >>
> >> auto-unassigned, auto-deprioritized-blocker,
> auto-deprioritized-critical,
> >> auto-deprioritized-major, auto-closed
> >>
> >> I am looking forward to further comments and would otherwise proceed to
> a
> >> vote towards the end of next week.
> >>
> >> Cheers,
> >>
> >> Konstantin
> >>
> >>
> >> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rm...@apache.org>
> wrote:
> >>
> >>> Thanks a lot for the proposal!
> >>>
> >>> +1 for doing it!
> >>>
> >>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
> >>> khachatryan.roman@gmail.com> wrote:
> >>>
> >>>> Hi Konstantin,
> >>>>
> >>>> I think we should try it out.
> >>>> Even if tickets don't work well it can be a good step towards managing
> >>>> technical debt in some other way, like wiki.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Regards,
> >>>> Roman
> >>>>
> >>>>
> >>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
> >> dwysakowicz@apache.org>
> >>>> wrote:
> >>>>
> >>>>> I'd be fine with dropping the "Trivial" priority in favour of
> >> "starter"
> >>>>> label.
> >>>>>
> >>>>> Best,
> >>>>>
> >>>>> Dawid
> >>>>>
> >>>>> On 01/03/2021 11:53, Konstantin Knauf wrote:
> >>>>>> Hi Dawid,
> >>>>>>
> >>>>>> Thanks for the feedback. Do you think we should simply get rid of
> >> the
> >>>>>> "Trivial" priority then and use the "starter" label more
> >>> aggressively?
> >>>>>>
> >>>>>> Best,
> >>>>>>
> >>>>>> Konstantin
> >>>>>>
> >>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
> >>>> dwysakowicz@apache.org
> >>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Konstantin,
> >>>>>>>
> >>>>>>> I also like the idea.
> >>>>>>>
> >>>>>>> Two comments:
> >>>>>>>
> >>>>>>> * you describe the "Trivial" priority as one that needs to be
> >>>>>>> implemented immediately. First of all it is not used to often,
> >> but I
> >>>>>>> think the way it works now is similar with a "starter" label.
> >> Tasks
> >>>> that
> >>>>>>> are not bugs, are easy to implement and we think they are fine to
> >> be
> >>>>>>> taken by newcomers. Therefore they do not fall in my mind into
> >>>>>>> "immediately" category.
> >>>>>>>
> >>>>>>> * I would still deprioritise test instabilities. I think there
> >>>> shouldn't
> >>>>>>> be a problem with that. We do post links to all failures therefore
> >>> it
> >>>>>>> will automatically priortise the tasks according to failure
> >>>> frequencies.
> >>>>>>>
> >>>>>>> Best,
> >>>>>>>
> >>>>>>> Dawid
> >>>>>>>
> >>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote:
> >>>>>>>> Hi Xintong,
> >>>>>>>>
> >>>>>>>> yes, such labels would make a lot of sense. I added a sentence to
> >>> the
> >>>>>>>> document.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Konstantin
> >>>>>>>>
> >>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
> >> tonysong820@gmail.com
> >>>>
> >>>>>>> wrote:
> >>>>>>>>> Thanks for driving this discussion, Konstantin.
> >>>>>>>>>
> >>>>>>>>> I like the idea of having a bot reminding
> >>> reporter/assignee/watchers
> >>>>>>> about
> >>>>>>>>> inactive tickets and if needed downgrade/close them
> >> automatically.
> >>>>>>>>>
> >>>>>>>>> My two cents:
> >>>>>>>>> We may have labels like "downgraded-by-bot" / "closed-by-bot",
> >> so
> >>>> that
> >>>>>>> it's
> >>>>>>>>> easier to filter and review tickets updated by the bot.
> >>>>>>>>> We may want to review such tickets (e.g., monthly) in case a
> >> valid
> >>>>>>> ticket
> >>>>>>>>> failed to draw the attention of relevant committers and the
> >>> reporter
> >>>>>>>>> doesn't know who to ping.
> >>>>>>>>>
> >>>>>>>>> Thank you~
> >>>>>>>>>
> >>>>>>>>> Xintong Song
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
> >>> trohrmann@apache.org
> >>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Thanks for starting this discussion Konstantin. I like your
> >>>> proposal
> >>>>>>> and
> >>>>>>>>>> also the idea of automating the tedious parts of it via a bot.
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>> Till
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
> >>>> knaufk@apache.org>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Dear Flink Community,
> >>>>>>>>>>>
> >>>>>>>>>>> I would like to start a discussion on improving and to some
> >>> extent
> >>>>>>>>> simply
> >>>>>>>>>>> defining the way we work with Jira. Some aspects have been
> >>>>> discussed a
> >>>>>>>>>>> while back [1], but I would like to go a bit beyond that with
> >>> the
> >>>>>>>>>> following
> >>>>>>>>>>> goals in mind:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> clearer communication and expectation management with the
> >>>>> community
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> a user or contributor should be able to judge the
> >> urgency
> >>>> of a
> >>>>>>>>>> ticket
> >>>>>>>>>>> by its priority
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> if a ticket is assigned to someone the expectation that
> >>>>> someone
> >>>>>>>>> is
> >>>>>>>>>>> working on it should hold
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> generally reduce noise in Jira
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> reduce overhead of committers to ask about status updates
> >> of
> >>>>>>>>>>> contributions or bug reports
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> “Are you still working on this?”
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> “Are you still interested in this?”
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> “Does this still happen on Flink 1.x?”
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> “Are you still experiencing this issue?”
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> “What is the status of the implementation”?
> >>>>>>>>>>> -
> >>>>>>>>>>>
> >>>>>>>>>>> while still encouraging users to add new tickets and to
> >> leave
> >>>>>>>>> feedback
> >>>>>>>>>>> about existing tickets
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Please see the full proposal here:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> >>>>>>>>>>> .
> >>>>>>>>>>>
> >>>>>>>>>>> The idea would be to discuss this proposal in this thread. If
> >> we
> >>>>> come
> >>>>>>>>> to
> >>>>>>>>>> a
> >>>>>>>>>>> conclusion, I'd document the proposal in the wiki [2] and we
> >>> would
> >>>>>>> then
> >>>>>>>>>>> vote on it (approval by "Lazy Majority").
> >>>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>>
> >>>>>>>>>>> Konstantin
> >>>>>>>>>>>
> >>>>>>>>>>> [1]
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> >>>>>>>>>>> [2]
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> >>>>>>>>>>> --
> >>>>>>>>>>>
> >>>>>>>>>>> Konstantin Knauf
> >>>>>>>>>>>
> >>>>>>>>>>> https://twitter.com/snntrable
> >>>>>>>>>>>
> >>>>>>>>>>> https://github.com/knaufk
> >>>>>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >> --
> >>
> >> Konstantin Knauf
> >>
> >> https://twitter.com/snntrable
> >>
> >> https://github.com/knaufk
> >>
>
>
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk
Re: [DISCUSS] Apache Flink Jira Process
Posted by Leonard Xu <xb...@gmail.com>.
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 <to...@gmail.com> 写道：
>
> 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 <kn...@apache.org> wrote:
>
>> Hi everyone,
>>
>> Thank you for all the comments so far. As proposed, I have dropped the
>> "Trivial" Priority.
>>
>> I also added another section "Rules in Detail" to the document adding some
>> concrete numbers & labels that implement the rules. As a TLDR, here is an
>> example of the flow for a "Blocker", that is created and assigned to a
>> user, but never receives any updates afterwards.
>>
>> Day
>>
>> Status
>>
>> Priority
>>
>> Labels
>>
>> 0
>>
>> Open
>>
>> Blocker
>>
>> 7
>>
>> Open
>>
>> Blocker
>>
>> stale-assigned
>>
>> 14
>>
>> Open
>>
>> Blocker
>>
>> auto-unassigned
>>
>> 15
>>
>> Open
>>
>> Blocker
>>
>> auto-unassigned, stale-blocker
>>
>> 22
>>
>> Open
>>
>> Critical
>>
>> auto-unassigned, auto-deprioritized-blocker
>>
>> 29
>>
>> Open
>>
>> Critical
>>
>> auto-unassigned, auto-deprioritized-blocker, stale-critical
>>
>> 36
>>
>> Open
>>
>> Major
>>
>> auto-unassigned, auto-deprioritized-blocker, auto-deprioritized-critical
>>
>> 66
>>
>> Open
>>
>> Major
>>
>> auto-unassigned, auto-deprioritized-blocker, auto-deprioritized-critical,
>> stale-major
>>
>> 73
>>
>> Open
>>
>> Minor
>>
>> auto-unassigned, auto-deprioritized-blocker, auto-deprioritized-critical,
>> auto-deprioritized-major
>>
>> 263
>>
>> Open
>>
>> Minor
>>
>> auto-unassigned, auto-deprioritized-blocker, auto-deprioritized-critical,
>> auto-deprioritized-major, stale-minor
>>
>> 270
>>
>> Closed
>>
>> Minor
>>
>> auto-unassigned, auto-deprioritized-blocker, auto-deprioritized-critical,
>> auto-deprioritized-major, auto-closed
>>
>> I am looking forward to further comments and would otherwise proceed to a
>> vote towards the end of next week.
>>
>> Cheers,
>>
>> Konstantin
>>
>>
>> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rm...@apache.org> wrote:
>>
>>> Thanks a lot for the proposal!
>>>
>>> +1 for doing it!
>>>
>>> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
>>> khachatryan.roman@gmail.com> wrote:
>>>
>>>> Hi Konstantin,
>>>>
>>>> I think we should try it out.
>>>> Even if tickets don't work well it can be a good step towards managing
>>>> technical debt in some other way, like wiki.
>>>>
>>>> Thanks!
>>>>
>>>> Regards,
>>>> Roman
>>>>
>>>>
>>>> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
>> dwysakowicz@apache.org>
>>>> wrote:
>>>>
>>>>> I'd be fine with dropping the "Trivial" priority in favour of
>> "starter"
>>>>> label.
>>>>>
>>>>> Best,
>>>>>
>>>>> Dawid
>>>>>
>>>>> On 01/03/2021 11:53, Konstantin Knauf wrote:
>>>>>> Hi Dawid,
>>>>>>
>>>>>> Thanks for the feedback. Do you think we should simply get rid of
>> the
>>>>>> "Trivial" priority then and use the "starter" label more
>>> aggressively?
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Konstantin
>>>>>>
>>>>>> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
>>>> dwysakowicz@apache.org
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Konstantin,
>>>>>>>
>>>>>>> I also like the idea.
>>>>>>>
>>>>>>> Two comments:
>>>>>>>
>>>>>>> * you describe the "Trivial" priority as one that needs to be
>>>>>>> implemented immediately. First of all it is not used to often,
>> but I
>>>>>>> think the way it works now is similar with a "starter" label.
>> Tasks
>>>> that
>>>>>>> are not bugs, are easy to implement and we think they are fine to
>> be
>>>>>>> taken by newcomers. Therefore they do not fall in my mind into
>>>>>>> "immediately" category.
>>>>>>>
>>>>>>> * I would still deprioritise test instabilities. I think there
>>>> shouldn't
>>>>>>> be a problem with that. We do post links to all failures therefore
>>> it
>>>>>>> will automatically priortise the tasks according to failure
>>>> frequencies.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Dawid
>>>>>>>
>>>>>>> On 01/03/2021 09:38, Konstantin Knauf wrote:
>>>>>>>> Hi Xintong,
>>>>>>>>
>>>>>>>> yes, such labels would make a lot of sense. I added a sentence to
>>> the
>>>>>>>> document.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Konstantin
>>>>>>>>
>>>>>>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
>> tonysong820@gmail.com
>>>>
>>>>>>> wrote:
>>>>>>>>> Thanks for driving this discussion, Konstantin.
>>>>>>>>>
>>>>>>>>> I like the idea of having a bot reminding
>>> reporter/assignee/watchers
>>>>>>> about
>>>>>>>>> inactive tickets and if needed downgrade/close them
>> automatically.
>>>>>>>>>
>>>>>>>>> My two cents:
>>>>>>>>> We may have labels like "downgraded-by-bot" / "closed-by-bot",
>> so
>>>> that
>>>>>>> it's
>>>>>>>>> easier to filter and review tickets updated by the bot.
>>>>>>>>> We may want to review such tickets (e.g., monthly) in case a
>> valid
>>>>>>> ticket
>>>>>>>>> failed to draw the attention of relevant committers and the
>>> reporter
>>>>>>>>> doesn't know who to ping.
>>>>>>>>>
>>>>>>>>> Thank you~
>>>>>>>>>
>>>>>>>>> Xintong Song
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
>>> trohrmann@apache.org
>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks for starting this discussion Konstantin. I like your
>>>> proposal
>>>>>>> and
>>>>>>>>>> also the idea of automating the tedious parts of it via a bot.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Till
>>>>>>>>>>
>>>>>>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
>>>> knaufk@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Dear Flink Community,
>>>>>>>>>>>
>>>>>>>>>>> I would like to start a discussion on improving and to some
>>> extent
>>>>>>>>> simply
>>>>>>>>>>> defining the way we work with Jira. Some aspects have been
>>>>> discussed a
>>>>>>>>>>> while back [1], but I would like to go a bit beyond that with
>>> the
>>>>>>>>>> following
>>>>>>>>>>> goals in mind:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> clearer communication and expectation management with the
>>>>> community
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> a user or contributor should be able to judge the
>> urgency
>>>> of a
>>>>>>>>>> ticket
>>>>>>>>>>> by its priority
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> if a ticket is assigned to someone the expectation that
>>>>> someone
>>>>>>>>> is
>>>>>>>>>>> working on it should hold
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> generally reduce noise in Jira
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> reduce overhead of committers to ask about status updates
>> of
>>>>>>>>>>> contributions or bug reports
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> “Are you still working on this?”
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> “Are you still interested in this?”
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> “Does this still happen on Flink 1.x?”
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> “Are you still experiencing this issue?”
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> “What is the status of the implementation”?
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> while still encouraging users to add new tickets and to
>> leave
>>>>>>>>> feedback
>>>>>>>>>>> about existing tickets
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Please see the full proposal here:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>> The idea would be to discuss this proposal in this thread. If
>> we
>>>>> come
>>>>>>>>> to
>>>>>>>>>> a
>>>>>>>>>>> conclusion, I'd document the proposal in the wiki [2] and we
>>> would
>>>>>>> then
>>>>>>>>>>> vote on it (approval by "Lazy Majority").
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Konstantin
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
>>>>>>>>>>> [2]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> Konstantin Knauf
>>>>>>>>>>>
>>>>>>>>>>> https://twitter.com/snntrable
>>>>>>>>>>>
>>>>>>>>>>> https://github.com/knaufk
>>>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Konstantin Knauf
>>
>> https://twitter.com/snntrable
>>
>> https://github.com/knaufk
>>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Xintong Song <to...@gmail.com>.
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 <kn...@apache.org> wrote:
> Hi everyone,
>
> Thank you for all the comments so far. As proposed, I have dropped the
> "Trivial" Priority.
>
> I also added another section "Rules in Detail" to the document adding some
> concrete numbers & labels that implement the rules. As a TLDR, here is an
> example of the flow for a "Blocker", that is created and assigned to a
> user, but never receives any updates afterwards.
>
> Day
>
> Status
>
> Priority
>
> Labels
>
> 0
>
> Open
>
> Blocker
>
> 7
>
> Open
>
> Blocker
>
> stale-assigned
>
> 14
>
> Open
>
> Blocker
>
> auto-unassigned
>
> 15
>
> Open
>
> Blocker
>
> auto-unassigned, stale-blocker
>
> 22
>
> Open
>
> Critical
>
> auto-unassigned, auto-deprioritized-blocker
>
> 29
>
> Open
>
> Critical
>
> auto-unassigned, auto-deprioritized-blocker, stale-critical
>
> 36
>
> Open
>
> Major
>
> auto-unassigned, auto-deprioritized-blocker, auto-deprioritized-critical
>
> 66
>
> Open
>
> Major
>
> auto-unassigned, auto-deprioritized-blocker, auto-deprioritized-critical,
> stale-major
>
> 73
>
> Open
>
> Minor
>
> auto-unassigned, auto-deprioritized-blocker, auto-deprioritized-critical,
> auto-deprioritized-major
>
> 263
>
> Open
>
> Minor
>
> auto-unassigned, auto-deprioritized-blocker, auto-deprioritized-critical,
> auto-deprioritized-major, stale-minor
>
> 270
>
> Closed
>
> Minor
>
> auto-unassigned, auto-deprioritized-blocker, auto-deprioritized-critical,
> auto-deprioritized-major, auto-closed
>
> I am looking forward to further comments and would otherwise proceed to a
> vote towards the end of next week.
>
> Cheers,
>
> Konstantin
>
>
> On Tue, Mar 2, 2021 at 3:45 PM Robert Metzger <rm...@apache.org> wrote:
>
> > Thanks a lot for the proposal!
> >
> > +1 for doing it!
> >
> > On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
> > khachatryan.roman@gmail.com> wrote:
> >
> > > Hi Konstantin,
> > >
> > > I think we should try it out.
> > > Even if tickets don't work well it can be a good step towards managing
> > > technical debt in some other way, like wiki.
> > >
> > > Thanks!
> > >
> > > Regards,
> > > Roman
> > >
> > >
> > > On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <
> dwysakowicz@apache.org>
> > > wrote:
> > >
> > > > I'd be fine with dropping the "Trivial" priority in favour of
> "starter"
> > > > label.
> > > >
> > > > Best,
> > > >
> > > > Dawid
> > > >
> > > > On 01/03/2021 11:53, Konstantin Knauf wrote:
> > > > > Hi Dawid,
> > > > >
> > > > > Thanks for the feedback. Do you think we should simply get rid of
> the
> > > > > "Trivial" priority then and use the "starter" label more
> > aggressively?
> > > > >
> > > > > Best,
> > > > >
> > > > > Konstantin
> > > > >
> > > > > On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
> > > dwysakowicz@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Hi Konstantin,
> > > > >>
> > > > >> I also like the idea.
> > > > >>
> > > > >> Two comments:
> > > > >>
> > > > >> * you describe the "Trivial" priority as one that needs to be
> > > > >> implemented immediately. First of all it is not used to often,
> but I
> > > > >> think the way it works now is similar with a "starter" label.
> Tasks
> > > that
> > > > >> are not bugs, are easy to implement and we think they are fine to
> be
> > > > >> taken by newcomers. Therefore they do not fall in my mind into
> > > > >> "immediately" category.
> > > > >>
> > > > >> * I would still deprioritise test instabilities. I think there
> > > shouldn't
> > > > >> be a problem with that. We do post links to all failures therefore
> > it
> > > > >> will automatically priortise the tasks according to failure
> > > frequencies.
> > > > >>
> > > > >> Best,
> > > > >>
> > > > >> Dawid
> > > > >>
> > > > >> On 01/03/2021 09:38, Konstantin Knauf wrote:
> > > > >>> Hi Xintong,
> > > > >>>
> > > > >>> yes, such labels would make a lot of sense. I added a sentence to
> > the
> > > > >>> document.
> > > > >>>
> > > > >>> Thanks,
> > > > >>>
> > > > >>> Konstantin
> > > > >>>
> > > > >>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <
> tonysong820@gmail.com
> > >
> > > > >> wrote:
> > > > >>>> Thanks for driving this discussion, Konstantin.
> > > > >>>>
> > > > >>>> I like the idea of having a bot reminding
> > reporter/assignee/watchers
> > > > >> about
> > > > >>>> inactive tickets and if needed downgrade/close them
> automatically.
> > > > >>>>
> > > > >>>> My two cents:
> > > > >>>> We may have labels like "downgraded-by-bot" / "closed-by-bot",
> so
> > > that
> > > > >> it's
> > > > >>>> easier to filter and review tickets updated by the bot.
> > > > >>>> We may want to review such tickets (e.g., monthly) in case a
> valid
> > > > >> ticket
> > > > >>>> failed to draw the attention of relevant committers and the
> > reporter
> > > > >>>> doesn't know who to ping.
> > > > >>>>
> > > > >>>> Thank you~
> > > > >>>>
> > > > >>>> Xintong Song
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
> > trohrmann@apache.org
> > > >
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>>> Thanks for starting this discussion Konstantin. I like your
> > > proposal
> > > > >> and
> > > > >>>>> also the idea of automating the tedious parts of it via a bot.
> > > > >>>>>
> > > > >>>>> Cheers,
> > > > >>>>> Till
> > > > >>>>>
> > > > >>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
> > > knaufk@apache.org>
> > > > >>>>> wrote:
> > > > >>>>>
> > > > >>>>>> Dear Flink Community,
> > > > >>>>>>
> > > > >>>>>> I would like to start a discussion on improving and to some
> > extent
> > > > >>>> simply
> > > > >>>>>> defining the way we work with Jira. Some aspects have been
> > > > discussed a
> > > > >>>>>> while back [1], but I would like to go a bit beyond that with
> > the
> > > > >>>>> following
> > > > >>>>>> goals in mind:
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> clearer communication and expectation management with the
> > > > community
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> a user or contributor should be able to judge the
> urgency
> > > of a
> > > > >>>>> ticket
> > > > >>>>>> by its priority
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> if a ticket is assigned to someone the expectation that
> > > > someone
> > > > >>>> is
> > > > >>>>>> working on it should hold
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> generally reduce noise in Jira
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> reduce overhead of committers to ask about status updates
> of
> > > > >>>>>> contributions or bug reports
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> “Are you still working on this?”
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> “Are you still interested in this?”
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> “Does this still happen on Flink 1.x?”
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> “Are you still experiencing this issue?”
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> “What is the status of the implementation”?
> > > > >>>>>> -
> > > > >>>>>>
> > > > >>>>>> while still encouraging users to add new tickets and to
> leave
> > > > >>>> feedback
> > > > >>>>>> about existing tickets
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> Please see the full proposal here:
> > > > >>>>>>
> > > > >>>>>>
> > > > >>
> > > >
> > >
> >
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> > > > >>>>>> .
> > > > >>>>>>
> > > > >>>>>> The idea would be to discuss this proposal in this thread. If
> we
> > > > come
> > > > >>>> to
> > > > >>>>> a
> > > > >>>>>> conclusion, I'd document the proposal in the wiki [2] and we
> > would
> > > > >> then
> > > > >>>>>> vote on it (approval by "Lazy Majority").
> > > > >>>>>>
> > > > >>>>>> Cheers,
> > > > >>>>>>
> > > > >>>>>> Konstantin
> > > > >>>>>>
> > > > >>>>>> [1]
> > > > >>>>>>
> > > > >>>>>>
> > > > >>
> > > >
> > >
> >
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> > > > >>>>>> [2]
> > > > >>>>>>
> > > > >>>>>>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> > > > >>>>>> --
> > > > >>>>>>
> > > > >>>>>> Konstantin Knauf
> > > > >>>>>>
> > > > >>>>>> https://twitter.com/snntrable
> > > > >>>>>>
> > > > >>>>>> https://github.com/knaufk
> > > > >>>>>>
> > > > >>
> > > >
> > > >
> > >
> >
>
>
> --
>
> Konstantin Knauf
>
> https://twitter.com/snntrable
>
> https://github.com/knaufk
>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Konstantin Knauf <kn...@apache.org>.
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 <rm...@apache.org> wrote:
> Thanks a lot for the proposal!
>
> +1 for doing it!
>
> On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
> khachatryan.roman@gmail.com> wrote:
>
> > Hi Konstantin,
> >
> > I think we should try it out.
> > Even if tickets don't work well it can be a good step towards managing
> > technical debt in some other way, like wiki.
> >
> > Thanks!
> >
> > Regards,
> > Roman
> >
> >
> > On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <dw...@apache.org>
> > wrote:
> >
> > > I'd be fine with dropping the "Trivial" priority in favour of "starter"
> > > label.
> > >
> > > Best,
> > >
> > > Dawid
> > >
> > > On 01/03/2021 11:53, Konstantin Knauf wrote:
> > > > Hi Dawid,
> > > >
> > > > Thanks for the feedback. Do you think we should simply get rid of the
> > > > "Trivial" priority then and use the "starter" label more
> aggressively?
> > > >
> > > > Best,
> > > >
> > > > Konstantin
> > > >
> > > > On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
> > dwysakowicz@apache.org
> > > >
> > > > wrote:
> > > >
> > > >> Hi Konstantin,
> > > >>
> > > >> I also like the idea.
> > > >>
> > > >> Two comments:
> > > >>
> > > >> * you describe the "Trivial" priority as one that needs to be
> > > >> implemented immediately. First of all it is not used to often, but I
> > > >> think the way it works now is similar with a "starter" label. Tasks
> > that
> > > >> are not bugs, are easy to implement and we think they are fine to be
> > > >> taken by newcomers. Therefore they do not fall in my mind into
> > > >> "immediately" category.
> > > >>
> > > >> * I would still deprioritise test instabilities. I think there
> > shouldn't
> > > >> be a problem with that. We do post links to all failures therefore
> it
> > > >> will automatically priortise the tasks according to failure
> > frequencies.
> > > >>
> > > >> Best,
> > > >>
> > > >> Dawid
> > > >>
> > > >> On 01/03/2021 09:38, Konstantin Knauf wrote:
> > > >>> Hi Xintong,
> > > >>>
> > > >>> yes, such labels would make a lot of sense. I added a sentence to
> the
> > > >>> document.
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >>> Konstantin
> > > >>>
> > > >>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <tonysong820@gmail.com
> >
> > > >> wrote:
> > > >>>> Thanks for driving this discussion, Konstantin.
> > > >>>>
> > > >>>> I like the idea of having a bot reminding
> reporter/assignee/watchers
> > > >> about
> > > >>>> inactive tickets and if needed downgrade/close them automatically.
> > > >>>>
> > > >>>> My two cents:
> > > >>>> We may have labels like "downgraded-by-bot" / "closed-by-bot", so
> > that
> > > >> it's
> > > >>>> easier to filter and review tickets updated by the bot.
> > > >>>> We may want to review such tickets (e.g., monthly) in case a valid
> > > >> ticket
> > > >>>> failed to draw the attention of relevant committers and the
> reporter
> > > >>>> doesn't know who to ping.
> > > >>>>
> > > >>>> Thank you~
> > > >>>>
> > > >>>> Xintong Song
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <
> trohrmann@apache.org
> > >
> > > >>>> wrote:
> > > >>>>
> > > >>>>> Thanks for starting this discussion Konstantin. I like your
> > proposal
> > > >> and
> > > >>>>> also the idea of automating the tedious parts of it via a bot.
> > > >>>>>
> > > >>>>> Cheers,
> > > >>>>> Till
> > > >>>>>
> > > >>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
> > knaufk@apache.org>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Dear Flink Community,
> > > >>>>>>
> > > >>>>>> I would like to start a discussion on improving and to some
> extent
> > > >>>> simply
> > > >>>>>> defining the way we work with Jira. Some aspects have been
> > > discussed a
> > > >>>>>> while back [1], but I would like to go a bit beyond that with
> the
> > > >>>>> following
> > > >>>>>> goals in mind:
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> clearer communication and expectation management with the
> > > community
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> a user or contributor should be able to judge the urgency
> > of a
> > > >>>>> ticket
> > > >>>>>> by its priority
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> if a ticket is assigned to someone the expectation that
> > > someone
> > > >>>> is
> > > >>>>>> working on it should hold
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> generally reduce noise in Jira
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> reduce overhead of committers to ask about status updates of
> > > >>>>>> contributions or bug reports
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> “Are you still working on this?”
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> “Are you still interested in this?”
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> “Does this still happen on Flink 1.x?”
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> “Are you still experiencing this issue?”
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> “What is the status of the implementation”?
> > > >>>>>> -
> > > >>>>>>
> > > >>>>>> while still encouraging users to add new tickets and to leave
> > > >>>> feedback
> > > >>>>>> about existing tickets
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Please see the full proposal here:
> > > >>>>>>
> > > >>>>>>
> > > >>
> > >
> >
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> > > >>>>>> .
> > > >>>>>>
> > > >>>>>> The idea would be to discuss this proposal in this thread. If we
> > > come
> > > >>>> to
> > > >>>>> a
> > > >>>>>> conclusion, I'd document the proposal in the wiki [2] and we
> would
> > > >> then
> > > >>>>>> vote on it (approval by "Lazy Majority").
> > > >>>>>>
> > > >>>>>> Cheers,
> > > >>>>>>
> > > >>>>>> Konstantin
> > > >>>>>>
> > > >>>>>> [1]
> > > >>>>>>
> > > >>>>>>
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> > > >>>>>> [2]
> > > >>>>>>
> > > >>>>>>
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> > > >>>>>> --
> > > >>>>>>
> > > >>>>>> Konstantin Knauf
> > > >>>>>>
> > > >>>>>> https://twitter.com/snntrable
> > > >>>>>>
> > > >>>>>> https://github.com/knaufk
> > > >>>>>>
> > > >>
> > >
> > >
> >
>
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk
Re: [DISCUSS] Apache Flink Jira Process
Posted by Robert Metzger <rm...@apache.org>.
Thanks a lot for the proposal!
+1 for doing it!
On Tue, Mar 2, 2021 at 12:27 PM Khachatryan Roman <
khachatryan.roman@gmail.com> wrote:
> Hi Konstantin,
>
> I think we should try it out.
> Even if tickets don't work well it can be a good step towards managing
> technical debt in some other way, like wiki.
>
> Thanks!
>
> Regards,
> Roman
>
>
> On Tue, Mar 2, 2021 at 9:32 AM Dawid Wysakowicz <dw...@apache.org>
> wrote:
>
> > I'd be fine with dropping the "Trivial" priority in favour of "starter"
> > label.
> >
> > Best,
> >
> > Dawid
> >
> > On 01/03/2021 11:53, Konstantin Knauf wrote:
> > > Hi Dawid,
> > >
> > > Thanks for the feedback. Do you think we should simply get rid of the
> > > "Trivial" priority then and use the "starter" label more aggressively?
> > >
> > > Best,
> > >
> > > Konstantin
> > >
> > > On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <
> dwysakowicz@apache.org
> > >
> > > wrote:
> > >
> > >> Hi Konstantin,
> > >>
> > >> I also like the idea.
> > >>
> > >> Two comments:
> > >>
> > >> * you describe the "Trivial" priority as one that needs to be
> > >> implemented immediately. First of all it is not used to often, but I
> > >> think the way it works now is similar with a "starter" label. Tasks
> that
> > >> are not bugs, are easy to implement and we think they are fine to be
> > >> taken by newcomers. Therefore they do not fall in my mind into
> > >> "immediately" category.
> > >>
> > >> * I would still deprioritise test instabilities. I think there
> shouldn't
> > >> be a problem with that. We do post links to all failures therefore it
> > >> will automatically priortise the tasks according to failure
> frequencies.
> > >>
> > >> Best,
> > >>
> > >> Dawid
> > >>
> > >> On 01/03/2021 09:38, Konstantin Knauf wrote:
> > >>> Hi Xintong,
> > >>>
> > >>> yes, such labels would make a lot of sense. I added a sentence to the
> > >>> document.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Konstantin
> > >>>
> > >>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <to...@gmail.com>
> > >> wrote:
> > >>>> Thanks for driving this discussion, Konstantin.
> > >>>>
> > >>>> I like the idea of having a bot reminding reporter/assignee/watchers
> > >> about
> > >>>> inactive tickets and if needed downgrade/close them automatically.
> > >>>>
> > >>>> My two cents:
> > >>>> We may have labels like "downgraded-by-bot" / "closed-by-bot", so
> that
> > >> it's
> > >>>> easier to filter and review tickets updated by the bot.
> > >>>> We may want to review such tickets (e.g., monthly) in case a valid
> > >> ticket
> > >>>> failed to draw the attention of relevant committers and the reporter
> > >>>> doesn't know who to ping.
> > >>>>
> > >>>> Thank you~
> > >>>>
> > >>>> Xintong Song
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <trohrmann@apache.org
> >
> > >>>> wrote:
> > >>>>
> > >>>>> Thanks for starting this discussion Konstantin. I like your
> proposal
> > >> and
> > >>>>> also the idea of automating the tedious parts of it via a bot.
> > >>>>>
> > >>>>> Cheers,
> > >>>>> Till
> > >>>>>
> > >>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
> knaufk@apache.org>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Dear Flink Community,
> > >>>>>>
> > >>>>>> I would like to start a discussion on improving and to some extent
> > >>>> simply
> > >>>>>> defining the way we work with Jira. Some aspects have been
> > discussed a
> > >>>>>> while back [1], but I would like to go a bit beyond that with the
> > >>>>> following
> > >>>>>> goals in mind:
> > >>>>>>
> > >>>>>>
> > >>>>>> -
> > >>>>>>
> > >>>>>> clearer communication and expectation management with the
> > community
> > >>>>>> -
> > >>>>>>
> > >>>>>> a user or contributor should be able to judge the urgency
> of a
> > >>>>> ticket
> > >>>>>> by its priority
> > >>>>>> -
> > >>>>>>
> > >>>>>> if a ticket is assigned to someone the expectation that
> > someone
> > >>>> is
> > >>>>>> working on it should hold
> > >>>>>> -
> > >>>>>>
> > >>>>>> generally reduce noise in Jira
> > >>>>>> -
> > >>>>>>
> > >>>>>> reduce overhead of committers to ask about status updates of
> > >>>>>> contributions or bug reports
> > >>>>>> -
> > >>>>>>
> > >>>>>> “Are you still working on this?”
> > >>>>>> -
> > >>>>>>
> > >>>>>> “Are you still interested in this?”
> > >>>>>> -
> > >>>>>>
> > >>>>>> “Does this still happen on Flink 1.x?”
> > >>>>>> -
> > >>>>>>
> > >>>>>> “Are you still experiencing this issue?”
> > >>>>>> -
> > >>>>>>
> > >>>>>> “What is the status of the implementation”?
> > >>>>>> -
> > >>>>>>
> > >>>>>> while still encouraging users to add new tickets and to leave
> > >>>> feedback
> > >>>>>> about existing tickets
> > >>>>>>
> > >>>>>>
> > >>>>>> Please see the full proposal here:
> > >>>>>>
> > >>>>>>
> > >>
> >
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> > >>>>>> .
> > >>>>>>
> > >>>>>> The idea would be to discuss this proposal in this thread. If we
> > come
> > >>>> to
> > >>>>> a
> > >>>>>> conclusion, I'd document the proposal in the wiki [2] and we would
> > >> then
> > >>>>>> vote on it (approval by "Lazy Majority").
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>>
> > >>>>>> Konstantin
> > >>>>>>
> > >>>>>> [1]
> > >>>>>>
> > >>>>>>
> > >>
> >
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> > >>>>>> [2]
> > >>>>>>
> > >>>>>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> > >>>>>> --
> > >>>>>>
> > >>>>>> Konstantin Knauf
> > >>>>>>
> > >>>>>> https://twitter.com/snntrable
> > >>>>>>
> > >>>>>> https://github.com/knaufk
> > >>>>>>
> > >>
> >
> >
>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Khachatryan Roman <kh...@gmail.com>.
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 <dw...@apache.org>
wrote:
> I'd be fine with dropping the "Trivial" priority in favour of "starter"
> label.
>
> Best,
>
> Dawid
>
> On 01/03/2021 11:53, Konstantin Knauf wrote:
> > Hi Dawid,
> >
> > Thanks for the feedback. Do you think we should simply get rid of the
> > "Trivial" priority then and use the "starter" label more aggressively?
> >
> > Best,
> >
> > Konstantin
> >
> > On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <dwysakowicz@apache.org
> >
> > wrote:
> >
> >> Hi Konstantin,
> >>
> >> I also like the idea.
> >>
> >> Two comments:
> >>
> >> * you describe the "Trivial" priority as one that needs to be
> >> implemented immediately. First of all it is not used to often, but I
> >> think the way it works now is similar with a "starter" label. Tasks that
> >> are not bugs, are easy to implement and we think they are fine to be
> >> taken by newcomers. Therefore they do not fall in my mind into
> >> "immediately" category.
> >>
> >> * I would still deprioritise test instabilities. I think there shouldn't
> >> be a problem with that. We do post links to all failures therefore it
> >> will automatically priortise the tasks according to failure frequencies.
> >>
> >> Best,
> >>
> >> Dawid
> >>
> >> On 01/03/2021 09:38, Konstantin Knauf wrote:
> >>> Hi Xintong,
> >>>
> >>> yes, such labels would make a lot of sense. I added a sentence to the
> >>> document.
> >>>
> >>> Thanks,
> >>>
> >>> Konstantin
> >>>
> >>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <to...@gmail.com>
> >> wrote:
> >>>> Thanks for driving this discussion, Konstantin.
> >>>>
> >>>> I like the idea of having a bot reminding reporter/assignee/watchers
> >> about
> >>>> inactive tickets and if needed downgrade/close them automatically.
> >>>>
> >>>> My two cents:
> >>>> We may have labels like "downgraded-by-bot" / "closed-by-bot", so that
> >> it's
> >>>> easier to filter and review tickets updated by the bot.
> >>>> We may want to review such tickets (e.g., monthly) in case a valid
> >> ticket
> >>>> failed to draw the attention of relevant committers and the reporter
> >>>> doesn't know who to ping.
> >>>>
> >>>> Thank you~
> >>>>
> >>>> Xintong Song
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <tr...@apache.org>
> >>>> wrote:
> >>>>
> >>>>> Thanks for starting this discussion Konstantin. I like your proposal
> >> and
> >>>>> also the idea of automating the tedious parts of it via a bot.
> >>>>>
> >>>>> Cheers,
> >>>>> Till
> >>>>>
> >>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <kn...@apache.org>
> >>>>> wrote:
> >>>>>
> >>>>>> Dear Flink Community,
> >>>>>>
> >>>>>> I would like to start a discussion on improving and to some extent
> >>>> simply
> >>>>>> defining the way we work with Jira. Some aspects have been
> discussed a
> >>>>>> while back [1], but I would like to go a bit beyond that with the
> >>>>> following
> >>>>>> goals in mind:
> >>>>>>
> >>>>>>
> >>>>>> -
> >>>>>>
> >>>>>> clearer communication and expectation management with the
> community
> >>>>>> -
> >>>>>>
> >>>>>> a user or contributor should be able to judge the urgency of a
> >>>>> ticket
> >>>>>> by its priority
> >>>>>> -
> >>>>>>
> >>>>>> if a ticket is assigned to someone the expectation that
> someone
> >>>> is
> >>>>>> working on it should hold
> >>>>>> -
> >>>>>>
> >>>>>> generally reduce noise in Jira
> >>>>>> -
> >>>>>>
> >>>>>> reduce overhead of committers to ask about status updates of
> >>>>>> contributions or bug reports
> >>>>>> -
> >>>>>>
> >>>>>> “Are you still working on this?”
> >>>>>> -
> >>>>>>
> >>>>>> “Are you still interested in this?”
> >>>>>> -
> >>>>>>
> >>>>>> “Does this still happen on Flink 1.x?”
> >>>>>> -
> >>>>>>
> >>>>>> “Are you still experiencing this issue?”
> >>>>>> -
> >>>>>>
> >>>>>> “What is the status of the implementation”?
> >>>>>> -
> >>>>>>
> >>>>>> while still encouraging users to add new tickets and to leave
> >>>> feedback
> >>>>>> about existing tickets
> >>>>>>
> >>>>>>
> >>>>>> Please see the full proposal here:
> >>>>>>
> >>>>>>
> >>
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> >>>>>> .
> >>>>>>
> >>>>>> The idea would be to discuss this proposal in this thread. If we
> come
> >>>> to
> >>>>> a
> >>>>>> conclusion, I'd document the proposal in the wiki [2] and we would
> >> then
> >>>>>> vote on it (approval by "Lazy Majority").
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> Konstantin
> >>>>>>
> >>>>>> [1]
> >>>>>>
> >>>>>>
> >>
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> >>>>>> [2]
> >>>>>>
> >>>>>>
> >>
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> >>>>>> --
> >>>>>>
> >>>>>> Konstantin Knauf
> >>>>>>
> >>>>>> https://twitter.com/snntrable
> >>>>>>
> >>>>>> https://github.com/knaufk
> >>>>>>
> >>
>
>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Dawid Wysakowicz <dw...@apache.org>.
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 <dw...@apache.org>
> wrote:
>
>> Hi Konstantin,
>>
>> I also like the idea.
>>
>> Two comments:
>>
>> * you describe the "Trivial" priority as one that needs to be
>> implemented immediately. First of all it is not used to often, but I
>> think the way it works now is similar with a "starter" label. Tasks that
>> are not bugs, are easy to implement and we think they are fine to be
>> taken by newcomers. Therefore they do not fall in my mind into
>> "immediately" category.
>>
>> * I would still deprioritise test instabilities. I think there shouldn't
>> be a problem with that. We do post links to all failures therefore it
>> will automatically priortise the tasks according to failure frequencies.
>>
>> Best,
>>
>> Dawid
>>
>> On 01/03/2021 09:38, Konstantin Knauf wrote:
>>> Hi Xintong,
>>>
>>> yes, such labels would make a lot of sense. I added a sentence to the
>>> document.
>>>
>>> Thanks,
>>>
>>> Konstantin
>>>
>>> On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <to...@gmail.com>
>> wrote:
>>>> Thanks for driving this discussion, Konstantin.
>>>>
>>>> I like the idea of having a bot reminding reporter/assignee/watchers
>> about
>>>> inactive tickets and if needed downgrade/close them automatically.
>>>>
>>>> My two cents:
>>>> We may have labels like "downgraded-by-bot" / "closed-by-bot", so that
>> it's
>>>> easier to filter and review tickets updated by the bot.
>>>> We may want to review such tickets (e.g., monthly) in case a valid
>> ticket
>>>> failed to draw the attention of relevant committers and the reporter
>>>> doesn't know who to ping.
>>>>
>>>> Thank you~
>>>>
>>>> Xintong Song
>>>>
>>>>
>>>>
>>>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <tr...@apache.org>
>>>> wrote:
>>>>
>>>>> Thanks for starting this discussion Konstantin. I like your proposal
>> and
>>>>> also the idea of automating the tedious parts of it via a bot.
>>>>>
>>>>> Cheers,
>>>>> Till
>>>>>
>>>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <kn...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Dear Flink Community,
>>>>>>
>>>>>> I would like to start a discussion on improving and to some extent
>>>> simply
>>>>>> defining the way we work with Jira. Some aspects have been discussed a
>>>>>> while back [1], but I would like to go a bit beyond that with the
>>>>> following
>>>>>> goals in mind:
>>>>>>
>>>>>>
>>>>>> -
>>>>>>
>>>>>> clearer communication and expectation management with the community
>>>>>> -
>>>>>>
>>>>>> a user or contributor should be able to judge the urgency of a
>>>>> ticket
>>>>>> by its priority
>>>>>> -
>>>>>>
>>>>>> if a ticket is assigned to someone the expectation that someone
>>>> is
>>>>>> working on it should hold
>>>>>> -
>>>>>>
>>>>>> generally reduce noise in Jira
>>>>>> -
>>>>>>
>>>>>> reduce overhead of committers to ask about status updates of
>>>>>> contributions or bug reports
>>>>>> -
>>>>>>
>>>>>> “Are you still working on this?”
>>>>>> -
>>>>>>
>>>>>> “Are you still interested in this?”
>>>>>> -
>>>>>>
>>>>>> “Does this still happen on Flink 1.x?”
>>>>>> -
>>>>>>
>>>>>> “Are you still experiencing this issue?”
>>>>>> -
>>>>>>
>>>>>> “What is the status of the implementation”?
>>>>>> -
>>>>>>
>>>>>> while still encouraging users to add new tickets and to leave
>>>> feedback
>>>>>> about existing tickets
>>>>>>
>>>>>>
>>>>>> Please see the full proposal here:
>>>>>>
>>>>>>
>> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
>>>>>> .
>>>>>>
>>>>>> The idea would be to discuss this proposal in this thread. If we come
>>>> to
>>>>> a
>>>>>> conclusion, I'd document the proposal in the wiki [2] and we would
>> then
>>>>>> vote on it (approval by "Lazy Majority").
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Konstantin
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
>>>>>> [2]
>>>>>>
>>>>>>
>> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
>>>>>> --
>>>>>>
>>>>>> Konstantin Knauf
>>>>>>
>>>>>> https://twitter.com/snntrable
>>>>>>
>>>>>> https://github.com/knaufk
>>>>>>
>>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Konstantin Knauf <kn...@apache.org>.
Hi Roman,
thanks for your feedback. For the Technical Debt tickets the same rules as
for all other tickets would apply:
* Major+ indicates an active discussion or contribution.
* Minor is for everything else.
So, other issue types, too, do not imply an intention to work on it in the
near future. Take, for example, a user making a feature request or
improvement proposal and us waiting to see if there are more users that
would like to see this improvement.
The advantage I see with a dedicated Technical Debt ticket type is that it
encourages the community to document technical debt as part of their
regular workflow without cluttering the "backlog".
What do you think?
Cheers,
Konstantin
On Mon, Mar 1, 2021 at 9:48 PM Roman Khachatryan <ro...@apache.org> wrote:
> Hi,
>
> Thanks for the proposal Konstantin,
> I like the ideas expressed there.
>
> I am a bit concerned about the new issue type "Technical Debt". In contrast
> to other issue types, it doesn't imply that someone will likely work on
> that. So it can linger until the bot closes it.
> Probably we need some rules requiring a person opening such a ticket to
> have an intention to work on it in the near future?
> Another approach would be some wiki space.
>
> As for the trivial priority, I would remove it and (use labels where
> appropriate) as you suggested.
>
> Regards,
> Roman
>
>
> On Mon, Mar 1, 2021 at 11:53 AM Konstantin Knauf <konstantin@ververica.com
> >
> wrote:
>
> > Hi Dawid,
> >
> > Thanks for the feedback. Do you think we should simply get rid of the
> > "Trivial" priority then and use the "starter" label more aggressively?
> >
> > Best,
> >
> > Konstantin
> >
> > On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <dwysakowicz@apache.org
> >
> > wrote:
> >
> > > Hi Konstantin,
> > >
> > > I also like the idea.
> > >
> > > Two comments:
> > >
> > > * you describe the "Trivial" priority as one that needs to be
> > > implemented immediately. First of all it is not used to often, but I
> > > think the way it works now is similar with a "starter" label. Tasks
> that
> > > are not bugs, are easy to implement and we think they are fine to be
> > > taken by newcomers. Therefore they do not fall in my mind into
> > > "immediately" category.
> > >
> > > * I would still deprioritise test instabilities. I think there
> shouldn't
> > > be a problem with that. We do post links to all failures therefore it
> > > will automatically priortise the tasks according to failure
> frequencies.
> > >
> > > Best,
> > >
> > > Dawid
> > >
> > > On 01/03/2021 09:38, Konstantin Knauf wrote:
> > > > Hi Xintong,
> > > >
> > > > yes, such labels would make a lot of sense. I added a sentence to the
> > > > document.
> > > >
> > > > Thanks,
> > > >
> > > > Konstantin
> > > >
> > > > On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <to...@gmail.com>
> > > wrote:
> > > >
> > > >> Thanks for driving this discussion, Konstantin.
> > > >>
> > > >> I like the idea of having a bot reminding reporter/assignee/watchers
> > > about
> > > >> inactive tickets and if needed downgrade/close them automatically.
> > > >>
> > > >> My two cents:
> > > >> We may have labels like "downgraded-by-bot" / "closed-by-bot", so
> that
> > > it's
> > > >> easier to filter and review tickets updated by the bot.
> > > >> We may want to review such tickets (e.g., monthly) in case a valid
> > > ticket
> > > >> failed to draw the attention of relevant committers and the reporter
> > > >> doesn't know who to ping.
> > > >>
> > > >> Thank you~
> > > >>
> > > >> Xintong Song
> > > >>
> > > >>
> > > >>
> > > >> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <trohrmann@apache.org
> >
> > > >> wrote:
> > > >>
> > > >>> Thanks for starting this discussion Konstantin. I like your
> proposal
> > > and
> > > >>> also the idea of automating the tedious parts of it via a bot.
> > > >>>
> > > >>> Cheers,
> > > >>> Till
> > > >>>
> > > >>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <
> knaufk@apache.org>
> > > >>> wrote:
> > > >>>
> > > >>>> Dear Flink Community,
> > > >>>>
> > > >>>> I would like to start a discussion on improving and to some extent
> > > >> simply
> > > >>>> defining the way we work with Jira. Some aspects have been
> > discussed a
> > > >>>> while back [1], but I would like to go a bit beyond that with the
> > > >>> following
> > > >>>> goals in mind:
> > > >>>>
> > > >>>>
> > > >>>> -
> > > >>>>
> > > >>>> clearer communication and expectation management with the
> > community
> > > >>>> -
> > > >>>>
> > > >>>> a user or contributor should be able to judge the urgency
> of a
> > > >>> ticket
> > > >>>> by its priority
> > > >>>> -
> > > >>>>
> > > >>>> if a ticket is assigned to someone the expectation that
> > someone
> > > >> is
> > > >>>> working on it should hold
> > > >>>> -
> > > >>>>
> > > >>>> generally reduce noise in Jira
> > > >>>> -
> > > >>>>
> > > >>>> reduce overhead of committers to ask about status updates of
> > > >>>> contributions or bug reports
> > > >>>> -
> > > >>>>
> > > >>>> “Are you still working on this?”
> > > >>>> -
> > > >>>>
> > > >>>> “Are you still interested in this?”
> > > >>>> -
> > > >>>>
> > > >>>> “Does this still happen on Flink 1.x?”
> > > >>>> -
> > > >>>>
> > > >>>> “Are you still experiencing this issue?”
> > > >>>> -
> > > >>>>
> > > >>>> “What is the status of the implementation”?
> > > >>>> -
> > > >>>>
> > > >>>> while still encouraging users to add new tickets and to leave
> > > >> feedback
> > > >>>> about existing tickets
> > > >>>>
> > > >>>>
> > > >>>> Please see the full proposal here:
> > > >>>>
> > > >>>>
> > > >>
> > >
> >
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> > > >>>> .
> > > >>>>
> > > >>>> The idea would be to discuss this proposal in this thread. If we
> > come
> > > >> to
> > > >>> a
> > > >>>> conclusion, I'd document the proposal in the wiki [2] and we would
> > > then
> > > >>>> vote on it (approval by "Lazy Majority").
> > > >>>>
> > > >>>> Cheers,
> > > >>>>
> > > >>>> Konstantin
> > > >>>>
> > > >>>> [1]
> > > >>>>
> > > >>>>
> > > >>
> > >
> >
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> > > >>>> [2]
> > > >>>>
> > > >>>>
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> > > >>>> --
> > > >>>>
> > > >>>> Konstantin Knauf
> > > >>>>
> > > >>>> https://twitter.com/snntrable
> > > >>>>
> > > >>>> https://github.com/knaufk
> > > >>>>
> > > >
> > >
> > >
> >
> > --
> >
> > Konstantin Knauf | Head of Product
> >
> > +49 160 91394525
> >
> >
> > Follow us @VervericaData Ververica <https://www.ververica.com/>
> >
> >
> > --
> >
> > Join Flink Forward <https://flink-forward.org/> - The Apache Flink
> > Conference
> >
> > Stream Processing | Event Driven | Real Time
> >
> > --
> >
> > Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany
> >
> > --
> > Ververica GmbH
> > Registered at Amtsgericht Charlottenburg: HRB 158244 B
> > Managing Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl Anton
> > Wehner
> >
>
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk
Re: [DISCUSS] Apache Flink Jira Process
Posted by Roman Khachatryan <ro...@apache.org>.
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 <ko...@ververica.com>
wrote:
> Hi Dawid,
>
> Thanks for the feedback. Do you think we should simply get rid of the
> "Trivial" priority then and use the "starter" label more aggressively?
>
> Best,
>
> Konstantin
>
> On Mon, Mar 1, 2021 at 11:44 AM Dawid Wysakowicz <dw...@apache.org>
> wrote:
>
> > Hi Konstantin,
> >
> > I also like the idea.
> >
> > Two comments:
> >
> > * you describe the "Trivial" priority as one that needs to be
> > implemented immediately. First of all it is not used to often, but I
> > think the way it works now is similar with a "starter" label. Tasks that
> > are not bugs, are easy to implement and we think they are fine to be
> > taken by newcomers. Therefore they do not fall in my mind into
> > "immediately" category.
> >
> > * I would still deprioritise test instabilities. I think there shouldn't
> > be a problem with that. We do post links to all failures therefore it
> > will automatically priortise the tasks according to failure frequencies.
> >
> > Best,
> >
> > Dawid
> >
> > On 01/03/2021 09:38, Konstantin Knauf wrote:
> > > Hi Xintong,
> > >
> > > yes, such labels would make a lot of sense. I added a sentence to the
> > > document.
> > >
> > > Thanks,
> > >
> > > Konstantin
> > >
> > > On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <to...@gmail.com>
> > wrote:
> > >
> > >> Thanks for driving this discussion, Konstantin.
> > >>
> > >> I like the idea of having a bot reminding reporter/assignee/watchers
> > about
> > >> inactive tickets and if needed downgrade/close them automatically.
> > >>
> > >> My two cents:
> > >> We may have labels like "downgraded-by-bot" / "closed-by-bot", so that
> > it's
> > >> easier to filter and review tickets updated by the bot.
> > >> We may want to review such tickets (e.g., monthly) in case a valid
> > ticket
> > >> failed to draw the attention of relevant committers and the reporter
> > >> doesn't know who to ping.
> > >>
> > >> Thank you~
> > >>
> > >> Xintong Song
> > >>
> > >>
> > >>
> > >> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <tr...@apache.org>
> > >> wrote:
> > >>
> > >>> Thanks for starting this discussion Konstantin. I like your proposal
> > and
> > >>> also the idea of automating the tedious parts of it via a bot.
> > >>>
> > >>> Cheers,
> > >>> Till
> > >>>
> > >>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <kn...@apache.org>
> > >>> wrote:
> > >>>
> > >>>> Dear Flink Community,
> > >>>>
> > >>>> I would like to start a discussion on improving and to some extent
> > >> simply
> > >>>> defining the way we work with Jira. Some aspects have been
> discussed a
> > >>>> while back [1], but I would like to go a bit beyond that with the
> > >>> following
> > >>>> goals in mind:
> > >>>>
> > >>>>
> > >>>> -
> > >>>>
> > >>>> clearer communication and expectation management with the
> community
> > >>>> -
> > >>>>
> > >>>> a user or contributor should be able to judge the urgency of a
> > >>> ticket
> > >>>> by its priority
> > >>>> -
> > >>>>
> > >>>> if a ticket is assigned to someone the expectation that
> someone
> > >> is
> > >>>> working on it should hold
> > >>>> -
> > >>>>
> > >>>> generally reduce noise in Jira
> > >>>> -
> > >>>>
> > >>>> reduce overhead of committers to ask about status updates of
> > >>>> contributions or bug reports
> > >>>> -
> > >>>>
> > >>>> “Are you still working on this?”
> > >>>> -
> > >>>>
> > >>>> “Are you still interested in this?”
> > >>>> -
> > >>>>
> > >>>> “Does this still happen on Flink 1.x?”
> > >>>> -
> > >>>>
> > >>>> “Are you still experiencing this issue?”
> > >>>> -
> > >>>>
> > >>>> “What is the status of the implementation”?
> > >>>> -
> > >>>>
> > >>>> while still encouraging users to add new tickets and to leave
> > >> feedback
> > >>>> about existing tickets
> > >>>>
> > >>>>
> > >>>> Please see the full proposal here:
> > >>>>
> > >>>>
> > >>
> >
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> > >>>> .
> > >>>>
> > >>>> The idea would be to discuss this proposal in this thread. If we
> come
> > >> to
> > >>> a
> > >>>> conclusion, I'd document the proposal in the wiki [2] and we would
> > then
> > >>>> vote on it (approval by "Lazy Majority").
> > >>>>
> > >>>> Cheers,
> > >>>>
> > >>>> Konstantin
> > >>>>
> > >>>> [1]
> > >>>>
> > >>>>
> > >>
> >
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> > >>>> [2]
> > >>>>
> > >>>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> > >>>> --
> > >>>>
> > >>>> Konstantin Knauf
> > >>>>
> > >>>> https://twitter.com/snntrable
> > >>>>
> > >>>> https://github.com/knaufk
> > >>>>
> > >
> >
> >
>
> --
>
> Konstantin Knauf | Head of Product
>
> +49 160 91394525
>
>
> Follow us @VervericaData Ververica <https://www.ververica.com/>
>
>
> --
>
> Join Flink Forward <https://flink-forward.org/> - The Apache Flink
> Conference
>
> Stream Processing | Event Driven | Real Time
>
> --
>
> Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany
>
> --
> Ververica GmbH
> Registered at Amtsgericht Charlottenburg: HRB 158244 B
> Managing Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl Anton
> Wehner
>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Konstantin Knauf <ko...@ververica.com>.
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 <dw...@apache.org>
wrote:
> Hi Konstantin,
>
> I also like the idea.
>
> Two comments:
>
> * you describe the "Trivial" priority as one that needs to be
> implemented immediately. First of all it is not used to often, but I
> think the way it works now is similar with a "starter" label. Tasks that
> are not bugs, are easy to implement and we think they are fine to be
> taken by newcomers. Therefore they do not fall in my mind into
> "immediately" category.
>
> * I would still deprioritise test instabilities. I think there shouldn't
> be a problem with that. We do post links to all failures therefore it
> will automatically priortise the tasks according to failure frequencies.
>
> Best,
>
> Dawid
>
> On 01/03/2021 09:38, Konstantin Knauf wrote:
> > Hi Xintong,
> >
> > yes, such labels would make a lot of sense. I added a sentence to the
> > document.
> >
> > Thanks,
> >
> > Konstantin
> >
> > On Mon, Mar 1, 2021 at 8:51 AM Xintong Song <to...@gmail.com>
> wrote:
> >
> >> Thanks for driving this discussion, Konstantin.
> >>
> >> I like the idea of having a bot reminding reporter/assignee/watchers
> about
> >> inactive tickets and if needed downgrade/close them automatically.
> >>
> >> My two cents:
> >> We may have labels like "downgraded-by-bot" / "closed-by-bot", so that
> it's
> >> easier to filter and review tickets updated by the bot.
> >> We may want to review such tickets (e.g., monthly) in case a valid
> ticket
> >> failed to draw the attention of relevant committers and the reporter
> >> doesn't know who to ping.
> >>
> >> Thank you~
> >>
> >> Xintong Song
> >>
> >>
> >>
> >> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <tr...@apache.org>
> >> wrote:
> >>
> >>> Thanks for starting this discussion Konstantin. I like your proposal
> and
> >>> also the idea of automating the tedious parts of it via a bot.
> >>>
> >>> Cheers,
> >>> Till
> >>>
> >>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <kn...@apache.org>
> >>> wrote:
> >>>
> >>>> Dear Flink Community,
> >>>>
> >>>> I would like to start a discussion on improving and to some extent
> >> simply
> >>>> defining the way we work with Jira. Some aspects have been discussed a
> >>>> while back [1], but I would like to go a bit beyond that with the
> >>> following
> >>>> goals in mind:
> >>>>
> >>>>
> >>>> -
> >>>>
> >>>> clearer communication and expectation management with the community
> >>>> -
> >>>>
> >>>> a user or contributor should be able to judge the urgency of a
> >>> ticket
> >>>> by its priority
> >>>> -
> >>>>
> >>>> if a ticket is assigned to someone the expectation that someone
> >> is
> >>>> working on it should hold
> >>>> -
> >>>>
> >>>> generally reduce noise in Jira
> >>>> -
> >>>>
> >>>> reduce overhead of committers to ask about status updates of
> >>>> contributions or bug reports
> >>>> -
> >>>>
> >>>> “Are you still working on this?”
> >>>> -
> >>>>
> >>>> “Are you still interested in this?”
> >>>> -
> >>>>
> >>>> “Does this still happen on Flink 1.x?”
> >>>> -
> >>>>
> >>>> “Are you still experiencing this issue?”
> >>>> -
> >>>>
> >>>> “What is the status of the implementation”?
> >>>> -
> >>>>
> >>>> while still encouraging users to add new tickets and to leave
> >> feedback
> >>>> about existing tickets
> >>>>
> >>>>
> >>>> Please see the full proposal here:
> >>>>
> >>>>
> >>
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> >>>> .
> >>>>
> >>>> The idea would be to discuss this proposal in this thread. If we come
> >> to
> >>> a
> >>>> conclusion, I'd document the proposal in the wiki [2] and we would
> then
> >>>> vote on it (approval by "Lazy Majority").
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Konstantin
> >>>>
> >>>> [1]
> >>>>
> >>>>
> >>
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> >>>> [2]
> >>>>
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> >>>> --
> >>>>
> >>>> Konstantin Knauf
> >>>>
> >>>> https://twitter.com/snntrable
> >>>>
> >>>> https://github.com/knaufk
> >>>>
> >
>
>
--
Konstantin Knauf | Head of Product
+49 160 91394525
Follow us @VervericaData Ververica <https://www.ververica.com/>
--
Join Flink Forward <https://flink-forward.org/> - The Apache Flink
Conference
Stream Processing | Event Driven | Real Time
--
Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany
--
Ververica GmbH
Registered at Amtsgericht Charlottenburg: HRB 158244 B
Managing Directors: Yip Park Tung Jason, Jinwei (Kevin) Zhang, Karl Anton
Wehner
Re: [DISCUSS] Apache Flink Jira Process
Posted by Dawid Wysakowicz <dw...@apache.org>.
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 <to...@gmail.com> wrote:
>
>> Thanks for driving this discussion, Konstantin.
>>
>> I like the idea of having a bot reminding reporter/assignee/watchers about
>> inactive tickets and if needed downgrade/close them automatically.
>>
>> My two cents:
>> We may have labels like "downgraded-by-bot" / "closed-by-bot", so that it's
>> easier to filter and review tickets updated by the bot.
>> We may want to review such tickets (e.g., monthly) in case a valid ticket
>> failed to draw the attention of relevant committers and the reporter
>> doesn't know who to ping.
>>
>> Thank you~
>>
>> Xintong Song
>>
>>
>>
>> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <tr...@apache.org>
>> wrote:
>>
>>> Thanks for starting this discussion Konstantin. I like your proposal and
>>> also the idea of automating the tedious parts of it via a bot.
>>>
>>> Cheers,
>>> Till
>>>
>>> On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <kn...@apache.org>
>>> wrote:
>>>
>>>> Dear Flink Community,
>>>>
>>>> I would like to start a discussion on improving and to some extent
>> simply
>>>> defining the way we work with Jira. Some aspects have been discussed a
>>>> while back [1], but I would like to go a bit beyond that with the
>>> following
>>>> goals in mind:
>>>>
>>>>
>>>> -
>>>>
>>>> clearer communication and expectation management with the community
>>>> -
>>>>
>>>> a user or contributor should be able to judge the urgency of a
>>> ticket
>>>> by its priority
>>>> -
>>>>
>>>> if a ticket is assigned to someone the expectation that someone
>> is
>>>> working on it should hold
>>>> -
>>>>
>>>> generally reduce noise in Jira
>>>> -
>>>>
>>>> reduce overhead of committers to ask about status updates of
>>>> contributions or bug reports
>>>> -
>>>>
>>>> “Are you still working on this?”
>>>> -
>>>>
>>>> “Are you still interested in this?”
>>>> -
>>>>
>>>> “Does this still happen on Flink 1.x?”
>>>> -
>>>>
>>>> “Are you still experiencing this issue?”
>>>> -
>>>>
>>>> “What is the status of the implementation”?
>>>> -
>>>>
>>>> while still encouraging users to add new tickets and to leave
>> feedback
>>>> about existing tickets
>>>>
>>>>
>>>> Please see the full proposal here:
>>>>
>>>>
>> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
>>>> .
>>>>
>>>> The idea would be to discuss this proposal in this thread. If we come
>> to
>>> a
>>>> conclusion, I'd document the proposal in the wiki [2] and we would then
>>>> vote on it (approval by "Lazy Majority").
>>>>
>>>> Cheers,
>>>>
>>>> Konstantin
>>>>
>>>> [1]
>>>>
>>>>
>> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
>>>> [2]
>>>>
>>>>
>> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
>>>> --
>>>>
>>>> Konstantin Knauf
>>>>
>>>> https://twitter.com/snntrable
>>>>
>>>> https://github.com/knaufk
>>>>
>
Re: [DISCUSS] Apache Flink Jira Process
Posted by Konstantin Knauf <kn...@apache.org>.
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 <to...@gmail.com> wrote:
> Thanks for driving this discussion, Konstantin.
>
> I like the idea of having a bot reminding reporter/assignee/watchers about
> inactive tickets and if needed downgrade/close them automatically.
>
> My two cents:
> We may have labels like "downgraded-by-bot" / "closed-by-bot", so that it's
> easier to filter and review tickets updated by the bot.
> We may want to review such tickets (e.g., monthly) in case a valid ticket
> failed to draw the attention of relevant committers and the reporter
> doesn't know who to ping.
>
> Thank you~
>
> Xintong Song
>
>
>
> On Sat, Feb 27, 2021 at 1:37 AM Till Rohrmann <tr...@apache.org>
> wrote:
>
> > Thanks for starting this discussion Konstantin. I like your proposal and
> > also the idea of automating the tedious parts of it via a bot.
> >
> > Cheers,
> > Till
> >
> > On Fri, Feb 26, 2021 at 4:17 PM Konstantin Knauf <kn...@apache.org>
> > wrote:
> >
> > > Dear Flink Community,
> > >
> > > I would like to start a discussion on improving and to some extent
> simply
> > > defining the way we work with Jira. Some aspects have been discussed a
> > > while back [1], but I would like to go a bit beyond that with the
> > following
> > > goals in mind:
> > >
> > >
> > > -
> > >
> > > clearer communication and expectation management with the community
> > > -
> > >
> > > a user or contributor should be able to judge the urgency of a
> > ticket
> > > by its priority
> > > -
> > >
> > > if a ticket is assigned to someone the expectation that someone
> is
> > > working on it should hold
> > > -
> > >
> > > generally reduce noise in Jira
> > > -
> > >
> > > reduce overhead of committers to ask about status updates of
> > > contributions or bug reports
> > > -
> > >
> > > “Are you still working on this?”
> > > -
> > >
> > > “Are you still interested in this?”
> > > -
> > >
> > > “Does this still happen on Flink 1.x?”
> > > -
> > >
> > > “Are you still experiencing this issue?”
> > > -
> > >
> > > “What is the status of the implementation”?
> > > -
> > >
> > > while still encouraging users to add new tickets and to leave
> feedback
> > > about existing tickets
> > >
> > >
> > > Please see the full proposal here:
> > >
> > >
> >
> https://docs.google.com/document/d/19VmykDSn4BHgsCNTXtN89R7xea8e3cUIl-uivW8L6W8/edit#
> > > .
> > >
> > > The idea would be to discuss this proposal in this thread. If we come
> to
> > a
> > > conclusion, I'd document the proposal in the wiki [2] and we would then
> > > vote on it (approval by "Lazy Majority").
> > >
> > > Cheers,
> > >
> > > Konstantin
> > >
> > > [1]
> > >
> > >
> >
> https://lists.apache.org/thread.html/rd34fb695d371c2bf0cbd1696ce190bac35dd78f29edd8c60d0c7ee71%40%3Cdev.flink.apache.org%3E
> > > [2]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/FLINK/FLINK+Jira+field+definitions
> > >
> > > --
> > >
> > > Konstantin Knauf
> > >
> > > https://twitter.com/snntrable
> > >
> > > https://github.com/knaufk
> > >
> >
>
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk