On Fri, May 1, 2020 at 2:34 PM Kenneth Knowles <[email protected]> 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 <[email protected]> wrote: >> >> That SGTM >> >> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw <[email protected]> wrote: >>> >>> +1 to both. >>> >>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev <[email protected]> >>> wrote: >>> > >>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> >>> > <[email protected]> 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 <[email protected]> >>> >>> >> 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 <[email protected]> >>> >>> >> > 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 >>> >>> >> >> <[email protected]> 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 <[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): >>> >>> >> >>>>>>>> >>> >>> >> >>>>>>>> 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
