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 u...@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 <danolive...@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 <k...@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 <ajam...@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 >>> >>
