Re: JIRA priorities explaination

[Kenneth Knowles <ke...@apache.org>]

Coming back to this thread (again!)

I wrote up https://beam.apache.org/contribute/jira-priorities/ and
https://beam.apache.org/contribute/release-blockers/ and I have had success
communicating using these docs.

However, some people get confused because the existing Jira priorities have
tooltips that say something slightly different [1], or they just don't
discover the site.

Since Jira 7.6.0, I think, it is possible to customize this in Jira
directly. [2]

What do you think about changing from the default priorities to just P0,
P1, etc, and using these tooltips that match the docs on the Beam site?

P0 - Outage blocking development and/or testing work; requires immediate
and continuous attention
P1 - Critical bug: data loss, total loss of function, or loss of testing
signal due to test failures or flakiness
P2 - Default priority. Will be triaged and planned according to community
practices.
P3 - Non-urgent bugs, features, and improvements
P4 - Trivial items, spelling errors, etc.

This is related to the "Automation for Jira" thread. It was suggested to
automatically lower priorities of stale bugs, to match reality and let us
focus on the bugs that remain at higher priorities. I hope automatically
moving "P2" to "P3" with these tooltips is nicer for people than
automatically moving "Major" to "Minor". Using the default words seems like
you are telling the user their problem is minor.

Kenn

[1]
https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels
[2] https://jira.atlassian.com/browse/JRASERVER-3821

On Fri, Oct 25, 2019 at 4:25 PM Pablo Estrada <pa...@google.com> wrote:

> That SGTM
>
> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw <ro...@google.com>
> wrote:
>
>> +1 to both.
>>
>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev <va...@google.com>
>> wrote:
>> >
>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles <ke...@apache.org>
>> wrote:
>> >>
>> >> Suppose, hypothetically, we say that if Fix Version is set, then
>> P0/Blocker and P1/Critical block release and lower priorities get bumped.
>> >
>> >
>> > +1 to Kenn's suggestion.  In addition, we can discourage setting Fix
>> version for non-critical issues before issues are fixed.
>> >
>> >>
>> >>
>> >> Most likely the release manager still pings and asks about all those
>> before bumping. Which means that in effect they were part of the burn down
>> and do block the release in the sense that they must be re-triaged away to
>> the next release. I would prefer less work for the release manager and more
>> emphasis on the default being nonblocking.
>> >>
>> >> One very different possibility is to ignore Fix Version on open bugs
>> and use a different search query as the burndown, auto bump everything that
>> didn't make it.
>> >
>> > This may create a situation where an issue will eventually be closed,
>> but Fix Version not updated, and confuse the users who will rely "Fix
>> Version" to  find which release actually fixes the issue. A pass over open
>> bugs with a Fix Version set to next release (as currently done by a release
>> manager) helps to make sure that unfixed bugs won't have Fix Version tag of
>> the upcoming release.
>> >
>> >>
>> >> Kenn
>> >>
>> >> On Fri, Oct 25, 2019, 14:16 Robert Bradshaw <ro...@google.com>
>> wrote:
>> >>>
>> >>> I'm fine with that, but in that case we should have a priority for
>> >>> release blockers, below which bugs get automatically bumped to the
>> >>> next release (and which becomes the burndown list).
>> >>>
>> >>> On Fri, Oct 25, 2019 at 1:58 PM Kenneth Knowles <ke...@apache.org>
>> wrote:
>> >>> >
>> >>> > My takeaway from this thread is that priorities should have a
>> shared community intuition and/or policy around how they are treated, which
>> could eventually be formalized into SLOs.
>> >>> >
>> >>> > At a practical level, I do think that build breaks are higher
>> priority than release blockers. If you are on this thread but not looking
>> at the PR, here is the verbiage I added about urgency:
>> >>> >
>> >>> > P0/Blocker: "A P0 issue is more urgent than simply blocking the
>> next release"
>> >>> > P1/Critical: "Most critical bugs should block release"
>> >>> > P2/Major: "No special urgency is associated"
>> >>> > ...
>> >>> >
>> >>> > Kenn
>> >>> >
>> >>> > On Fri, Oct 25, 2019 at 11:46 AM Robert Bradshaw <
>> robertwb@google.com> wrote:
>> >>> >>
>> >>> >> We cut a release every 6 weeks, according to schedule, making it
>> easy
>> >>> >> to plan for, and the release manager typically sends out a warning
>> >>> >> email to remind everyone. I don't think it makes sense to do that
>> for
>> >>> >> every ticket. Blockers should be reserved for things we really
>> >>> >> shouldn't release without.
>> >>> >>
>> >>> >> On Fri, Oct 25, 2019 at 11:33 AM Pablo Estrada <pa...@google.com>
>> wrote:
>> >>> >> >
>> >>> >> > I mentioned on the PR that I had been using the 'blocker'
>> priority along with the 'fix version' field to mark issues that I want to
>> get in the release.
>> >>> >> > Of course, this little practice of mine only matters much around
>> release branch cutting time - and has been useful for me to track which
>> things I want to ensure getting into the release / bump to the next /etc.
>> >>> >> > I've also found it to be useful as a way to communicate with the
>> release manager without having to sync directly.
>> >>> >> >
>> >>> >> > What would be a reasonable way to tell the release manager "I'd
>> like to get this feature in. please talk to me if you're about to cut the
>> branch" - that also uses the priorities appropriately? - and that allows
>> the release manager to know when a fix version is "more optional" / "less
>> optional"?
>> >>> >> >
>> >>> >> > On Wed, Oct 23, 2019 at 12:20 PM Kenneth Knowles <
>> kenn@apache.org> wrote:
>> >>> >> >>
>> >>> >> >> I finally got around to writing some of this up. It is minimal.
>> Feedback is welcome, especially if what I have written does not accurately
>> represent the community's approach.
>> >>> >> >>
>> >>> >> >> https://github.com/apache/beam/pull/9862
>> >>> >> >>
>> >>> >> >> Kenn
>> >>> >> >>
>> >>> >> >> On Mon, Feb 11, 2019 at 3:21 PM Daniel Oliveira <
>> danoliveira@google.com> wrote:
>> >>> >> >>>
>> >>> >> >>> Ah, sorry, I missed that Alex was just quoting from our Jira
>> installation (didn't read his email closely enough). Also I wasn't aware
>> about those pages on our website.
>> >>> >> >>>
>> >>> >> >>> Seeing as we do have definitions for our priorities, I guess
>> my main request would be that they be made more discoverable somehow. I
>> don't think the tooltips are reliable, and the pages on the website are
>> informative, but hard to find. Since it feels a bit lazy to say "this isn't
>> discoverable enough" without suggesting any improvements, I'd like to
>> propose these two changes:
>> >>> >> >>>
>> >>> >> >>> 1. We should write a Beam Jira Guide with basic information
>> about our Jira. I think the bug priorities should go in here, but also
>> anything else we would want someone to know before filing any Jira issues,
>> like how our components are organized or what the different issue types
>> mean. This guide could either be written in the website or the wiki, but I
>> think it should definitely be linked in
>> https://beam.apache.org/contribute/ so that newcomers read it before
>> getting their Jira account approved. The goal here being to have a
>> reference for the basics of our Jira since at the moment it doesn't seem
>> like we have anything for this.
>> >>> >> >>>
>> >>> >> >>> 2. The existing info on Post-commit and pre-commit policies
>> doesn't seem very discoverable to someone monitoring the Pre/Post-commits.
>> I've reported a handful of test-failures already and haven't seen this link
>> mentioned much. We should try to find a way to funnel people towards this
>> link when there's an issue, the same way we try to funnel people towards
>> the contribution guide when they write a PR. As a note, while writing this
>> email I remembered this link that someone gave me before (
>> https://s.apache.org/beam-test-failure). That mentions the Post-commit
>> policies page, so maybe it's just a matter of pasting that all over our
>> Jenkins builds whenever we have a failing test?
>> >>> >> >>>
>> >>> >> >>> PS: I'm also definitely for SLOs, but I figure it's probably
>> better discussed in a separate thread so I'm trying to stick to the subject
>> of priority definitions.
>> >>> >> >>>
>> >>> >> >>> On Mon, Feb 11, 2019 at 9:17 AM Scott Wegner <sc...@apache.org>
>> wrote:
>> >>> >> >>>>
>> >>> >> >>>> Thanks for driving this discussion. I also was not aware of
>> these existing definitions. Once we agree on the terms, let's add them to
>> our Contributor Guide and start using them.
>> >>> >> >>>>
>> >>> >> >>>> +1 in general; I like both Alex and Kenn's definitions;
>> Additional wordsmithing could be moved to a Pull Request. Can we make the
>> definitions useful for both the person filing a bug, and the assignee, i.e.
>> >>> >> >>>>
>> >>> >> >>>> <Priority Level>: <Criteria for what types of issues should
>> be assigned>. <Expectations for responding to a Priority Level issue>
>> >>> >> >>>>
>> >>> >> >>>> On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles <
>> klk@google.com> wrote:
>> >>> >> >>>>>
>> >>> >> >>>>> The content that Alex posted* is the definition from our
>> Jira installation anyhow.
>> >>> >> >>>>>
>> >>> >> >>>>> I just searched around, and there's
>> https://community.atlassian.com/t5/Jira-questions/According-to-Jira-What-is-Blocker-Critical-Major-Minor-and/qaq-p/668774
>> which makes clear that this is really user-defined, since Jira has many
>> deployments with their own configs.
>> >>> >> >>>>>
>> >>> >> >>>>> I guess what I want to know about this thread is what action
>> is being proposed?
>> >>> >> >>>>>
>> >>> >> >>>>> Previously, there was a thread that resulted in
>> https://beam.apache.org/contribute/precommit-policies/ and
>> https://beam.apache.org/contribute/postcommits-policies/. These have
>> test failures and flakes as Critical. I agree with Alex that these should
>> be Blocker. They disrupt the work of the entire community, so we need to
>> drop everything and get green again.
>> >>> >> >>>>>
>> >>> >> >>>>> Other than that, I think what you - Daniel - are suggesting
>> is that the definition might be best expressed as SLOs. I asked on
>> user@infra.apache.org about how we could have those and the answer is
>> the homebrew
>> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/status/sla/jira/.
>> If anyone has time to dig into that and see if it can work for us, that
>> would be cool.
>> >>> >> >>>>>
>> >>> >> >>>>> Kenn
>> >>> >> >>>>>
>> >>> >> >>>>> *Blocker: Blocks development and/or testing work, production
>> could not run
>> >>> >> >>>>> Critical: Crashes, loss of data, severe memory leak.
>> >>> >> >>>>> Major (Default): Major loss of function.
>> >>> >> >>>>> Minor: Minor loss of function, or other problem where easy
>> workaround is present.
>> >>> >> >>>>> Trivial: Trivial Cosmetic problem like misspelt words or
>> misaligned text.
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>> On Sun, Feb 10, 2019 at 7:20 PM Daniel Oliveira <
>> danoliveira@google.com> wrote:
>> >>> >> >>>>>>
>> >>> >> >>>>>> Are there existing meanings for the priorities in Jira
>> already? I wasn't able to find any info on either the Beam website or wiki
>> about it, so I've just been prioritizing issues based on gut feeling. If
>> not, I think having some well-defined priorities would be nice, at least
>> for our test-failures, and especially if we wanna have some SLOs like I've
>> seen being thrown about.
>> >>> >> >>>>>>
>> >>> >> >>>>>> On Fri, Feb 8, 2019 at 3:06 PM Kenneth Knowles <
>> kenn@apache.org> wrote:
>> >>> >> >>>>>>>
>> >>> >> >>>>>>> I've been thinking about this since working on the
>> release. If I ignore the names I think:
>> >>> >> >>>>>>>
>> >>> >> >>>>>>> P0: get paged, stop whatever you planned on doing, work
>> late to fix
>> >>> >> >>>>>>> P1: continually update everyone on status and shouldn't
>> sit around unassigned
>> >>> >> >>>>>>> P2: most things here; they can be planned or picked up by
>> whomever
>> >>> >> >>>>>>> P3: nice-to-have things, maybe starter tasks or lesser
>> cleanup, but no driving need
>> >>> >> >>>>>>> Sometimes there's P4 but I don't value it. Often P3 is a
>> deprioritized thing from P2, so more involved and complex, while P4 is
>> something easy and not important filed just as a reminder. Either way, they
>> are both not on the main path of work.
>> >>> >> >>>>>>>
>> >>> >> >>>>>>> I looked into it and the Jira priority scheme determines
>> the set of priorities as well as the default. Ours is shared by 635
>> projects. Probably worth keeping. The default priority is Major which would
>> correspond with P2. We can expect the default to be where most issues end
>> up.
>> >>> >> >>>>>>>
>> >>> >> >>>>>>> P0 == Blocker: get paged, stop whatever you planned on
>> doing, work late to fix
>> >>> >> >>>>>>> P1 == Critical: continually update everyone on status and
>> shouldn't sit around unassigned
>> >>> >> >>>>>>> P0 == Major (default): most things here; they can be
>> planned or picked up by whomever
>> >>> >> >>>>>>> P3 == Minor: nice-to-have things, maybe starter tasks or
>> lesser cleanup, but no driving need
>> >>> >> >>>>>>> Trivial: Maybe this is attractive to newcomers as it makes
>> it sound easy.
>> >>> >> >>>>>>>
>> >>> >> >>>>>>> Kenn
>> >>> >> >>>>>>>
>> >>> >> >>>>>>> On Thu, Feb 7, 2019 at 4:08 PM Alex Amato <
>> ajamato@google.com> wrote:
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> Hello Beam community, I was thinking about this and found
>> some information to share/discuss. Would it be possible to confirm my
>> thinking on this:
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> There are 5 priorities in the JIRA system today (tooltip
>> link):
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> Blocker Blocks development and/or testing work,
>> production could not run
>> >>> >> >>>>>>>> Critical Crashes, loss of data, severe memory leak.
>> >>> >> >>>>>>>> Major Major loss of function.
>> >>> >> >>>>>>>> Minor Minor loss of function, or other problem where easy
>> workaround is present.
>> >>> >> >>>>>>>> Trivial Cosmetic problem like misspelt words or
>> misaligned text.
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> How should JIRA issues be prioritized for pre/post commit
>> test failures?
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> I think Blocker
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> What about the flakey failures?
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> Blocker as well?
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> How should non test issues be prioritized? (E.g. feature
>> to implement or bugs not regularly breaking tests).
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> I suggest Minor, but its not clear how to distinguish
>> between these.
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> Below is my thinking: But I wanted to know what the
>> Apache/Beam community generally thinks about these priorities.
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> Blocker: Expect to be paged. Production systems are down.
>> >>> >> >>>>>>>> Critical: Expect to be contacted by email or a bot to fix
>> this.
>> >>> >> >>>>>>>> Major: Some loss of function in the repository, can
>> issues that need to be addressed soon are here.
>> >>> >> >>>>>>>> Minor: Most issues will be here, important issues within
>> this will get picked up and completed. FRs, bugs.
>> >>> >> >>>>>>>> Trivial: Unlikely to be implemented, far too many issues
>> in this category. FRs, bugs.
>> >>> >> >>>>>>>>
>> >>> >> >>>>>>>> Thanks for helping to clear this up
>> >>> >> >>>>>>>> Alex
>> >>> >> >>>>
>> >>> >> >>>>
>> >>> >> >>>>
>> >>> >> >>>> --
>> >>> >> >>>>
>> >>> >> >>>>
>> >>> >> >>>>
>> >>> >> >>>>
>> >>> >> >>>> Got feedback? tinyurl.com/swegner-feedback
>>
>

Re: JIRA priorities explaination

[Luke Cwik <lc...@google.com>]

Sounds good to me.

On Fri, May 1, 2020 at 2:34 PM Kenneth Knowles <ke...@apache.org> wrote:

> Coming back to this thread (again!)
>
> I wrote up https://beam.apache.org/contribute/jira-priorities/ and
> https://beam.apache.org/contribute/release-blockers/ and I have had
> success communicating using these docs.
>
> However, some people get confused because the existing Jira priorities
> have tooltips that say something slightly different [1], or they just don't
> discover the site.
>
> Since Jira 7.6.0, I think, it is possible to customize this in Jira
> directly. [2]
>
> What do you think about changing from the default priorities to just P0,
> P1, etc, and using these tooltips that match the docs on the Beam site?
>
> P0 - Outage blocking development and/or testing work; requires immediate
> and continuous attention
> P1 - Critical bug: data loss, total loss of function, or loss of testing
> signal due to test failures or flakiness
> P2 - Default priority. Will be triaged and planned according to community
> practices.
> P3 - Non-urgent bugs, features, and improvements
> P4 - Trivial items, spelling errors, etc.
>
> This is related to the "Automation for Jira" thread. It was suggested to
> automatically lower priorities of stale bugs, to match reality and let us
> focus on the bugs that remain at higher priorities. I hope automatically
> moving "P2" to "P3" with these tooltips is nicer for people than
> automatically moving "Major" to "Minor". Using the default words seems like
> you are telling the user their problem is minor.
>
> Kenn
>
> [1]
> https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels
> [2] https://jira.atlassian.com/browse/JRASERVER-3821
>
> On Fri, Oct 25, 2019 at 4:25 PM Pablo Estrada <pa...@google.com> wrote:
>
>> That SGTM
>>
>> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw <ro...@google.com>
>> wrote:
>>
>>> +1 to both.
>>>
>>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev <va...@google.com>
>>> wrote:
>>> >
>>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles <ke...@apache.org>
>>> wrote:
>>> >>
>>> >> Suppose, hypothetically, we say that if Fix Version is set, then
>>> P0/Blocker and P1/Critical block release and lower priorities get bumped.
>>> >
>>> >
>>> > +1 to Kenn's suggestion.  In addition, we can discourage setting Fix
>>> version for non-critical issues before issues are fixed.
>>> >
>>> >>
>>> >>
>>> >> Most likely the release manager still pings and asks about all those
>>> before bumping. Which means that in effect they were part of the burn down
>>> and do block the release in the sense that they must be re-triaged away to
>>> the next release. I would prefer less work for the release manager and more
>>> emphasis on the default being nonblocking.
>>> >>
>>> >> One very different possibility is to ignore Fix Version on open bugs
>>> and use a different search query as the burndown, auto bump everything that
>>> didn't make it.
>>> >
>>> > This may create a situation where an issue will eventually be closed,
>>> but Fix Version not updated, and confuse the users who will rely "Fix
>>> Version" to  find which release actually fixes the issue. A pass over open
>>> bugs with a Fix Version set to next release (as currently done by a release
>>> manager) helps to make sure that unfixed bugs won't have Fix Version tag of
>>> the upcoming release.
>>> >
>>> >>
>>> >> Kenn
>>> >>
>>> >> On Fri, Oct 25, 2019, 14:16 Robert Bradshaw <ro...@google.com>
>>> wrote:
>>> >>>
>>> >>> I'm fine with that, but in that case we should have a priority for
>>> >>> release blockers, below which bugs get automatically bumped to the
>>> >>> next release (and which becomes the burndown list).
>>> >>>
>>> >>> On Fri, Oct 25, 2019 at 1:58 PM Kenneth Knowles <ke...@apache.org>
>>> wrote:
>>> >>> >
>>> >>> > My takeaway from this thread is that priorities should have a
>>> shared community intuition and/or policy around how they are treated, which
>>> could eventually be formalized into SLOs.
>>> >>> >
>>> >>> > At a practical level, I do think that build breaks are higher
>>> priority than release blockers. If you are on this thread but not looking
>>> at the PR, here is the verbiage I added about urgency:
>>> >>> >
>>> >>> > P0/Blocker: "A P0 issue is more urgent than simply blocking the
>>> next release"
>>> >>> > P1/Critical: "Most critical bugs should block release"
>>> >>> > P2/Major: "No special urgency is associated"
>>> >>> > ...
>>> >>> >
>>> >>> > Kenn
>>> >>> >
>>> >>> > On Fri, Oct 25, 2019 at 11:46 AM Robert Bradshaw <
>>> robertwb@google.com> wrote:
>>> >>> >>
>>> >>> >> We cut a release every 6 weeks, according to schedule, making it
>>> easy
>>> >>> >> to plan for, and the release manager typically sends out a warning
>>> >>> >> email to remind everyone. I don't think it makes sense to do that
>>> for
>>> >>> >> every ticket. Blockers should be reserved for things we really
>>> >>> >> shouldn't release without.
>>> >>> >>
>>> >>> >> On Fri, Oct 25, 2019 at 11:33 AM Pablo Estrada <
>>> pabloem@google.com> wrote:
>>> >>> >> >
>>> >>> >> > I mentioned on the PR that I had been using the 'blocker'
>>> priority along with the 'fix version' field to mark issues that I want to
>>> get in the release.
>>> >>> >> > Of course, this little practice of mine only matters much
>>> around release branch cutting time - and has been useful for me to track
>>> which things I want to ensure getting into the release / bump to the next
>>> /etc.
>>> >>> >> > I've also found it to be useful as a way to communicate with
>>> the release manager without having to sync directly.
>>> >>> >> >
>>> >>> >> > What would be a reasonable way to tell the release manager "I'd
>>> like to get this feature in. please talk to me if you're about to cut the
>>> branch" - that also uses the priorities appropriately? - and that allows
>>> the release manager to know when a fix version is "more optional" / "less
>>> optional"?
>>> >>> >> >
>>> >>> >> > On Wed, Oct 23, 2019 at 12:20 PM Kenneth Knowles <
>>> kenn@apache.org> wrote:
>>> >>> >> >>
>>> >>> >> >> I finally got around to writing some of this up. It is
>>> minimal. Feedback is welcome, especially if what I have written does not
>>> accurately represent the community's approach.
>>> >>> >> >>
>>> >>> >> >> https://github.com/apache/beam/pull/9862
>>> >>> >> >>
>>> >>> >> >> Kenn
>>> >>> >> >>
>>> >>> >> >> On Mon, Feb 11, 2019 at 3:21 PM Daniel Oliveira <
>>> danoliveira@google.com> wrote:
>>> >>> >> >>>
>>> >>> >> >>> Ah, sorry, I missed that Alex was just quoting from our Jira
>>> installation (didn't read his email closely enough). Also I wasn't aware
>>> about those pages on our website.
>>> >>> >> >>>
>>> >>> >> >>> Seeing as we do have definitions for our priorities, I guess
>>> my main request would be that they be made more discoverable somehow. I
>>> don't think the tooltips are reliable, and the pages on the website are
>>> informative, but hard to find. Since it feels a bit lazy to say "this isn't
>>> discoverable enough" without suggesting any improvements, I'd like to
>>> propose these two changes:
>>> >>> >> >>>
>>> >>> >> >>> 1. We should write a Beam Jira Guide with basic information
>>> about our Jira. I think the bug priorities should go in here, but also
>>> anything else we would want someone to know before filing any Jira issues,
>>> like how our components are organized or what the different issue types
>>> mean. This guide could either be written in the website or the wiki, but I
>>> think it should definitely be linked in
>>> https://beam.apache.org/contribute/ so that newcomers read it before
>>> getting their Jira account approved. The goal here being to have a
>>> reference for the basics of our Jira since at the moment it doesn't seem
>>> like we have anything for this.
>>> >>> >> >>>
>>> >>> >> >>> 2. The existing info on Post-commit and pre-commit policies
>>> doesn't seem very discoverable to someone monitoring the Pre/Post-commits.
>>> I've reported a handful of test-failures already and haven't seen this link
>>> mentioned much. We should try to find a way to funnel people towards this
>>> link when there's an issue, the same way we try to funnel people towards
>>> the contribution guide when they write a PR. As a note, while writing this
>>> email I remembered this link that someone gave me before (
>>> https://s.apache.org/beam-test-failure). That mentions the Post-commit
>>> policies page, so maybe it's just a matter of pasting that all over our
>>> Jenkins builds whenever we have a failing test?
>>> >>> >> >>>
>>> >>> >> >>> PS: I'm also definitely for SLOs, but I figure it's probably
>>> better discussed in a separate thread so I'm trying to stick to the subject
>>> of priority definitions.
>>> >>> >> >>>
>>> >>> >> >>> On Mon, Feb 11, 2019 at 9:17 AM Scott Wegner <
>>> scott@apache.org> wrote:
>>> >>> >> >>>>
>>> >>> >> >>>> Thanks for driving this discussion. I also was not aware of
>>> these existing definitions. Once we agree on the terms, let's add them to
>>> our Contributor Guide and start using them.
>>> >>> >> >>>>
>>> >>> >> >>>> +1 in general; I like both Alex and Kenn's definitions;
>>> Additional wordsmithing could be moved to a Pull Request. Can we make the
>>> definitions useful for both the person filing a bug, and the assignee, i.e.
>>> >>> >> >>>>
>>> >>> >> >>>> <Priority Level>: <Criteria for what types of issues should
>>> be assigned>. <Expectations for responding to a Priority Level issue>
>>> >>> >> >>>>
>>> >>> >> >>>> On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles <
>>> klk@google.com> wrote:
>>> >>> >> >>>>>
>>> >>> >> >>>>> The content that Alex posted* is the definition from our
>>> Jira installation anyhow.
>>> >>> >> >>>>>
>>> >>> >> >>>>> I just searched around, and there's
>>> https://community.atlassian.com/t5/Jira-questions/According-to-Jira-What-is-Blocker-Critical-Major-Minor-and/qaq-p/668774
>>> which makes clear that this is really user-defined, since Jira has many
>>> deployments with their own configs.
>>> >>> >> >>>>>
>>> >>> >> >>>>> I guess what I want to know about this thread is what
>>> action is being proposed?
>>> >>> >> >>>>>
>>> >>> >> >>>>> Previously, there was a thread that resulted in
>>> https://beam.apache.org/contribute/precommit-policies/ and
>>> https://beam.apache.org/contribute/postcommits-policies/. These have
>>> test failures and flakes as Critical. I agree with Alex that these should
>>> be Blocker. They disrupt the work of the entire community, so we need to
>>> drop everything and get green again.
>>> >>> >> >>>>>
>>> >>> >> >>>>> Other than that, I think what you - Daniel - are suggesting
>>> is that the definition might be best expressed as SLOs. I asked on
>>> user@infra.apache.org about how we could have those and the answer is
>>> the homebrew
>>> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/status/sla/jira/.
>>> If anyone has time to dig into that and see if it can work for us, that
>>> would be cool.
>>> >>> >> >>>>>
>>> >>> >> >>>>> Kenn
>>> >>> >> >>>>>
>>> >>> >> >>>>> *Blocker: Blocks development and/or testing work,
>>> production could not run
>>> >>> >> >>>>> Critical: Crashes, loss of data, severe memory leak.
>>> >>> >> >>>>> Major (Default): Major loss of function.
>>> >>> >> >>>>> Minor: Minor loss of function, or other problem where easy
>>> workaround is present.
>>> >>> >> >>>>> Trivial: Trivial Cosmetic problem like misspelt words or
>>> misaligned text.
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>> On Sun, Feb 10, 2019 at 7:20 PM Daniel Oliveira <
>>> danoliveira@google.com> wrote:
>>> >>> >> >>>>>>
>>> >>> >> >>>>>> Are there existing meanings for the priorities in Jira
>>> already? I wasn't able to find any info on either the Beam website or wiki
>>> about it, so I've just been prioritizing issues based on gut feeling. If
>>> not, I think having some well-defined priorities would be nice, at least
>>> for our test-failures, and especially if we wanna have some SLOs like I've
>>> seen being thrown about.
>>> >>> >> >>>>>>
>>> >>> >> >>>>>> On Fri, Feb 8, 2019 at 3:06 PM Kenneth Knowles <
>>> kenn@apache.org> wrote:
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> I've been thinking about this since working on the
>>> release. If I ignore the names I think:
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> P0: get paged, stop whatever you planned on doing, work
>>> late to fix
>>> >>> >> >>>>>>> P1: continually update everyone on status and shouldn't
>>> sit around unassigned
>>> >>> >> >>>>>>> P2: most things here; they can be planned or picked up by
>>> whomever
>>> >>> >> >>>>>>> P3: nice-to-have things, maybe starter tasks or lesser
>>> cleanup, but no driving need
>>> >>> >> >>>>>>> Sometimes there's P4 but I don't value it. Often P3 is a
>>> deprioritized thing from P2, so more involved and complex, while P4 is
>>> something easy and not important filed just as a reminder. Either way, they
>>> are both not on the main path of work.
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> I looked into it and the Jira priority scheme determines
>>> the set of priorities as well as the default. Ours is shared by 635
>>> projects. Probably worth keeping. The default priority is Major which would
>>> correspond with P2. We can expect the default to be where most issues end
>>> up.
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> P0 == Blocker: get paged, stop whatever you planned on
>>> doing, work late to fix
>>> >>> >> >>>>>>> P1 == Critical: continually update everyone on status and
>>> shouldn't sit around unassigned
>>> >>> >> >>>>>>> P0 == Major (default): most things here; they can be
>>> planned or picked up by whomever
>>> >>> >> >>>>>>> P3 == Minor: nice-to-have things, maybe starter tasks or
>>> lesser cleanup, but no driving need
>>> >>> >> >>>>>>> Trivial: Maybe this is attractive to newcomers as it
>>> makes it sound easy.
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> Kenn
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> On Thu, Feb 7, 2019 at 4:08 PM Alex Amato <
>>> ajamato@google.com> wrote:
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Hello Beam community, I was thinking about this and
>>> found some information to share/discuss. Would it be possible to confirm my
>>> thinking on this:
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> There are 5 priorities in the JIRA system today (tooltip
>>> link):
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Blocker Blocks development and/or testing work,
>>> production could not run
>>> >>> >> >>>>>>>> Critical Crashes, loss of data, severe memory leak.
>>> >>> >> >>>>>>>> Major Major loss of function.
>>> >>> >> >>>>>>>> Minor Minor loss of function, or other problem where
>>> easy workaround is present.
>>> >>> >> >>>>>>>> Trivial Cosmetic problem like misspelt words or
>>> misaligned text.
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> How should JIRA issues be prioritized for pre/post
>>> commit test failures?
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> I think Blocker
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> What about the flakey failures?
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Blocker as well?
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> How should non test issues be prioritized? (E.g. feature
>>> to implement or bugs not regularly breaking tests).
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> I suggest Minor, but its not clear how to distinguish
>>> between these.
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Below is my thinking: But I wanted to know what the
>>> Apache/Beam community generally thinks about these priorities.
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Blocker: Expect to be paged. Production systems are down.
>>> >>> >> >>>>>>>> Critical: Expect to be contacted by email or a bot to
>>> fix this.
>>> >>> >> >>>>>>>> Major: Some loss of function in the repository, can
>>> issues that need to be addressed soon are here.
>>> >>> >> >>>>>>>> Minor: Most issues will be here, important issues within
>>> this will get picked up and completed. FRs, bugs.
>>> >>> >> >>>>>>>> Trivial: Unlikely to be implemented, far too many issues
>>> in this category. FRs, bugs.
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Thanks for helping to clear this up
>>> >>> >> >>>>>>>> Alex
>>> >>> >> >>>>
>>> >>> >> >>>>
>>> >>> >> >>>>
>>> >>> >> >>>> --
>>> >>> >> >>>>
>>> >>> >> >>>>
>>> >>> >> >>>>
>>> >>> >> >>>>
>>> >>> >> >>>> Got feedback? tinyurl.com/swegner-feedback
>>>
>>

Re: JIRA priorities explaination

[Kenneth Knowles <ke...@apache.org>]

This is filed as https://issues.apache.org/jira/browse/INFRA-20231 which
should take place now.

On Fri, May 1, 2020 at 3:53 PM Ahmet Altay <al...@google.com> wrote:

> +1 sounds good to me. Oftentimes I confused the relative priorities of
> critical/blocker/major.
>
> On Fri, May 1, 2020 at 3:05 PM Tyson Hamilton <ty...@google.com> wrote:
>
>> Proposal sounds good to me! The tool tips will be fantastic.
>>
>> On Fri, May 1, 2020 at 3:03 PM Robert Bradshaw <ro...@google.com>
>> wrote:
>>
>>> On Fri, May 1, 2020 at 2:34 PM Kenneth Knowles <ke...@apache.org> wrote:
>>> >
>>> > Coming back to this thread (again!)
>>> >
>>> > I wrote up https://beam.apache.org/contribute/jira-priorities/ and
>>> https://beam.apache.org/contribute/release-blockers/ and I have had
>>> success communicating using these docs.
>>> >
>>> > However, some people get confused because the existing Jira priorities
>>> have tooltips that say something slightly different [1], or they just don't
>>> discover the site.
>>> >
>>> > Since Jira 7.6.0, I think, it is possible to customize this in Jira
>>> directly. [2]
>>> >
>>> > What do you think about changing from the default priorities to just
>>> P0, P1, etc, and using these tooltips that match the docs on the Beam site?
>>> >
>>> > P0 - Outage blocking development and/or testing work; requires
>>> immediate and continuous attention
>>> > P1 - Critical bug: data loss, total loss of function, or loss of
>>> testing signal due to test failures or flakiness
>>> > P2 - Default priority. Will be triaged and planned according to
>>> community practices.
>>> > P3 - Non-urgent bugs, features, and improvements
>>> > P4 - Trivial items, spelling errors, etc.
>>> >
>>> > This is related to the "Automation for Jira" thread. It was suggested
>>> to automatically lower priorities of stale bugs, to match reality and let
>>> us focus on the bugs that remain at higher priorities. I hope automatically
>>> moving "P2" to "P3" with these tooltips is nicer for people than
>>> automatically moving "Major" to "Minor". Using the default words seems like
>>> you are telling the user their problem is minor.
>>>
>>> That's a great point, +1.
>>>
>>> >
>>> > Kenn
>>> >
>>> > [1]
>>> https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels
>>> > [2] https://jira.atlassian.com/browse/JRASERVER-3821
>>> >
>>> > On Fri, Oct 25, 2019 at 4:25 PM Pablo Estrada <pa...@google.com>
>>> wrote:
>>> >>
>>> >> That SGTM
>>> >>
>>> >> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw <ro...@google.com>
>>> wrote:
>>> >>>
>>> >>> +1 to both.
>>> >>>
>>> >>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev <
>>> valentyn@google.com> wrote:
>>> >>> >
>>> >>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles <ke...@apache.org>
>>> wrote:
>>> >>> >>
>>> >>> >> Suppose, hypothetically, we say that if Fix Version is set, then
>>> P0/Blocker and P1/Critical block release and lower priorities get bumped.
>>> >>> >
>>> >>> >
>>> >>> > +1 to Kenn's suggestion.  In addition, we can discourage setting
>>> Fix version for non-critical issues before issues are fixed.
>>> >>> >
>>> >>> >>
>>> >>> >>
>>> >>> >> Most likely the release manager still pings and asks about all
>>> those before bumping. Which means that in effect they were part of the burn
>>> down and do block the release in the sense that they must be re-triaged
>>> away to the next release. I would prefer less work for the release manager
>>> and more emphasis on the default being nonblocking.
>>> >>> >>
>>> >>> >> One very different possibility is to ignore Fix Version on open
>>> bugs and use a different search query as the burndown, auto bump everything
>>> that didn't make it.
>>> >>> >
>>> >>> > This may create a situation where an issue will eventually be
>>> closed, but Fix Version not updated, and confuse the users who will rely
>>> "Fix Version" to  find which release actually fixes the issue. A pass over
>>> open bugs with a Fix Version set to next release (as currently done by a
>>> release manager) helps to make sure that unfixed bugs won't have Fix
>>> Version tag of the upcoming release.
>>> >>> >
>>> >>> >>
>>> >>> >> Kenn
>>> >>> >>
>>> >>> >> On Fri, Oct 25, 2019, 14:16 Robert Bradshaw <ro...@google.com>
>>> wrote:
>>> >>> >>>
>>> >>> >>> I'm fine with that, but in that case we should have a priority
>>> for
>>> >>> >>> release blockers, below which bugs get automatically bumped to
>>> the
>>> >>> >>> next release (and which becomes the burndown list).
>>> >>> >>>
>>> >>> >>> On Fri, Oct 25, 2019 at 1:58 PM Kenneth Knowles <ke...@apache.org>
>>> wrote:
>>> >>> >>> >
>>> >>> >>> > My takeaway from this thread is that priorities should have a
>>> shared community intuition and/or policy around how they are treated, which
>>> could eventually be formalized into SLOs.
>>> >>> >>> >
>>> >>> >>> > At a practical level, I do think that build breaks are higher
>>> priority than release blockers. If you are on this thread but not looking
>>> at the PR, here is the verbiage I added about urgency:
>>> >>> >>> >
>>> >>> >>> > P0/Blocker: "A P0 issue is more urgent than simply blocking
>>> the next release"
>>> >>> >>> > P1/Critical: "Most critical bugs should block release"
>>> >>> >>> > P2/Major: "No special urgency is associated"
>>> >>> >>> > ...
>>> >>> >>> >
>>> >>> >>> > Kenn
>>> >>> >>> >
>>> >>> >>> > On Fri, Oct 25, 2019 at 11:46 AM Robert Bradshaw <
>>> robertwb@google.com> wrote:
>>> >>> >>> >>
>>> >>> >>> >> We cut a release every 6 weeks, according to schedule, making
>>> it easy
>>> >>> >>> >> to plan for, and the release manager typically sends out a
>>> warning
>>> >>> >>> >> email to remind everyone. I don't think it makes sense to do
>>> that for
>>> >>> >>> >> every ticket. Blockers should be reserved for things we really
>>> >>> >>> >> shouldn't release without.
>>> >>> >>> >>
>>> >>> >>> >> On Fri, Oct 25, 2019 at 11:33 AM Pablo Estrada <
>>> pabloem@google.com> wrote:
>>> >>> >>> >> >
>>> >>> >>> >> > I mentioned on the PR that I had been using the 'blocker'
>>> priority along with the 'fix version' field to mark issues that I want to
>>> get in the release.
>>> >>> >>> >> > Of course, this little practice of mine only matters much
>>> around release branch cutting time - and has been useful for me to track
>>> which things I want to ensure getting into the release / bump to the next
>>> /etc.
>>> >>> >>> >> > I've also found it to be useful as a way to communicate
>>> with the release manager without having to sync directly.
>>> >>> >>> >> >
>>> >>> >>> >> > What would be a reasonable way to tell the release manager
>>> "I'd like to get this feature in. please talk to me if you're about to cut
>>> the branch" - that also uses the priorities appropriately? - and that
>>> allows the release manager to know when a fix version is "more optional" /
>>> "less optional"?
>>> >>> >>> >> >
>>> >>> >>> >> > On Wed, Oct 23, 2019 at 12:20 PM Kenneth Knowles <
>>> kenn@apache.org> wrote:
>>> >>> >>> >> >>
>>> >>> >>> >> >> I finally got around to writing some of this up. It is
>>> minimal. Feedback is welcome, especially if what I have written does not
>>> accurately represent the community's approach.
>>> >>> >>> >> >>
>>> >>> >>> >> >> https://github.com/apache/beam/pull/9862
>>> >>> >>> >> >>
>>> >>> >>> >> >> Kenn
>>> >>> >>> >> >>
>>> >>> >>> >> >> On Mon, Feb 11, 2019 at 3:21 PM Daniel Oliveira <
>>> danoliveira@google.com> wrote:
>>> >>> >>> >> >>>
>>> >>> >>> >> >>> Ah, sorry, I missed that Alex was just quoting from our
>>> Jira installation (didn't read his email closely enough). Also I wasn't
>>> aware about those pages on our website.
>>> >>> >>> >> >>>
>>> >>> >>> >> >>> Seeing as we do have definitions for our priorities, I
>>> guess my main request would be that they be made more discoverable somehow.
>>> I don't think the tooltips are reliable, and the pages on the website are
>>> informative, but hard to find. Since it feels a bit lazy to say "this isn't
>>> discoverable enough" without suggesting any improvements, I'd like to
>>> propose these two changes:
>>> >>> >>> >> >>>
>>> >>> >>> >> >>> 1. We should write a Beam Jira Guide with basic
>>> information about our Jira. I think the bug priorities should go in here,
>>> but also anything else we would want someone to know before filing any Jira
>>> issues, like how our components are organized or what the different issue
>>> types mean. This guide could either be written in the website or the wiki,
>>> but I think it should definitely be linked in
>>> https://beam.apache.org/contribute/ so that newcomers read it before
>>> getting their Jira account approved. The goal here being to have a
>>> reference for the basics of our Jira since at the moment it doesn't seem
>>> like we have anything for this.
>>> >>> >>> >> >>>
>>> >>> >>> >> >>> 2. The existing info on Post-commit and pre-commit
>>> policies doesn't seem very discoverable to someone monitoring the
>>> Pre/Post-commits. I've reported a handful of test-failures already and
>>> haven't seen this link mentioned much. We should try to find a way to
>>> funnel people towards this link when there's an issue, the same way we try
>>> to funnel people towards the contribution guide when they write a PR. As a
>>> note, while writing this email I remembered this link that someone gave me
>>> before (https://s.apache.org/beam-test-failure). That mentions the
>>> Post-commit policies page, so maybe it's just a matter of pasting that all
>>> over our Jenkins builds whenever we have a failing test?
>>> >>> >>> >> >>>
>>> >>> >>> >> >>> PS: I'm also definitely for SLOs, but I figure it's
>>> probably better discussed in a separate thread so I'm trying to stick to
>>> the subject of priority definitions.
>>> >>> >>> >> >>>
>>> >>> >>> >> >>> On Mon, Feb 11, 2019 at 9:17 AM Scott Wegner <
>>> scott@apache.org> wrote:
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>> Thanks for driving this discussion. I also was not aware
>>> of these existing definitions. Once we agree on the terms, let's add them
>>> to our Contributor Guide and start using them.
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>> +1 in general; I like both Alex and Kenn's definitions;
>>> Additional wordsmithing could be moved to a Pull Request. Can we make the
>>> definitions useful for both the person filing a bug, and the assignee, i.e.
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>> <Priority Level>: <Criteria for what types of issues
>>> should be assigned>. <Expectations for responding to a Priority Level issue>
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>> On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles <
>>> klk@google.com> wrote:
>>> >>> >>> >> >>>>>
>>> >>> >>> >> >>>>> The content that Alex posted* is the definition from
>>> our Jira installation anyhow.
>>> >>> >>> >> >>>>>
>>> >>> >>> >> >>>>> I just searched around, and there's
>>> https://community.atlassian.com/t5/Jira-questions/According-to-Jira-What-is-Blocker-Critical-Major-Minor-and/qaq-p/668774
>>> which makes clear that this is really user-defined, since Jira has many
>>> deployments with their own configs.
>>> >>> >>> >> >>>>>
>>> >>> >>> >> >>>>> I guess what I want to know about this thread is what
>>> action is being proposed?
>>> >>> >>> >> >>>>>
>>> >>> >>> >> >>>>> Previously, there was a thread that resulted in
>>> https://beam.apache.org/contribute/precommit-policies/ and
>>> https://beam.apache.org/contribute/postcommits-policies/. These have
>>> test failures and flakes as Critical. I agree with Alex that these should
>>> be Blocker. They disrupt the work of the entire community, so we need to
>>> drop everything and get green again.
>>> >>> >>> >> >>>>>
>>> >>> >>> >> >>>>> Other than that, I think what you - Daniel - are
>>> suggesting is that the definition might be best expressed as SLOs. I asked
>>> on user@infra.apache.org about how we could have those and the answer
>>> is the homebrew
>>> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/status/sla/jira/.
>>> If anyone has time to dig into that and see if it can work for us, that
>>> would be cool.
>>> >>> >>> >> >>>>>
>>> >>> >>> >> >>>>> Kenn
>>> >>> >>> >> >>>>>
>>> >>> >>> >> >>>>> *Blocker: Blocks development and/or testing work,
>>> production could not run
>>> >>> >>> >> >>>>> Critical: Crashes, loss of data, severe memory leak.
>>> >>> >>> >> >>>>> Major (Default): Major loss of function.
>>> >>> >>> >> >>>>> Minor: Minor loss of function, or other problem where
>>> easy workaround is present.
>>> >>> >>> >> >>>>> Trivial: Trivial Cosmetic problem like misspelt words
>>> or misaligned text.
>>> >>> >>> >> >>>>>
>>> >>> >>> >> >>>>>
>>> >>> >>> >> >>>>> On Sun, Feb 10, 2019 at 7:20 PM Daniel Oliveira <
>>> danoliveira@google.com> wrote:
>>> >>> >>> >> >>>>>>
>>> >>> >>> >> >>>>>> Are there existing meanings for the priorities in Jira
>>> already? I wasn't able to find any info on either the Beam website or wiki
>>> about it, so I've just been prioritizing issues based on gut feeling. If
>>> not, I think having some well-defined priorities would be nice, at least
>>> for our test-failures, and especially if we wanna have some SLOs like I've
>>> seen being thrown about.
>>> >>> >>> >> >>>>>>
>>> >>> >>> >> >>>>>> On Fri, Feb 8, 2019 at 3:06 PM Kenneth Knowles <
>>> kenn@apache.org> wrote:
>>> >>> >>> >> >>>>>>>
>>> >>> >>> >> >>>>>>> I've been thinking about this since working on the
>>> release. If I ignore the names I think:
>>> >>> >>> >> >>>>>>>
>>> >>> >>> >> >>>>>>> P0: get paged, stop whatever you planned on doing,
>>> work late to fix
>>> >>> >>> >> >>>>>>> P1: continually update everyone on status and
>>> shouldn't sit around unassigned
>>> >>> >>> >> >>>>>>> P2: most things here; they can be planned or picked
>>> up by whomever
>>> >>> >>> >> >>>>>>> P3: nice-to-have things, maybe starter tasks or
>>> lesser cleanup, but no driving need
>>> >>> >>> >> >>>>>>> Sometimes there's P4 but I don't value it. Often P3
>>> is a deprioritized thing from P2, so more involved and complex, while P4 is
>>> something easy and not important filed just as a reminder. Either way, they
>>> are both not on the main path of work.
>>> >>> >>> >> >>>>>>>
>>> >>> >>> >> >>>>>>> I looked into it and the Jira priority scheme
>>> determines the set of priorities as well as the default. Ours is shared by
>>> 635 projects. Probably worth keeping. The default priority is Major which
>>> would correspond with P2. We can expect the default to be where most issues
>>> end up.
>>> >>> >>> >> >>>>>>>
>>> >>> >>> >> >>>>>>> P0 == Blocker: get paged, stop whatever you planned
>>> on doing, work late to fix
>>> >>> >>> >> >>>>>>> P1 == Critical: continually update everyone on status
>>> and shouldn't sit around unassigned
>>> >>> >>> >> >>>>>>> P0 == Major (default): most things here; they can be
>>> planned or picked up by whomever
>>> >>> >>> >> >>>>>>> P3 == Minor: nice-to-have things, maybe starter tasks
>>> or lesser cleanup, but no driving need
>>> >>> >>> >> >>>>>>> Trivial: Maybe this is attractive to newcomers as it
>>> makes it sound easy.
>>> >>> >>> >> >>>>>>>
>>> >>> >>> >> >>>>>>> Kenn
>>> >>> >>> >> >>>>>>>
>>> >>> >>> >> >>>>>>> On Thu, Feb 7, 2019 at 4:08 PM Alex Amato <
>>> ajamato@google.com> wrote:
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> Hello Beam community, I was thinking about this and
>>> found some information to share/discuss. Would it be possible to confirm my
>>> thinking on this:
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> There are 5 priorities in the JIRA system today
>>> (tooltip link):
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> Blocker Blocks development and/or testing work,
>>> production could not run
>>> >>> >>> >> >>>>>>>> Critical Crashes, loss of data, severe memory leak.
>>> >>> >>> >> >>>>>>>> Major Major loss of function.
>>> >>> >>> >> >>>>>>>> Minor Minor loss of function, or other problem where
>>> easy workaround is present.
>>> >>> >>> >> >>>>>>>> Trivial Cosmetic problem like misspelt words or
>>> misaligned text.
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> How should JIRA issues be prioritized for pre/post
>>> commit test failures?
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> I think Blocker
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> What about the flakey failures?
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> Blocker as well?
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> How should non test issues be prioritized? (E.g.
>>> feature to implement or bugs not regularly breaking tests).
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> I suggest Minor, but its not clear how to
>>> distinguish between these.
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> Below is my thinking: But I wanted to know what the
>>> Apache/Beam community generally thinks about these priorities.
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> Blocker: Expect to be paged. Production systems are
>>> down.
>>> >>> >>> >> >>>>>>>> Critical: Expect to be contacted by email or a bot
>>> to fix this.
>>> >>> >>> >> >>>>>>>> Major: Some loss of function in the repository, can
>>> issues that need to be addressed soon are here.
>>> >>> >>> >> >>>>>>>> Minor: Most issues will be here, important issues
>>> within this will get picked up and completed. FRs, bugs.
>>> >>> >>> >> >>>>>>>> Trivial: Unlikely to be implemented, far too many
>>> issues in this category. FRs, bugs.
>>> >>> >>> >> >>>>>>>>
>>> >>> >>> >> >>>>>>>> Thanks for helping to clear this up
>>> >>> >>> >> >>>>>>>> Alex
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>> --
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>>
>>> >>> >>> >> >>>> Got feedback? tinyurl.com/swegner-feedback
>>>
>>

Re: JIRA priorities explaination

[Ahmet Altay <al...@google.com>]

+1 sounds good to me. Oftentimes I confused the relative priorities of
critical/blocker/major.

On Fri, May 1, 2020 at 3:05 PM Tyson Hamilton <ty...@google.com> wrote:

> Proposal sounds good to me! The tool tips will be fantastic.
>
> On Fri, May 1, 2020 at 3:03 PM Robert Bradshaw <ro...@google.com>
> wrote:
>
>> On Fri, May 1, 2020 at 2:34 PM Kenneth Knowles <ke...@apache.org> wrote:
>> >
>> > Coming back to this thread (again!)
>> >
>> > I wrote up https://beam.apache.org/contribute/jira-priorities/ and
>> https://beam.apache.org/contribute/release-blockers/ and I have had
>> success communicating using these docs.
>> >
>> > However, some people get confused because the existing Jira priorities
>> have tooltips that say something slightly different [1], or they just don't
>> discover the site.
>> >
>> > Since Jira 7.6.0, I think, it is possible to customize this in Jira
>> directly. [2]
>> >
>> > What do you think about changing from the default priorities to just
>> P0, P1, etc, and using these tooltips that match the docs on the Beam site?
>> >
>> > P0 - Outage blocking development and/or testing work; requires
>> immediate and continuous attention
>> > P1 - Critical bug: data loss, total loss of function, or loss of
>> testing signal due to test failures or flakiness
>> > P2 - Default priority. Will be triaged and planned according to
>> community practices.
>> > P3 - Non-urgent bugs, features, and improvements
>> > P4 - Trivial items, spelling errors, etc.
>> >
>> > This is related to the "Automation for Jira" thread. It was suggested
>> to automatically lower priorities of stale bugs, to match reality and let
>> us focus on the bugs that remain at higher priorities. I hope automatically
>> moving "P2" to "P3" with these tooltips is nicer for people than
>> automatically moving "Major" to "Minor". Using the default words seems like
>> you are telling the user their problem is minor.
>>
>> That's a great point, +1.
>>
>> >
>> > Kenn
>> >
>> > [1]
>> https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels
>> > [2] https://jira.atlassian.com/browse/JRASERVER-3821
>> >
>> > On Fri, Oct 25, 2019 at 4:25 PM Pablo Estrada <pa...@google.com>
>> wrote:
>> >>
>> >> That SGTM
>> >>
>> >> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw <ro...@google.com>
>> wrote:
>> >>>
>> >>> +1 to both.
>> >>>
>> >>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev <
>> valentyn@google.com> wrote:
>> >>> >
>> >>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles <ke...@apache.org>
>> wrote:
>> >>> >>
>> >>> >> Suppose, hypothetically, we say that if Fix Version is set, then
>> P0/Blocker and P1/Critical block release and lower priorities get bumped.
>> >>> >
>> >>> >
>> >>> > +1 to Kenn's suggestion.  In addition, we can discourage setting
>> Fix version for non-critical issues before issues are fixed.
>> >>> >
>> >>> >>
>> >>> >>
>> >>> >> Most likely the release manager still pings and asks about all
>> those before bumping. Which means that in effect they were part of the burn
>> down and do block the release in the sense that they must be re-triaged
>> away to the next release. I would prefer less work for the release manager
>> and more emphasis on the default being nonblocking.
>> >>> >>
>> >>> >> One very different possibility is to ignore Fix Version on open
>> bugs and use a different search query as the burndown, auto bump everything
>> that didn't make it.
>> >>> >
>> >>> > This may create a situation where an issue will eventually be
>> closed, but Fix Version not updated, and confuse the users who will rely
>> "Fix Version" to  find which release actually fixes the issue. A pass over
>> open bugs with a Fix Version set to next release (as currently done by a
>> release manager) helps to make sure that unfixed bugs won't have Fix
>> Version tag of the upcoming release.
>> >>> >
>> >>> >>
>> >>> >> Kenn
>> >>> >>
>> >>> >> On Fri, Oct 25, 2019, 14:16 Robert Bradshaw <ro...@google.com>
>> wrote:
>> >>> >>>
>> >>> >>> I'm fine with that, but in that case we should have a priority for
>> >>> >>> release blockers, below which bugs get automatically bumped to the
>> >>> >>> next release (and which becomes the burndown list).
>> >>> >>>
>> >>> >>> On Fri, Oct 25, 2019 at 1:58 PM Kenneth Knowles <ke...@apache.org>
>> wrote:
>> >>> >>> >
>> >>> >>> > My takeaway from this thread is that priorities should have a
>> shared community intuition and/or policy around how they are treated, which
>> could eventually be formalized into SLOs.
>> >>> >>> >
>> >>> >>> > At a practical level, I do think that build breaks are higher
>> priority than release blockers. If you are on this thread but not looking
>> at the PR, here is the verbiage I added about urgency:
>> >>> >>> >
>> >>> >>> > P0/Blocker: "A P0 issue is more urgent than simply blocking the
>> next release"
>> >>> >>> > P1/Critical: "Most critical bugs should block release"
>> >>> >>> > P2/Major: "No special urgency is associated"
>> >>> >>> > ...
>> >>> >>> >
>> >>> >>> > Kenn
>> >>> >>> >
>> >>> >>> > On Fri, Oct 25, 2019 at 11:46 AM Robert Bradshaw <
>> robertwb@google.com> wrote:
>> >>> >>> >>
>> >>> >>> >> We cut a release every 6 weeks, according to schedule, making
>> it easy
>> >>> >>> >> to plan for, and the release manager typically sends out a
>> warning
>> >>> >>> >> email to remind everyone. I don't think it makes sense to do
>> that for
>> >>> >>> >> every ticket. Blockers should be reserved for things we really
>> >>> >>> >> shouldn't release without.
>> >>> >>> >>
>> >>> >>> >> On Fri, Oct 25, 2019 at 11:33 AM Pablo Estrada <
>> pabloem@google.com> wrote:
>> >>> >>> >> >
>> >>> >>> >> > I mentioned on the PR that I had been using the 'blocker'
>> priority along with the 'fix version' field to mark issues that I want to
>> get in the release.
>> >>> >>> >> > Of course, this little practice of mine only matters much
>> around release branch cutting time - and has been useful for me to track
>> which things I want to ensure getting into the release / bump to the next
>> /etc.
>> >>> >>> >> > I've also found it to be useful as a way to communicate with
>> the release manager without having to sync directly.
>> >>> >>> >> >
>> >>> >>> >> > What would be a reasonable way to tell the release manager
>> "I'd like to get this feature in. please talk to me if you're about to cut
>> the branch" - that also uses the priorities appropriately? - and that
>> allows the release manager to know when a fix version is "more optional" /
>> "less optional"?
>> >>> >>> >> >
>> >>> >>> >> > On Wed, Oct 23, 2019 at 12:20 PM Kenneth Knowles <
>> kenn@apache.org> wrote:
>> >>> >>> >> >>
>> >>> >>> >> >> I finally got around to writing some of this up. It is
>> minimal. Feedback is welcome, especially if what I have written does not
>> accurately represent the community's approach.
>> >>> >>> >> >>
>> >>> >>> >> >> https://github.com/apache/beam/pull/9862
>> >>> >>> >> >>
>> >>> >>> >> >> Kenn
>> >>> >>> >> >>
>> >>> >>> >> >> On Mon, Feb 11, 2019 at 3:21 PM Daniel Oliveira <
>> danoliveira@google.com> wrote:
>> >>> >>> >> >>>
>> >>> >>> >> >>> Ah, sorry, I missed that Alex was just quoting from our
>> Jira installation (didn't read his email closely enough). Also I wasn't
>> aware about those pages on our website.
>> >>> >>> >> >>>
>> >>> >>> >> >>> Seeing as we do have definitions for our priorities, I
>> guess my main request would be that they be made more discoverable somehow.
>> I don't think the tooltips are reliable, and the pages on the website are
>> informative, but hard to find. Since it feels a bit lazy to say "this isn't
>> discoverable enough" without suggesting any improvements, I'd like to
>> propose these two changes:
>> >>> >>> >> >>>
>> >>> >>> >> >>> 1. We should write a Beam Jira Guide with basic
>> information about our Jira. I think the bug priorities should go in here,
>> but also anything else we would want someone to know before filing any Jira
>> issues, like how our components are organized or what the different issue
>> types mean. This guide could either be written in the website or the wiki,
>> but I think it should definitely be linked in
>> https://beam.apache.org/contribute/ so that newcomers read it before
>> getting their Jira account approved. The goal here being to have a
>> reference for the basics of our Jira since at the moment it doesn't seem
>> like we have anything for this.
>> >>> >>> >> >>>
>> >>> >>> >> >>> 2. The existing info on Post-commit and pre-commit
>> policies doesn't seem very discoverable to someone monitoring the
>> Pre/Post-commits. I've reported a handful of test-failures already and
>> haven't seen this link mentioned much. We should try to find a way to
>> funnel people towards this link when there's an issue, the same way we try
>> to funnel people towards the contribution guide when they write a PR. As a
>> note, while writing this email I remembered this link that someone gave me
>> before (https://s.apache.org/beam-test-failure). That mentions the
>> Post-commit policies page, so maybe it's just a matter of pasting that all
>> over our Jenkins builds whenever we have a failing test?
>> >>> >>> >> >>>
>> >>> >>> >> >>> PS: I'm also definitely for SLOs, but I figure it's
>> probably better discussed in a separate thread so I'm trying to stick to
>> the subject of priority definitions.
>> >>> >>> >> >>>
>> >>> >>> >> >>> On Mon, Feb 11, 2019 at 9:17 AM Scott Wegner <
>> scott@apache.org> wrote:
>> >>> >>> >> >>>>
>> >>> >>> >> >>>> Thanks for driving this discussion. I also was not aware
>> of these existing definitions. Once we agree on the terms, let's add them
>> to our Contributor Guide and start using them.
>> >>> >>> >> >>>>
>> >>> >>> >> >>>> +1 in general; I like both Alex and Kenn's definitions;
>> Additional wordsmithing could be moved to a Pull Request. Can we make the
>> definitions useful for both the person filing a bug, and the assignee, i.e.
>> >>> >>> >> >>>>
>> >>> >>> >> >>>> <Priority Level>: <Criteria for what types of issues
>> should be assigned>. <Expectations for responding to a Priority Level issue>
>> >>> >>> >> >>>>
>> >>> >>> >> >>>> On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles <
>> klk@google.com> wrote:
>> >>> >>> >> >>>>>
>> >>> >>> >> >>>>> The content that Alex posted* is the definition from our
>> Jira installation anyhow.
>> >>> >>> >> >>>>>
>> >>> >>> >> >>>>> I just searched around, and there's
>> https://community.atlassian.com/t5/Jira-questions/According-to-Jira-What-is-Blocker-Critical-Major-Minor-and/qaq-p/668774
>> which makes clear that this is really user-defined, since Jira has many
>> deployments with their own configs.
>> >>> >>> >> >>>>>
>> >>> >>> >> >>>>> I guess what I want to know about this thread is what
>> action is being proposed?
>> >>> >>> >> >>>>>
>> >>> >>> >> >>>>> Previously, there was a thread that resulted in
>> https://beam.apache.org/contribute/precommit-policies/ and
>> https://beam.apache.org/contribute/postcommits-policies/. These have
>> test failures and flakes as Critical. I agree with Alex that these should
>> be Blocker. They disrupt the work of the entire community, so we need to
>> drop everything and get green again.
>> >>> >>> >> >>>>>
>> >>> >>> >> >>>>> Other than that, I think what you - Daniel - are
>> suggesting is that the definition might be best expressed as SLOs. I asked
>> on user@infra.apache.org about how we could have those and the answer is
>> the homebrew
>> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/status/sla/jira/.
>> If anyone has time to dig into that and see if it can work for us, that
>> would be cool.
>> >>> >>> >> >>>>>
>> >>> >>> >> >>>>> Kenn
>> >>> >>> >> >>>>>
>> >>> >>> >> >>>>> *Blocker: Blocks development and/or testing work,
>> production could not run
>> >>> >>> >> >>>>> Critical: Crashes, loss of data, severe memory leak.
>> >>> >>> >> >>>>> Major (Default): Major loss of function.
>> >>> >>> >> >>>>> Minor: Minor loss of function, or other problem where
>> easy workaround is present.
>> >>> >>> >> >>>>> Trivial: Trivial Cosmetic problem like misspelt words or
>> misaligned text.
>> >>> >>> >> >>>>>
>> >>> >>> >> >>>>>
>> >>> >>> >> >>>>> On Sun, Feb 10, 2019 at 7:20 PM Daniel Oliveira <
>> danoliveira@google.com> wrote:
>> >>> >>> >> >>>>>>
>> >>> >>> >> >>>>>> Are there existing meanings for the priorities in Jira
>> already? I wasn't able to find any info on either the Beam website or wiki
>> about it, so I've just been prioritizing issues based on gut feeling. If
>> not, I think having some well-defined priorities would be nice, at least
>> for our test-failures, and especially if we wanna have some SLOs like I've
>> seen being thrown about.
>> >>> >>> >> >>>>>>
>> >>> >>> >> >>>>>> On Fri, Feb 8, 2019 at 3:06 PM Kenneth Knowles <
>> kenn@apache.org> wrote:
>> >>> >>> >> >>>>>>>
>> >>> >>> >> >>>>>>> I've been thinking about this since working on the
>> release. If I ignore the names I think:
>> >>> >>> >> >>>>>>>
>> >>> >>> >> >>>>>>> P0: get paged, stop whatever you planned on doing,
>> work late to fix
>> >>> >>> >> >>>>>>> P1: continually update everyone on status and
>> shouldn't sit around unassigned
>> >>> >>> >> >>>>>>> P2: most things here; they can be planned or picked up
>> by whomever
>> >>> >>> >> >>>>>>> P3: nice-to-have things, maybe starter tasks or lesser
>> cleanup, but no driving need
>> >>> >>> >> >>>>>>> Sometimes there's P4 but I don't value it. Often P3 is
>> a deprioritized thing from P2, so more involved and complex, while P4 is
>> something easy and not important filed just as a reminder. Either way, they
>> are both not on the main path of work.
>> >>> >>> >> >>>>>>>
>> >>> >>> >> >>>>>>> I looked into it and the Jira priority scheme
>> determines the set of priorities as well as the default. Ours is shared by
>> 635 projects. Probably worth keeping. The default priority is Major which
>> would correspond with P2. We can expect the default to be where most issues
>> end up.
>> >>> >>> >> >>>>>>>
>> >>> >>> >> >>>>>>> P0 == Blocker: get paged, stop whatever you planned on
>> doing, work late to fix
>> >>> >>> >> >>>>>>> P1 == Critical: continually update everyone on status
>> and shouldn't sit around unassigned
>> >>> >>> >> >>>>>>> P0 == Major (default): most things here; they can be
>> planned or picked up by whomever
>> >>> >>> >> >>>>>>> P3 == Minor: nice-to-have things, maybe starter tasks
>> or lesser cleanup, but no driving need
>> >>> >>> >> >>>>>>> Trivial: Maybe this is attractive to newcomers as it
>> makes it sound easy.
>> >>> >>> >> >>>>>>>
>> >>> >>> >> >>>>>>> Kenn
>> >>> >>> >> >>>>>>>
>> >>> >>> >> >>>>>>> On Thu, Feb 7, 2019 at 4:08 PM Alex Amato <
>> ajamato@google.com> wrote:
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> Hello Beam community, I was thinking about this and
>> found some information to share/discuss. Would it be possible to confirm my
>> thinking on this:
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> There are 5 priorities in the JIRA system today
>> (tooltip link):
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> Blocker Blocks development and/or testing work,
>> production could not run
>> >>> >>> >> >>>>>>>> Critical Crashes, loss of data, severe memory leak.
>> >>> >>> >> >>>>>>>> Major Major loss of function.
>> >>> >>> >> >>>>>>>> Minor Minor loss of function, or other problem where
>> easy workaround is present.
>> >>> >>> >> >>>>>>>> Trivial Cosmetic problem like misspelt words or
>> misaligned text.
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> How should JIRA issues be prioritized for pre/post
>> commit test failures?
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> I think Blocker
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> What about the flakey failures?
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> Blocker as well?
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> How should non test issues be prioritized? (E.g.
>> feature to implement or bugs not regularly breaking tests).
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> I suggest Minor, but its not clear how to distinguish
>> between these.
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> Below is my thinking: But I wanted to know what the
>> Apache/Beam community generally thinks about these priorities.
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> Blocker: Expect to be paged. Production systems are
>> down.
>> >>> >>> >> >>>>>>>> Critical: Expect to be contacted by email or a bot to
>> fix this.
>> >>> >>> >> >>>>>>>> Major: Some loss of function in the repository, can
>> issues that need to be addressed soon are here.
>> >>> >>> >> >>>>>>>> Minor: Most issues will be here, important issues
>> within this will get picked up and completed. FRs, bugs.
>> >>> >>> >> >>>>>>>> Trivial: Unlikely to be implemented, far too many
>> issues in this category. FRs, bugs.
>> >>> >>> >> >>>>>>>>
>> >>> >>> >> >>>>>>>> Thanks for helping to clear this up
>> >>> >>> >> >>>>>>>> Alex
>> >>> >>> >> >>>>
>> >>> >>> >> >>>>
>> >>> >>> >> >>>>
>> >>> >>> >> >>>> --
>> >>> >>> >> >>>>
>> >>> >>> >> >>>>
>> >>> >>> >> >>>>
>> >>> >>> >> >>>>
>> >>> >>> >> >>>> Got feedback? tinyurl.com/swegner-feedback
>>
>

Re: JIRA priorities explaination

[Tyson Hamilton <ty...@google.com>]

Proposal sounds good to me! The tool tips will be fantastic.

On Fri, May 1, 2020 at 3:03 PM Robert Bradshaw <ro...@google.com> wrote:

> On Fri, May 1, 2020 at 2:34 PM Kenneth Knowles <ke...@apache.org> wrote:
> >
> > Coming back to this thread (again!)
> >
> > I wrote up https://beam.apache.org/contribute/jira-priorities/ and
> https://beam.apache.org/contribute/release-blockers/ and I have had
> success communicating using these docs.
> >
> > However, some people get confused because the existing Jira priorities
> have tooltips that say something slightly different [1], or they just don't
> discover the site.
> >
> > Since Jira 7.6.0, I think, it is possible to customize this in Jira
> directly. [2]
> >
> > What do you think about changing from the default priorities to just P0,
> P1, etc, and using these tooltips that match the docs on the Beam site?
> >
> > P0 - Outage blocking development and/or testing work; requires immediate
> and continuous attention
> > P1 - Critical bug: data loss, total loss of function, or loss of testing
> signal due to test failures or flakiness
> > P2 - Default priority. Will be triaged and planned according to
> community practices.
> > P3 - Non-urgent bugs, features, and improvements
> > P4 - Trivial items, spelling errors, etc.
> >
> > This is related to the "Automation for Jira" thread. It was suggested to
> automatically lower priorities of stale bugs, to match reality and let us
> focus on the bugs that remain at higher priorities. I hope automatically
> moving "P2" to "P3" with these tooltips is nicer for people than
> automatically moving "Major" to "Minor". Using the default words seems like
> you are telling the user their problem is minor.
>
> That's a great point, +1.
>
> >
> > Kenn
> >
> > [1]
> https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels
> > [2] https://jira.atlassian.com/browse/JRASERVER-3821
> >
> > On Fri, Oct 25, 2019 at 4:25 PM Pablo Estrada <pa...@google.com>
> wrote:
> >>
> >> That SGTM
> >>
> >> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw <ro...@google.com>
> wrote:
> >>>
> >>> +1 to both.
> >>>
> >>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev <
> valentyn@google.com> wrote:
> >>> >
> >>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles <ke...@apache.org>
> wrote:
> >>> >>
> >>> >> Suppose, hypothetically, we say that if Fix Version is set, then
> P0/Blocker and P1/Critical block release and lower priorities get bumped.
> >>> >
> >>> >
> >>> > +1 to Kenn's suggestion.  In addition, we can discourage setting Fix
> version for non-critical issues before issues are fixed.
> >>> >
> >>> >>
> >>> >>
> >>> >> Most likely the release manager still pings and asks about all
> those before bumping. Which means that in effect they were part of the burn
> down and do block the release in the sense that they must be re-triaged
> away to the next release. I would prefer less work for the release manager
> and more emphasis on the default being nonblocking.
> >>> >>
> >>> >> One very different possibility is to ignore Fix Version on open
> bugs and use a different search query as the burndown, auto bump everything
> that didn't make it.
> >>> >
> >>> > This may create a situation where an issue will eventually be
> closed, but Fix Version not updated, and confuse the users who will rely
> "Fix Version" to  find which release actually fixes the issue. A pass over
> open bugs with a Fix Version set to next release (as currently done by a
> release manager) helps to make sure that unfixed bugs won't have Fix
> Version tag of the upcoming release.
> >>> >
> >>> >>
> >>> >> Kenn
> >>> >>
> >>> >> On Fri, Oct 25, 2019, 14:16 Robert Bradshaw <ro...@google.com>
> wrote:
> >>> >>>
> >>> >>> I'm fine with that, but in that case we should have a priority for
> >>> >>> release blockers, below which bugs get automatically bumped to the
> >>> >>> next release (and which becomes the burndown list).
> >>> >>>
> >>> >>> On Fri, Oct 25, 2019 at 1:58 PM Kenneth Knowles <ke...@apache.org>
> wrote:
> >>> >>> >
> >>> >>> > My takeaway from this thread is that priorities should have a
> shared community intuition and/or policy around how they are treated, which
> could eventually be formalized into SLOs.
> >>> >>> >
> >>> >>> > At a practical level, I do think that build breaks are higher
> priority than release blockers. If you are on this thread but not looking
> at the PR, here is the verbiage I added about urgency:
> >>> >>> >
> >>> >>> > P0/Blocker: "A P0 issue is more urgent than simply blocking the
> next release"
> >>> >>> > P1/Critical: "Most critical bugs should block release"
> >>> >>> > P2/Major: "No special urgency is associated"
> >>> >>> > ...
> >>> >>> >
> >>> >>> > Kenn
> >>> >>> >
> >>> >>> > On Fri, Oct 25, 2019 at 11:46 AM Robert Bradshaw <
> robertwb@google.com> wrote:
> >>> >>> >>
> >>> >>> >> We cut a release every 6 weeks, according to schedule, making
> it easy
> >>> >>> >> to plan for, and the release manager typically sends out a
> warning
> >>> >>> >> email to remind everyone. I don't think it makes sense to do
> that for
> >>> >>> >> every ticket. Blockers should be reserved for things we really
> >>> >>> >> shouldn't release without.
> >>> >>> >>
> >>> >>> >> On Fri, Oct 25, 2019 at 11:33 AM Pablo Estrada <
> pabloem@google.com> wrote:
> >>> >>> >> >
> >>> >>> >> > I mentioned on the PR that I had been using the 'blocker'
> priority along with the 'fix version' field to mark issues that I want to
> get in the release.
> >>> >>> >> > Of course, this little practice of mine only matters much
> around release branch cutting time - and has been useful for me to track
> which things I want to ensure getting into the release / bump to the next
> /etc.
> >>> >>> >> > I've also found it to be useful as a way to communicate with
> the release manager without having to sync directly.
> >>> >>> >> >
> >>> >>> >> > What would be a reasonable way to tell the release manager
> "I'd like to get this feature in. please talk to me if you're about to cut
> the branch" - that also uses the priorities appropriately? - and that
> allows the release manager to know when a fix version is "more optional" /
> "less optional"?
> >>> >>> >> >
> >>> >>> >> > On Wed, Oct 23, 2019 at 12:20 PM Kenneth Knowles <
> kenn@apache.org> wrote:
> >>> >>> >> >>
> >>> >>> >> >> I finally got around to writing some of this up. It is
> minimal. Feedback is welcome, especially if what I have written does not
> accurately represent the community's approach.
> >>> >>> >> >>
> >>> >>> >> >> https://github.com/apache/beam/pull/9862
> >>> >>> >> >>
> >>> >>> >> >> Kenn
> >>> >>> >> >>
> >>> >>> >> >> On Mon, Feb 11, 2019 at 3:21 PM Daniel Oliveira <
> danoliveira@google.com> wrote:
> >>> >>> >> >>>
> >>> >>> >> >>> Ah, sorry, I missed that Alex was just quoting from our
> Jira installation (didn't read his email closely enough). Also I wasn't
> aware about those pages on our website.
> >>> >>> >> >>>
> >>> >>> >> >>> Seeing as we do have definitions for our priorities, I
> guess my main request would be that they be made more discoverable somehow.
> I don't think the tooltips are reliable, and the pages on the website are
> informative, but hard to find. Since it feels a bit lazy to say "this isn't
> discoverable enough" without suggesting any improvements, I'd like to
> propose these two changes:
> >>> >>> >> >>>
> >>> >>> >> >>> 1. We should write a Beam Jira Guide with basic information
> about our Jira. I think the bug priorities should go in here, but also
> anything else we would want someone to know before filing any Jira issues,
> like how our components are organized or what the different issue types
> mean. This guide could either be written in the website or the wiki, but I
> think it should definitely be linked in
> https://beam.apache.org/contribute/ so that newcomers read it before
> getting their Jira account approved. The goal here being to have a
> reference for the basics of our Jira since at the moment it doesn't seem
> like we have anything for this.
> >>> >>> >> >>>
> >>> >>> >> >>> 2. The existing info on Post-commit and pre-commit policies
> doesn't seem very discoverable to someone monitoring the Pre/Post-commits.
> I've reported a handful of test-failures already and haven't seen this link
> mentioned much. We should try to find a way to funnel people towards this
> link when there's an issue, the same way we try to funnel people towards
> the contribution guide when they write a PR. As a note, while writing this
> email I remembered this link that someone gave me before (
> https://s.apache.org/beam-test-failure). That mentions the Post-commit
> policies page, so maybe it's just a matter of pasting that all over our
> Jenkins builds whenever we have a failing test?
> >>> >>> >> >>>
> >>> >>> >> >>> PS: I'm also definitely for SLOs, but I figure it's
> probably better discussed in a separate thread so I'm trying to stick to
> the subject of priority definitions.
> >>> >>> >> >>>
> >>> >>> >> >>> On Mon, Feb 11, 2019 at 9:17 AM Scott Wegner <
> scott@apache.org> wrote:
> >>> >>> >> >>>>
> >>> >>> >> >>>> Thanks for driving this discussion. I also was not aware
> of these existing definitions. Once we agree on the terms, let's add them
> to our Contributor Guide and start using them.
> >>> >>> >> >>>>
> >>> >>> >> >>>> +1 in general; I like both Alex and Kenn's definitions;
> Additional wordsmithing could be moved to a Pull Request. Can we make the
> definitions useful for both the person filing a bug, and the assignee, i.e.
> >>> >>> >> >>>>
> >>> >>> >> >>>> <Priority Level>: <Criteria for what types of issues
> should be assigned>. <Expectations for responding to a Priority Level issue>
> >>> >>> >> >>>>
> >>> >>> >> >>>> On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles <
> klk@google.com> wrote:
> >>> >>> >> >>>>>
> >>> >>> >> >>>>> The content that Alex posted* is the definition from our
> Jira installation anyhow.
> >>> >>> >> >>>>>
> >>> >>> >> >>>>> I just searched around, and there's
> https://community.atlassian.com/t5/Jira-questions/According-to-Jira-What-is-Blocker-Critical-Major-Minor-and/qaq-p/668774
> which makes clear that this is really user-defined, since Jira has many
> deployments with their own configs.
> >>> >>> >> >>>>>
> >>> >>> >> >>>>> I guess what I want to know about this thread is what
> action is being proposed?
> >>> >>> >> >>>>>
> >>> >>> >> >>>>> Previously, there was a thread that resulted in
> https://beam.apache.org/contribute/precommit-policies/ and
> https://beam.apache.org/contribute/postcommits-policies/. These have test
> failures and flakes as Critical. I agree with Alex that these should be
> Blocker. They disrupt the work of the entire community, so we need to drop
> everything and get green again.
> >>> >>> >> >>>>>
> >>> >>> >> >>>>> Other than that, I think what you - Daniel - are
> suggesting is that the definition might be best expressed as SLOs. I asked
> on user@infra.apache.org about how we could have those and the answer is
> the homebrew
> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/status/sla/jira/.
> If anyone has time to dig into that and see if it can work for us, that
> would be cool.
> >>> >>> >> >>>>>
> >>> >>> >> >>>>> Kenn
> >>> >>> >> >>>>>
> >>> >>> >> >>>>> *Blocker: Blocks development and/or testing work,
> production could not run
> >>> >>> >> >>>>> Critical: Crashes, loss of data, severe memory leak.
> >>> >>> >> >>>>> Major (Default): Major loss of function.
> >>> >>> >> >>>>> Minor: Minor loss of function, or other problem where
> easy workaround is present.
> >>> >>> >> >>>>> Trivial: Trivial Cosmetic problem like misspelt words or
> misaligned text.
> >>> >>> >> >>>>>
> >>> >>> >> >>>>>
> >>> >>> >> >>>>> On Sun, Feb 10, 2019 at 7:20 PM Daniel Oliveira <
> danoliveira@google.com> wrote:
> >>> >>> >> >>>>>>
> >>> >>> >> >>>>>> Are there existing meanings for the priorities in Jira
> already? I wasn't able to find any info on either the Beam website or wiki
> about it, so I've just been prioritizing issues based on gut feeling. If
> not, I think having some well-defined priorities would be nice, at least
> for our test-failures, and especially if we wanna have some SLOs like I've
> seen being thrown about.
> >>> >>> >> >>>>>>
> >>> >>> >> >>>>>> On Fri, Feb 8, 2019 at 3:06 PM Kenneth Knowles <
> kenn@apache.org> wrote:
> >>> >>> >> >>>>>>>
> >>> >>> >> >>>>>>> I've been thinking about this since working on the
> release. If I ignore the names I think:
> >>> >>> >> >>>>>>>
> >>> >>> >> >>>>>>> P0: get paged, stop whatever you planned on doing, work
> late to fix
> >>> >>> >> >>>>>>> P1: continually update everyone on status and shouldn't
> sit around unassigned
> >>> >>> >> >>>>>>> P2: most things here; they can be planned or picked up
> by whomever
> >>> >>> >> >>>>>>> P3: nice-to-have things, maybe starter tasks or lesser
> cleanup, but no driving need
> >>> >>> >> >>>>>>> Sometimes there's P4 but I don't value it. Often P3 is
> a deprioritized thing from P2, so more involved and complex, while P4 is
> something easy and not important filed just as a reminder. Either way, they
> are both not on the main path of work.
> >>> >>> >> >>>>>>>
> >>> >>> >> >>>>>>> I looked into it and the Jira priority scheme
> determines the set of priorities as well as the default. Ours is shared by
> 635 projects. Probably worth keeping. The default priority is Major which
> would correspond with P2. We can expect the default to be where most issues
> end up.
> >>> >>> >> >>>>>>>
> >>> >>> >> >>>>>>> P0 == Blocker: get paged, stop whatever you planned on
> doing, work late to fix
> >>> >>> >> >>>>>>> P1 == Critical: continually update everyone on status
> and shouldn't sit around unassigned
> >>> >>> >> >>>>>>> P0 == Major (default): most things here; they can be
> planned or picked up by whomever
> >>> >>> >> >>>>>>> P3 == Minor: nice-to-have things, maybe starter tasks
> or lesser cleanup, but no driving need
> >>> >>> >> >>>>>>> Trivial: Maybe this is attractive to newcomers as it
> makes it sound easy.
> >>> >>> >> >>>>>>>
> >>> >>> >> >>>>>>> Kenn
> >>> >>> >> >>>>>>>
> >>> >>> >> >>>>>>> On Thu, Feb 7, 2019 at 4:08 PM Alex Amato <
> ajamato@google.com> wrote:
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> Hello Beam community, I was thinking about this and
> found some information to share/discuss. Would it be possible to confirm my
> thinking on this:
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> There are 5 priorities in the JIRA system today
> (tooltip link):
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> Blocker Blocks development and/or testing work,
> production could not run
> >>> >>> >> >>>>>>>> Critical Crashes, loss of data, severe memory leak.
> >>> >>> >> >>>>>>>> Major Major loss of function.
> >>> >>> >> >>>>>>>> Minor Minor loss of function, or other problem where
> easy workaround is present.
> >>> >>> >> >>>>>>>> Trivial Cosmetic problem like misspelt words or
> misaligned text.
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> How should JIRA issues be prioritized for pre/post
> commit test failures?
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> I think Blocker
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> What about the flakey failures?
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> Blocker as well?
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> How should non test issues be prioritized? (E.g.
> feature to implement or bugs not regularly breaking tests).
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> I suggest Minor, but its not clear how to distinguish
> between these.
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> Below is my thinking: But I wanted to know what the
> Apache/Beam community generally thinks about these priorities.
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> Blocker: Expect to be paged. Production systems are
> down.
> >>> >>> >> >>>>>>>> Critical: Expect to be contacted by email or a bot to
> fix this.
> >>> >>> >> >>>>>>>> Major: Some loss of function in the repository, can
> issues that need to be addressed soon are here.
> >>> >>> >> >>>>>>>> Minor: Most issues will be here, important issues
> within this will get picked up and completed. FRs, bugs.
> >>> >>> >> >>>>>>>> Trivial: Unlikely to be implemented, far too many
> issues in this category. FRs, bugs.
> >>> >>> >> >>>>>>>>
> >>> >>> >> >>>>>>>> Thanks for helping to clear this up
> >>> >>> >> >>>>>>>> Alex
> >>> >>> >> >>>>
> >>> >>> >> >>>>
> >>> >>> >> >>>>
> >>> >>> >> >>>> --
> >>> >>> >> >>>>
> >>> >>> >> >>>>
> >>> >>> >> >>>>
> >>> >>> >> >>>>
> >>> >>> >> >>>> Got feedback? tinyurl.com/swegner-feedback
>

Re: JIRA priorities explaination

[Robert Bradshaw <ro...@google.com>]

On Fri, May 1, 2020 at 2:34 PM Kenneth Knowles <ke...@apache.org> wrote:
>
> Coming back to this thread (again!)
>
> I wrote up https://beam.apache.org/contribute/jira-priorities/ and https://beam.apache.org/contribute/release-blockers/ and I have had success communicating using these docs.
>
> However, some people get confused because the existing Jira priorities have tooltips that say something slightly different [1], or they just don't discover the site.
>
> Since Jira 7.6.0, I think, it is possible to customize this in Jira directly. [2]
>
> What do you think about changing from the default priorities to just P0, P1, etc, and using these tooltips that match the docs on the Beam site?
>
> P0 - Outage blocking development and/or testing work; requires immediate and continuous attention
> P1 - Critical bug: data loss, total loss of function, or loss of testing signal due to test failures or flakiness
> P2 - Default priority. Will be triaged and planned according to community practices.
> P3 - Non-urgent bugs, features, and improvements
> P4 - Trivial items, spelling errors, etc.
>
> This is related to the "Automation for Jira" thread. It was suggested to automatically lower priorities of stale bugs, to match reality and let us focus on the bugs that remain at higher priorities. I hope automatically moving "P2" to "P3" with these tooltips is nicer for people than automatically moving "Major" to "Minor". Using the default words seems like you are telling the user their problem is minor.

That's a great point, +1.

>
> Kenn
>
> [1] https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels
> [2] https://jira.atlassian.com/browse/JRASERVER-3821
>
> On Fri, Oct 25, 2019 at 4:25 PM Pablo Estrada <pa...@google.com> wrote:
>>
>> That SGTM
>>
>> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw <ro...@google.com> wrote:
>>>
>>> +1 to both.
>>>
>>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev <va...@google.com> wrote:
>>> >
>>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles <ke...@apache.org> wrote:
>>> >>
>>> >> Suppose, hypothetically, we say that if Fix Version is set, then P0/Blocker and P1/Critical block release and lower priorities get bumped.
>>> >
>>> >
>>> > +1 to Kenn's suggestion.  In addition, we can discourage setting Fix version for non-critical issues before issues are fixed.
>>> >
>>> >>
>>> >>
>>> >> Most likely the release manager still pings and asks about all those before bumping. Which means that in effect they were part of the burn down and do block the release in the sense that they must be re-triaged away to the next release. I would prefer less work for the release manager and more emphasis on the default being nonblocking.
>>> >>
>>> >> One very different possibility is to ignore Fix Version on open bugs and use a different search query as the burndown, auto bump everything that didn't make it.
>>> >
>>> > This may create a situation where an issue will eventually be closed, but Fix Version not updated, and confuse the users who will rely "Fix Version" to  find which release actually fixes the issue. A pass over open bugs with a Fix Version set to next release (as currently done by a release manager) helps to make sure that unfixed bugs won't have Fix Version tag of the upcoming release.
>>> >
>>> >>
>>> >> Kenn
>>> >>
>>> >> On Fri, Oct 25, 2019, 14:16 Robert Bradshaw <ro...@google.com> wrote:
>>> >>>
>>> >>> I'm fine with that, but in that case we should have a priority for
>>> >>> release blockers, below which bugs get automatically bumped to the
>>> >>> next release (and which becomes the burndown list).
>>> >>>
>>> >>> On Fri, Oct 25, 2019 at 1:58 PM Kenneth Knowles <ke...@apache.org> wrote:
>>> >>> >
>>> >>> > My takeaway from this thread is that priorities should have a shared community intuition and/or policy around how they are treated, which could eventually be formalized into SLOs.
>>> >>> >
>>> >>> > At a practical level, I do think that build breaks are higher priority than release blockers. If you are on this thread but not looking at the PR, here is the verbiage I added about urgency:
>>> >>> >
>>> >>> > P0/Blocker: "A P0 issue is more urgent than simply blocking the next release"
>>> >>> > P1/Critical: "Most critical bugs should block release"
>>> >>> > P2/Major: "No special urgency is associated"
>>> >>> > ...
>>> >>> >
>>> >>> > Kenn
>>> >>> >
>>> >>> > On Fri, Oct 25, 2019 at 11:46 AM Robert Bradshaw <ro...@google.com> wrote:
>>> >>> >>
>>> >>> >> We cut a release every 6 weeks, according to schedule, making it easy
>>> >>> >> to plan for, and the release manager typically sends out a warning
>>> >>> >> email to remind everyone. I don't think it makes sense to do that for
>>> >>> >> every ticket. Blockers should be reserved for things we really
>>> >>> >> shouldn't release without.
>>> >>> >>
>>> >>> >> On Fri, Oct 25, 2019 at 11:33 AM Pablo Estrada <pa...@google.com> wrote:
>>> >>> >> >
>>> >>> >> > I mentioned on the PR that I had been using the 'blocker' priority along with the 'fix version' field to mark issues that I want to get in the release.
>>> >>> >> > Of course, this little practice of mine only matters much around release branch cutting time - and has been useful for me to track which things I want to ensure getting into the release / bump to the next /etc.
>>> >>> >> > I've also found it to be useful as a way to communicate with the release manager without having to sync directly.
>>> >>> >> >
>>> >>> >> > What would be a reasonable way to tell the release manager "I'd like to get this feature in. please talk to me if you're about to cut the branch" - that also uses the priorities appropriately? - and that allows the release manager to know when a fix version is "more optional" / "less optional"?
>>> >>> >> >
>>> >>> >> > On Wed, Oct 23, 2019 at 12:20 PM Kenneth Knowles <ke...@apache.org> wrote:
>>> >>> >> >>
>>> >>> >> >> I finally got around to writing some of this up. It is minimal. Feedback is welcome, especially if what I have written does not accurately represent the community's approach.
>>> >>> >> >>
>>> >>> >> >> https://github.com/apache/beam/pull/9862
>>> >>> >> >>
>>> >>> >> >> Kenn
>>> >>> >> >>
>>> >>> >> >> On Mon, Feb 11, 2019 at 3:21 PM Daniel Oliveira <da...@google.com> wrote:
>>> >>> >> >>>
>>> >>> >> >>> Ah, sorry, I missed that Alex was just quoting from our Jira installation (didn't read his email closely enough). Also I wasn't aware about those pages on our website.
>>> >>> >> >>>
>>> >>> >> >>> Seeing as we do have definitions for our priorities, I guess my main request would be that they be made more discoverable somehow. I don't think the tooltips are reliable, and the pages on the website are informative, but hard to find. Since it feels a bit lazy to say "this isn't discoverable enough" without suggesting any improvements, I'd like to propose these two changes:
>>> >>> >> >>>
>>> >>> >> >>> 1. We should write a Beam Jira Guide with basic information about our Jira. I think the bug priorities should go in here, but also anything else we would want someone to know before filing any Jira issues, like how our components are organized or what the different issue types mean. This guide could either be written in the website or the wiki, but I think it should definitely be linked in https://beam.apache.org/contribute/ so that newcomers read it before getting their Jira account approved. The goal here being to have a reference for the basics of our Jira since at the moment it doesn't seem like we have anything for this.
>>> >>> >> >>>
>>> >>> >> >>> 2. The existing info on Post-commit and pre-commit policies doesn't seem very discoverable to someone monitoring the Pre/Post-commits. I've reported a handful of test-failures already and haven't seen this link mentioned much. We should try to find a way to funnel people towards this link when there's an issue, the same way we try to funnel people towards the contribution guide when they write a PR. As a note, while writing this email I remembered this link that someone gave me before (https://s.apache.org/beam-test-failure). That mentions the Post-commit policies page, so maybe it's just a matter of pasting that all over our Jenkins builds whenever we have a failing test?
>>> >>> >> >>>
>>> >>> >> >>> PS: I'm also definitely for SLOs, but I figure it's probably better discussed in a separate thread so I'm trying to stick to the subject of priority definitions.
>>> >>> >> >>>
>>> >>> >> >>> On Mon, Feb 11, 2019 at 9:17 AM Scott Wegner <sc...@apache.org> wrote:
>>> >>> >> >>>>
>>> >>> >> >>>> Thanks for driving this discussion. I also was not aware of these existing definitions. Once we agree on the terms, let's add them to our Contributor Guide and start using them.
>>> >>> >> >>>>
>>> >>> >> >>>> +1 in general; I like both Alex and Kenn's definitions; Additional wordsmithing could be moved to a Pull Request. Can we make the definitions useful for both the person filing a bug, and the assignee, i.e.
>>> >>> >> >>>>
>>> >>> >> >>>> <Priority Level>: <Criteria for what types of issues should be assigned>. <Expectations for responding to a Priority Level issue>
>>> >>> >> >>>>
>>> >>> >> >>>> On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles <kl...@google.com> wrote:
>>> >>> >> >>>>>
>>> >>> >> >>>>> The content that Alex posted* is the definition from our Jira installation anyhow.
>>> >>> >> >>>>>
>>> >>> >> >>>>> I just searched around, and there's https://community.atlassian.com/t5/Jira-questions/According-to-Jira-What-is-Blocker-Critical-Major-Minor-and/qaq-p/668774 which makes clear that this is really user-defined, since Jira has many deployments with their own configs.
>>> >>> >> >>>>>
>>> >>> >> >>>>> I guess what I want to know about this thread is what action is being proposed?
>>> >>> >> >>>>>
>>> >>> >> >>>>> Previously, there was a thread that resulted in https://beam.apache.org/contribute/precommit-policies/ and https://beam.apache.org/contribute/postcommits-policies/. These have test failures and flakes as Critical. I agree with Alex that these should be Blocker. They disrupt the work of the entire community, so we need to drop everything and get green again.
>>> >>> >> >>>>>
>>> >>> >> >>>>> Other than that, I think what you - Daniel - are suggesting is that the definition might be best expressed as SLOs. I asked on user@infra.apache.org about how we could have those and the answer is the homebrew https://svn.apache.org/repos/infra/infrastructure/trunk/projects/status/sla/jira/. If anyone has time to dig into that and see if it can work for us, that would be cool.
>>> >>> >> >>>>>
>>> >>> >> >>>>> Kenn
>>> >>> >> >>>>>
>>> >>> >> >>>>> *Blocker: Blocks development and/or testing work, production could not run
>>> >>> >> >>>>> Critical: Crashes, loss of data, severe memory leak.
>>> >>> >> >>>>> Major (Default): Major loss of function.
>>> >>> >> >>>>> Minor: Minor loss of function, or other problem where easy workaround is present.
>>> >>> >> >>>>> Trivial: Trivial Cosmetic problem like misspelt words or misaligned text.
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>> On Sun, Feb 10, 2019 at 7:20 PM Daniel Oliveira <da...@google.com> wrote:
>>> >>> >> >>>>>>
>>> >>> >> >>>>>> Are there existing meanings for the priorities in Jira already? I wasn't able to find any info on either the Beam website or wiki about it, so I've just been prioritizing issues based on gut feeling. If not, I think having some well-defined priorities would be nice, at least for our test-failures, and especially if we wanna have some SLOs like I've seen being thrown about.
>>> >>> >> >>>>>>
>>> >>> >> >>>>>> On Fri, Feb 8, 2019 at 3:06 PM Kenneth Knowles <ke...@apache.org> wrote:
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> I've been thinking about this since working on the release. If I ignore the names I think:
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> P0: get paged, stop whatever you planned on doing, work late to fix
>>> >>> >> >>>>>>> P1: continually update everyone on status and shouldn't sit around unassigned
>>> >>> >> >>>>>>> P2: most things here; they can be planned or picked up by whomever
>>> >>> >> >>>>>>> P3: nice-to-have things, maybe starter tasks or lesser cleanup, but no driving need
>>> >>> >> >>>>>>> Sometimes there's P4 but I don't value it. Often P3 is a deprioritized thing from P2, so more involved and complex, while P4 is something easy and not important filed just as a reminder. Either way, they are both not on the main path of work.
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> I looked into it and the Jira priority scheme determines the set of priorities as well as the default. Ours is shared by 635 projects. Probably worth keeping. The default priority is Major which would correspond with P2. We can expect the default to be where most issues end up.
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> P0 == Blocker: get paged, stop whatever you planned on doing, work late to fix
>>> >>> >> >>>>>>> P1 == Critical: continually update everyone on status and shouldn't sit around unassigned
>>> >>> >> >>>>>>> P0 == Major (default): most things here; they can be planned or picked up by whomever
>>> >>> >> >>>>>>> P3 == Minor: nice-to-have things, maybe starter tasks or lesser cleanup, but no driving need
>>> >>> >> >>>>>>> Trivial: Maybe this is attractive to newcomers as it makes it sound easy.
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> Kenn
>>> >>> >> >>>>>>>
>>> >>> >> >>>>>>> On Thu, Feb 7, 2019 at 4:08 PM Alex Amato <aj...@google.com> wrote:
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Hello Beam community, I was thinking about this and found some information to share/discuss. Would it be possible to confirm my thinking on this:
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> There are 5 priorities in the JIRA system today (tooltip link):
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Blocker Blocks development and/or testing work, production could not run
>>> >>> >> >>>>>>>> Critical Crashes, loss of data, severe memory leak.
>>> >>> >> >>>>>>>> Major Major loss of function.
>>> >>> >> >>>>>>>> Minor Minor loss of function, or other problem where easy workaround is present.
>>> >>> >> >>>>>>>> Trivial Cosmetic problem like misspelt words or misaligned text.
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> How should JIRA issues be prioritized for pre/post commit test failures?
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> I think Blocker
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> What about the flakey failures?
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Blocker as well?
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> How should non test issues be prioritized? (E.g. feature to implement or bugs not regularly breaking tests).
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> I suggest Minor, but its not clear how to distinguish between these.
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Below is my thinking: But I wanted to know what the Apache/Beam community generally thinks about these priorities.
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Blocker: Expect to be paged. Production systems are down.
>>> >>> >> >>>>>>>> Critical: Expect to be contacted by email or a bot to fix this.
>>> >>> >> >>>>>>>> Major: Some loss of function in the repository, can issues that need to be addressed soon are here.
>>> >>> >> >>>>>>>> Minor: Most issues will be here, important issues within this will get picked up and completed. FRs, bugs.
>>> >>> >> >>>>>>>> Trivial: Unlikely to be implemented, far too many issues in this category. FRs, bugs.
>>> >>> >> >>>>>>>>
>>> >>> >> >>>>>>>> Thanks for helping to clear this up
>>> >>> >> >>>>>>>> Alex
>>> >>> >> >>>>
>>> >>> >> >>>>
>>> >>> >> >>>>
>>> >>> >> >>>> --
>>> >>> >> >>>>
>>> >>> >> >>>>
>>> >>> >> >>>>
>>> >>> >> >>>>
>>> >>> >> >>>> Got feedback? tinyurl.com/swegner-feedback