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 <[email protected]> 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 > [email protected] 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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
