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