Re: JIRA priorities explaination

[Kenneth Knowles]

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  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  wrote:
>
>> Proposal sounds good to me! The tool tips will be fantastic.
>>
>> On Fri, May 1, 2020 at 3:03 PM Robert Bradshaw 
>> wrote:
>>
>>> On Fri, May 1, 2020 at 2:34 PM Kenneth Knowles  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 
>>> wrote:
>>> >>
>>> >> That SGTM
>>> >>
>>> >> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw 
>>> wrote:
>>> >>>
>>> >>> +1 to both.
>>> >>>
>>> >>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev <
>>> valen...@google.com> wrote:
>>> >>> >
>>> >>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles 
>>> 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 
>>> 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 
>>> 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 rele

Re: JIRA priorities explaination

[Ahmet Altay]

+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  wrote:

> Proposal sounds good to me! The tool tips will be fantastic.
>
> On Fri, May 1, 2020 at 3:03 PM Robert Bradshaw 
> wrote:
>
>> On Fri, May 1, 2020 at 2:34 PM Kenneth Knowles  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 
>> wrote:
>> >>
>> >> That SGTM
>> >>
>> >> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw 
>> wrote:
>> >>>
>> >>> +1 to both.
>> >>>
>> >>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev <
>> valen...@google.com> wrote:
>> >>> >
>> >>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles 
>> 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 
>> 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 
>> 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 <
>> rober...@google.com

Re: JIRA priorities explaination

[Tyson Hamilton]

Proposal sounds good to me! The tool tips will be fantastic.

On Fri, May 1, 2020 at 3:03 PM Robert Bradshaw  wrote:

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

Re: JIRA priorities explaination

[Luke Cwik]

Sounds good to me.

On Fri, May 1, 2020 at 2:34 PM Kenneth Knowles  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  wrote:
>
>> That SGTM
>>
>> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw 
>> wrote:
>>
>>> +1 to both.
>>>
>>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev 
>>> wrote:
>>> >
>>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles 
>>> 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 
>>> 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 
>>> 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 <
>>> rober...@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 <
>>> pabl...@google.com> wrote:
>>> >>> >> >
>>> >>> >> > I mentioned on the PR t

Re: JIRA priorities explaination

[Robert Bradshaw]

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

Re: JIRA priorities explaination

[Kenneth Knowles]

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

> That SGTM
>
> On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw 
> wrote:
>
>> +1 to both.
>>
>> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev 
>> wrote:
>> >
>> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles 
>> 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 
>> 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 
>> 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 <
>> rober...@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 
>> 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 h

Re: JIRA priorities explaination

[Pablo Estrada]

That SGTM

On Fri, Oct 25, 2019 at 4:18 PM Robert Bradshaw  wrote:

> +1 to both.
>
> On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev 
> wrote:
> >
> > On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles  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 
> 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 
> 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 <
> rober...@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 
> 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 
> 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 <
> danolive...@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 Be

Re: JIRA priorities explaination

[Robert Bradshaw]

+1 to both.

On Fri, Oct 25, 2019 at 3:58 PM Valentyn Tymofieiev  wrote:
>
> On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles  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  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  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  
>>> > 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  
>>> >> 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  
>>> >> > 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 
>>> >> >>  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 

Re: JIRA priorities explaination

[Valentyn Tymofieiev]

On Fri, Oct 25, 2019 at 3:39 PM Kenneth Knowles  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  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  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 
>> 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 
>> 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 
>> 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 <
>> danolive...@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 l

Re: JIRA priorities explaination

[Kenneth Knowles]

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  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  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 
> 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 
> 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 
> 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 <
> danolive...@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. A

Re: JIRA priorities explaination

[Kenneth Knowles]

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 
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  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 
> 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 
> 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  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.
> 
>  :  assigned>. 
> 
>  On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles 
> wrote:
> >
> > The content that Alex posted* is the definition from our Jira
> install

Re: JIRA priorities explaination

[Robert Bradshaw]

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  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  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  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  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  
>> >> 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  wrote:
>> 
>>  Thanks for driving this discussion. I also was not aware of thes

Re: JIRA priorities explaination

[Robert Bradshaw]

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

 : . 
 

 On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles  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

Re: JIRA priorities explaination

[Pablo Estrada]

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  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 
> 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  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.
>>>
>>> : >> assigned>. 
>>>
>>> On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles  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
 u...@infra.apache.org about how 

Re: JIRA priorities explaination

[Kenneth Knowles]

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 
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  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.
>>
>> : .
>> 
>>
>> On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles  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
>>> 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 
>>> 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 w

Re: JIRA priorities explaination

[Daniel Oliveira]

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  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.
>
> : .
> 
>
> On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles  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
>> 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 
>> 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  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: continu

Re: JIRA priorities explaination

[Scott Wegner]

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.

: .


On Sun, Feb 10, 2019 at 7:49 PM Kenneth Knowles  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
> 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 
> 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  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  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?
>>>

Re: JIRA priorities explaination

[Kenneth Knowles]

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

Re: JIRA priorities explaination

[Daniel Oliveira]

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

Re: JIRA priorities explaination

[Kenneth Knowles]

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