JIRA priorities explaination

[Alex Amato <aj...@google.com>]

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
   <https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels>
   ):
   -
      - *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

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

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

[Pablo Estrada <pa...@google.com>]

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

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

+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

Re: JIRA priorities explaination

[Valentyn Tymofieiev <va...@google.com>]

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

Re: JIRA priorities explaination

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

Suppose, hypothetically, we say that if Fix Version is set, then P0/Blocker
and P1/Critical block release and lower priorities get bumped.

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.

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

Re: JIRA priorities explaination

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

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

Re: JIRA priorities explaination

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

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

Re: JIRA priorities explaination

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

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

Re: JIRA priorities explaination

[Pablo Estrada <pa...@google.com>]

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
>> <https://www.google.com/url?q=https://s.apache.org/beam-test-failure&sa=D&usg=AFQjCNH0ZmcPNrKiYDDcajVZuCnC_qfxDw>).
>> 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
>>>>>>>    <https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels>
>>>>>>>    ):
>>>>>>>    -
>>>>>>>       - *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>]

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
> <https://www.google.com/url?q=https://s.apache.org/beam-test-failure&sa=D&usg=AFQjCNH0ZmcPNrKiYDDcajVZuCnC_qfxDw>).
> 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
>>>>>>    <https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels>
>>>>>>    ):
>>>>>>    -
>>>>>>       - *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

[Daniel Oliveira <da...@google.com>]

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
<https://www.google.com/url?q=https://s.apache.org/beam-test-failure&sa=D&usg=AFQjCNH0ZmcPNrKiYDDcajVZuCnC_qfxDw>).
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
>>>>>    <https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels>
>>>>>    ):
>>>>>    -
>>>>>       - *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

[Scott Wegner <sc...@apache.org>]

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
>>>>    <https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels>
>>>>    ):
>>>>    -
>>>>       - *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 <kl...@google.com>]

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
>>>    <https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels>
>>>    ):
>>>    -
>>>       - *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
>>>
>>

Re: JIRA priorities explaination

[Daniel Oliveira <da...@google.com>]

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
>>    <https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels>
>>    ):
>>    -
>>       - *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
>>
>

Re: JIRA priorities explaination

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

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
>    <https://issues.apache.org/jira/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels>
>    ):
>    -
>       - *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
>