Re: Request to review feature-freeze proposed tickets

[Vinay Chella]

Thanks for the responses, I think the summary so far is: committers and
reviewers are positive on reviewing the community tickets mentioned in this
email except for a couple of them that Joshua mentioned, with the caution of
not disrupting the current testing efforts.

Thank you, Ariel, for understanding the concerns and helping with reviews.

Thank you, Jon, for picking up CASSANDRA-14303.

@Joshua, if you can comment on the tickets that concern you that would be
helpful, and I will take them off from my list to track for 4.0.

I would like to help drive these tickets to their completion in 4.0 (either
deferred or committed) unless someone has concerns.

Thanks,
Vinay


On Thu, Nov 22, 2018 at 6:19 PM Sankalp Kohli 
wrote:

> We already should be taking correctness and perf changes and I am +1 on
> taking operational tickets. Agree with Josh that the only exception will be
> if it causes disruption in testing.
>
> I think as a project we should be more open to operational issues as
> having a fork is not ideal.
>
> Regarding time it is taking to review things, I think we should not start
> doing big features post 4.0 but instead review all possible JIRAs first.
> Once we are out of this debt, we should define a  process so that we don’t
> end up in this state. I think this item deserves a separate thread which we
> can start closer to 4.0 being cut.
>
> > On Nov 23, 2018, at 12:17 AM, Joshua McKenzie 
> wrote:
> >
> > Strong +1 on prioritizing community engagement 1st and caution second,
> > though still prioritizing it. I think the right metric for us to
> calibrate
> > around is that "disrupt in-flight testing cycles", i.e. if changes cause
> > significant rework for people that have already begun testing 4.0,
> probably
> > ok to review and get it in but target 4.0.x.
> >
> > On Thu, Nov 22, 2018 at 12:00 PM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> >>> I assume it's obvious to everyone that this should be taken on a
> >>> case-by-case basis. There's at least 2 that were in that list (one of
> >> which
> >>> Marcus bumped off PA) that are potentially big and hairy changes that
> >> would
> >>> disrupt in-flight testing cycles.
> >>
> >> Agreed.  I’d prefer we aim to be as permissive as practical, though.
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

Thanks.  I’ll respond inline with the thinking around the original proposal.

> On 5 Dec 2018, at 20:26, Stefan Podkowinski  wrote:
> 
> Thanks Benedict and everyone involved putting up the proposal! It really
> deserves some more feedback and I realize that I'm a bit late for that
> and probably missed a good deal of the conversation so far. I'd still
> like to share some of my notes that I've taken while reading through it,
> for the sake of discussion.
> 
> 
> Priority:
> Blocker and critical seem to be more useful to me, compared to "urgent",
> which is not clear about what's being urgent to whom and probably be
> picked from a personal perspective. Blockers are useful for identifying
> issues that need to be solved before creating an imminent release.
> Critical should be used for patches important enough for releases that
> are maintained on "critical bug fixes only" basis. It's not strictly
> used that way, but "urgent" doesn't address this.

Urgent was intended specifically to replace both Blocker and Critical.  
Anything “Urgent” probably needs to block release and probably accelerate 
release once committed.

We don’t really distinguish between Critical and Blocker right now, and I’m not 
sure we need to.  Perhaps others have input?

> Complexity:
> Possibly inappropriate for some type of issues, simply not known yet, or
> impossible to tell. I'd not add it and keep using labels for that if we
> have to highlight outliers, like lhf.

This is explicitly only for the Bug issue type.

> Discovered by:
> Neat idea, would be very interesting to analyze that.
> 
> Bug category:
> More complex bugs will probably fall into multiple categories. Choices
> are hard to answer without the description. Do we really need this as a
> mandatory field for new bug reports, which may not have been even
> analyzed yet. What would you pick e.g. when reporting a broken test on CI?

The Triage state is intended to handle this.  You only migrate to Open when you 
have enough information to complete this.

I’m also not convinced there is actually much overlap?  The only ones I can 
think of, there’s a clear attribution.

In your example, the following item from the Correctness list:

Test Failure
A test is broken - if this turns out to be a legitimate bug, it should 
transition to the bug's category once diagnosed


> Component:
> I'd prefer not having to have subcategories or multi-select values. It's
> too inflexible (why would any hint issues necessarily be consistency
> issues?).

The category doesn’t imply there’s a consistency problem, they just categorise 
the components.  A consistency problem would be denoted in the bug category. 

For this specific example, Hints are most easily grouped along with the set of 
features we use to distribute data around the cluster, which has been loosely 
named consistency in this proposal.  It doesn’t follow that a problem with any 
one of these systems entails a failure of consistency?

If you have a better name proposal, I’m all ears.  But trust me, it’s a hard 
problem, and took a surprising amount of time to come up with this proposal.  
Loosely grouping items should make the more complete list more manageable than 
a giant grab-bag, so that people become familiar with the groupings, and don’t 
need to remember the naming of every item.  Conversely, the present day setup 
of loose groupings only leads to a lot of misunderstandings about what was 
meant by those groups.

> 
> Features:
> Distinction of features/components isn't really clear to me. At least
> crosscuts like observability should be there, instead of components.
> It's still useful, as it's general enough, easy to answer and
> insightful. I'd reduce the component list a bit and make this an
> optional follow up selection after features. 

The idea was primarily for things that were both cross-sectional and difficult 
to group together.  Observability could probably go in Features, sure.  I don’t 
really have a strong opinion on that.

> Remove 'Reproduced in':
> We should have a field that allows the user to report the used Cassandra
> version for an issue.

Why not a comment or the description?  This field is not searchable, and it 
usually gets reported in the description today.  Usage of this field is very 
patchy, and of not great utility IMO.  Perhaps others have an opinion?

> As for workflow changes, I don't have a real opinion on that yet and
> like to give this some more thoughts. But the suggested review status
> changes are something I'd definitely like to see happening.
> 
> 
> On 04.12.18 20:12, Benedict Elliott Smith wrote:
>> Ok, so after an initial flurry everyone has lost interest :)
>> 
>> I think we should take a quick poll (not a vote), on people’s positions on 
>> the questions raised so far.  If people could try to take the time to stake 
>> a +1/-1, or A/B, for each item, that would be really great.  This poll will 
>> not be the end of discussions, but will (hopefully) at least draw a 

Re: JIRA Workflow Proposals

[Stefan Podkowinski]

Thanks Benedict and everyone involved putting up the proposal! It really
deserves some more feedback and I realize that I'm a bit late for that
and probably missed a good deal of the conversation so far. I'd still
like to share some of my notes that I've taken while reading through it,
for the sake of discussion.


Priority:
Blocker and critical seem to be more useful to me, compared to "urgent",
which is not clear about what's being urgent to whom and probably be
picked from a personal perspective. Blockers are useful for identifying
issues that need to be solved before creating an imminent release.
Critical should be used for patches important enough for releases that
are maintained on "critical bug fixes only" basis. It's not strictly
used that way, but "urgent" doesn't address this.

Complexity:
Possibly inappropriate for some type of issues, simply not known yet, or
impossible to tell. I'd not add it and keep using labels for that if we
have to highlight outliers, like lhf.

Discovered by:
Neat idea, would be very interesting to analyze that.

Bug category:
More complex bugs will probably fall into multiple categories. Choices
are hard to answer without the description. Do we really need this as a
mandatory field for new bug reports, which may not have been even
analyzed yet. What would you pick e.g. when reporting a broken test on CI?

Component:
I'd prefer not having to have subcategories or multi-select values. It's
too inflexible (why would any hint issues necessarily be consistency
issues?).

Features:
Distinction of features/components isn't really clear to me. At least
crosscuts like observability should be there, instead of components.
It's still useful, as it's general enough, easy to answer and
insightful. I'd reduce the component list a bit and make this an
optional follow up selection after features. 

Remove 'Reproduced in':
We should have a field that allows the user to report the used Cassandra
version for an issue.


As for workflow changes, I don't have a real opinion on that yet and
like to give this some more thoughts. But the suggested review status
changes are something I'd definitely like to see happening.


On 04.12.18 20:12, Benedict Elliott Smith wrote:
> Ok, so after an initial flurry everyone has lost interest :)
>
> I think we should take a quick poll (not a vote), on people’s positions on 
> the questions raised so far.  If people could try to take the time to stake a 
> +1/-1, or A/B, for each item, that would be really great.  This poll will not 
> be the end of discussions, but will (hopefully) at least draw a line under 
> the current open questions.
>
> I will start with some verbiage, then summarise with options for everyone to 
> respond to.  You can scroll to the summary immediately if you like.
>
> - 1. Component: Multi-select or Cascading-select (i.e. only one component 
> possible per ticket, but neater UX)
> - 2. Labels: rather than litigate people’s positions, I propose we do the 
> least controversial thing, which is to simply leave labels intact, and only 
> supplement them with the new schema information.  We can later revisit if we 
> decide it’s getting messy.
> - 3. "First review completed; second review ongoing": I don’t think we need 
> to complicate the process; if there are two reviews in flight, the first 
> reviewer can simply comment that they are done when ready, and the second 
> reviewer can move the status once they are done.  If the first reviewer wants 
> substantive changes, they can move the status to "Change Request” before the 
> other reviewer completes, if they like.  Everyone involved can probably 
> negotiate this fairly well, but we can introduce some specific guidance on 
> how to conduct yourself here in a follow-up.  
> - 4. Priorities: Option A: Wish, Low, Normal, High, Urgent; Option B: Wish, 
> Low, Normal, Urgent
> - 5. Mandatory Platform and Feature. Make mandatory by introducing new “All” 
> and “None” (respectively) options, so always possible to select an option.
> - 6. Environment field: Remove?
>
> I think this captures everything that has been brought up so far, except for 
> the suggestion to make "Since Version” a “Version” - but that needs more 
> discussion, as I don’t think there’s a clear alternative proposal yet.
>
> Summary:
>
> 1: Component. (A) Multi-select; (B) Cascading-select
> 2: Labels: leave alone +1/-1
> 3: No workflow changes for first/second review: +1/-1
> 4: Priorities: Including High +1/-1
> 5: Mandatory Platform and Feature: +1/-1
> 6: Remove Environment field: +1/-1
>
> I will begin.
>
> 1: A
> 2: +1
> 3: +1
> 4: +1
> 5: Don’t mind
> 6: +1
>
>
>
>
>> On 29 Nov 2018, at 22:04, Scott Andreas  wrote:
>>
>> If I read Josh’s reply right, I think the suggestion is to periodically 
>> review active labels and promote those that are demonstrably useful to 
>> components (cf. folksonomy -> 
>> taxonomy). 
>> I hadn’t read the reply as 

Re: JIRA Workflow Proposals

[Nate McCall]

> Summary:
>
> 1: Component. (A) Multi-select; (B) Cascading-select
> 2: Labels: leave alone +1/-1
> 3: No workflow changes for first/second review: +1/-1
> 4: Priorities: Including High +1/-1
> 5: Mandatory Platform and Feature: +1/-1
> 6: Remove Environment field: +1/-1
>

1: A
2: +1
3: +1
4: +1
5: +0
6: +1

(Appreciate the good discussion here as well - thx everyone!)

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: JIRA Workflow Proposals

[Joshua McKenzie]

1: A
2: +1
3: +1
4: +1
5: Meh. +0
6: +1

On Wed, Dec 5, 2018 at 2:57 PM Jonathan Haddad  wrote:

> My personal preference is to remove labels, but I don't see it as a huge
> issue if they stay.
>
> 1. A
> 2. prefer to remove (I suppose I'm a -.1?)
> 3. +1
> 4. +1
> 5. No preference
> 6. +1
>
>
>
> On Wed, Dec 5, 2018 at 11:43 AM jay.zhu...@yahoo.com.INVALID
>  wrote:
>
> >  1: Component. (A) Multi-select
> > 2: Labels: leave alone +1
> > 3: No workflow changes for first/second review: +1
> > 4: Priorities Including High: -1
> > 5: Mandatory Platform and Feature: +1
> > 6: Remove Environment field: +1
> >
> > On Wednesday, December 5, 2018, 2:58:21 AM PST, Benedict Elliott
> Smith
> >  wrote:
> >
> >  Thanks for the feedback and further questions.  I’m sure there will be
> > more, particularly around permissions and roles, so it’s good to get some
> > of these other discussions moving.
> >
> > No doubt we’ll do a second poll once the first one concludes.  Please,
> > everyone, keep your first poll answers coming!
> >
> > > On 5 Dec 2018, at 09:50, Sylvain Lebresne  wrote:
> > >
> > > Thanks for all those that contributed to the proposal, and specifically
> > to
> > > Benedict for leading the discussion.
> > >
> > > On the general proposal, I suspect there is a few details we may have
> to
> > > tweak going forward, but hard to be sure before trying and as I do
> think
> > > it's progress, I'm personally happy to move forward with this. But for
> > the
> > > sake of discussions, a minor remarks that I don't think have been
> > mentioned
> > > above:
> > > - at least the platform and feature fields will be moving targets (the
> > > features hopefully more so than the platform, but new java version gets
> > > release regularly for instance). Do we know technically if we can get
> > those
> > > easily updated without requiring an infra JIRA ticket?
> >
> > This is actually a really good question.  I had assumed this would be
> > treated much like Component, Version, etc
> >
> > However, I was wrong:
> >
> >
> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
> > <
> >
> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
> > >
> >
> > There are some possible workarounds, but none of them seem great.
> There’s
> > a plugin, but not sure if Infra would be OK with this:
> >
> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server=overview
> > <
> >
> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server=overview
> > >
> >
> > This is potentially a real blocker for these two fields.
> >
> > So, for feature an alternative is to merge Feature/[Feature] into
> > Component.  This would implicitly make it non-mandatory, however.  This
> > could potentially be fixed with a custom field validator, but this might
> > need a plugin.
> >
> > For Platform, I don’t have a good alternative idea right now.  This is
> > something that is best curated, but definitely needs to be easily
> updated.
> >
> >
> > > - I'd personally probably remove the condition of being "jira
> > contributor"
> > > to move tickets out of triage. Being a "jira contributor" is a pretty
> > > arbitrary in practice. Anyone that ever asked has been added, no
> question
> > > asked, but it can actually be annoying to get added if no-one that
> knows
> > > how to do it is around. So if, as I assume, the goal is to ensure that
> > > fields are properly fielded, I don't think it will help much, and so I
> > > suspect it would just be an annoyance to new, not-yet-"jira
> contributor"
> > > users that are willing to fill all the required fields seriously (but
> > will
> > > see their ticket stuck in triage until they either get added, or some
> > other
> > > random user flip the switch). And why assume people will mis-field
> > stuffs?
> > > So I'd vote for just letting anyone transition out of triage as long as
> > all
> > > required field are there. Side-note: fwiw, I'd very much be in favor of
> > > removing the "jira contributor" concept for the reasons exposed above:
> I
> > > never felt it was anything else than an hindrance.
> >
> > I realise we have no real barrier to becoming a contributor, and that
> many
> > of these permissions are going to have limited impact.  But I think a
> > really easy to jump gate can still be helpful, and I don’t recall
> > contributors overstepping their role.  But this isn’t a critical point,
> and
> > it would be great to hear other’s opinions.
> >
> > > - Once we have 'complexity' and 'severity', I'm not entirely sure what
> > > 'priority' really means in a voluntary-based project? Is it the
> > gut-feeling
> > > for how useful the ticket is of whomever triage the ticket? If that,
> > > outside of not being convinced of the value, I'd argue that 1) it
> doesn't
> > > make sense for bugs and 2) it's sufficiently 

Re: JIRA Workflow Proposals

[Jonathan Haddad]

My personal preference is to remove labels, but I don't see it as a huge
issue if they stay.

1. A
2. prefer to remove (I suppose I'm a -.1?)
3. +1
4. +1
5. No preference
6. +1



On Wed, Dec 5, 2018 at 11:43 AM jay.zhu...@yahoo.com.INVALID
 wrote:

>  1: Component. (A) Multi-select
> 2: Labels: leave alone +1
> 3: No workflow changes for first/second review: +1
> 4: Priorities Including High: -1
> 5: Mandatory Platform and Feature: +1
> 6: Remove Environment field: +1
>
> On Wednesday, December 5, 2018, 2:58:21 AM PST, Benedict Elliott Smith
>  wrote:
>
>  Thanks for the feedback and further questions.  I’m sure there will be
> more, particularly around permissions and roles, so it’s good to get some
> of these other discussions moving.
>
> No doubt we’ll do a second poll once the first one concludes.  Please,
> everyone, keep your first poll answers coming!
>
> > On 5 Dec 2018, at 09:50, Sylvain Lebresne  wrote:
> >
> > Thanks for all those that contributed to the proposal, and specifically
> to
> > Benedict for leading the discussion.
> >
> > On the general proposal, I suspect there is a few details we may have to
> > tweak going forward, but hard to be sure before trying and as I do think
> > it's progress, I'm personally happy to move forward with this. But for
> the
> > sake of discussions, a minor remarks that I don't think have been
> mentioned
> > above:
> > - at least the platform and feature fields will be moving targets (the
> > features hopefully more so than the platform, but new java version gets
> > release regularly for instance). Do we know technically if we can get
> those
> > easily updated without requiring an infra JIRA ticket?
>
> This is actually a really good question.  I had assumed this would be
> treated much like Component, Version, etc
>
> However, I was wrong:
>
> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
> <
> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
> >
>
> There are some possible workarounds, but none of them seem great.  There’s
> a plugin, but not sure if Infra would be OK with this:
> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server=overview
> <
> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server=overview
> >
>
> This is potentially a real blocker for these two fields.
>
> So, for feature an alternative is to merge Feature/[Feature] into
> Component.  This would implicitly make it non-mandatory, however.  This
> could potentially be fixed with a custom field validator, but this might
> need a plugin.
>
> For Platform, I don’t have a good alternative idea right now.  This is
> something that is best curated, but definitely needs to be easily updated.
>
>
> > - I'd personally probably remove the condition of being "jira
> contributor"
> > to move tickets out of triage. Being a "jira contributor" is a pretty
> > arbitrary in practice. Anyone that ever asked has been added, no question
> > asked, but it can actually be annoying to get added if no-one that knows
> > how to do it is around. So if, as I assume, the goal is to ensure that
> > fields are properly fielded, I don't think it will help much, and so I
> > suspect it would just be an annoyance to new, not-yet-"jira contributor"
> > users that are willing to fill all the required fields seriously (but
> will
> > see their ticket stuck in triage until they either get added, or some
> other
> > random user flip the switch). And why assume people will mis-field
> stuffs?
> > So I'd vote for just letting anyone transition out of triage as long as
> all
> > required field are there. Side-note: fwiw, I'd very much be in favor of
> > removing the "jira contributor" concept for the reasons exposed above: I
> > never felt it was anything else than an hindrance.
>
> I realise we have no real barrier to becoming a contributor, and that many
> of these permissions are going to have limited impact.  But I think a
> really easy to jump gate can still be helpful, and I don’t recall
> contributors overstepping their role.  But this isn’t a critical point, and
> it would be great to hear other’s opinions.
>
> > - Once we have 'complexity' and 'severity', I'm not entirely sure what
> > 'priority' really means in a voluntary-based project? Is it the
> gut-feeling
> > for how useful the ticket is of whomever triage the ticket? If that,
> > outside of not being convinced of the value, I'd argue that 1) it doesn't
> > make sense for bugs and 2) it's sufficiently imprecise that it's imo
> worth
> > keeping it simple, something like low/normal/high ought to be enough. If
> > it's not that, then what is it, cause it's genuinely not immediately
> > obvious to me?
>
> Well, if nothing else Priority is the thing I sort my outstanding work by,
> and for this reason I have a preference for it being present for 

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

Thanks for the feedback and further questions.  I’m sure there will be more, 
particularly around permissions and roles, so it’s good to get some of these 
other discussions moving.

No doubt we’ll do a second poll once the first one concludes.  Please, 
everyone, keep your first poll answers coming!

> On 5 Dec 2018, at 09:50, Sylvain Lebresne  wrote:
> 
> Thanks for all those that contributed to the proposal, and specifically to
> Benedict for leading the discussion.
> 
> On the general proposal, I suspect there is a few details we may have to
> tweak going forward, but hard to be sure before trying and as I do think
> it's progress, I'm personally happy to move forward with this. But for the
> sake of discussions, a minor remarks that I don't think have been mentioned
> above:
> - at least the platform and feature fields will be moving targets (the
> features hopefully more so than the platform, but new java version gets
> release regularly for instance). Do we know technically if we can get those
> easily updated without requiring an infra JIRA ticket?

This is actually a really good question.  I had assumed this would be treated 
much like Component, Version, etc

However, I was wrong:
https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
 


There are some possible workarounds, but none of them seem great.  There’s a 
plugin, but not sure if Infra would be OK with this: 
https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server=overview
 


This is potentially a real blocker for these two fields.

So, for feature an alternative is to merge Feature/[Feature] into Component.  
This would implicitly make it non-mandatory, however.  This could potentially 
be fixed with a custom field validator, but this might need a plugin.

For Platform, I don’t have a good alternative idea right now.  This is 
something that is best curated, but definitely needs to be easily updated.


> - I'd personally probably remove the condition of being "jira contributor"
> to move tickets out of triage. Being a "jira contributor" is a pretty
> arbitrary in practice. Anyone that ever asked has been added, no question
> asked, but it can actually be annoying to get added if no-one that knows
> how to do it is around. So if, as I assume, the goal is to ensure that
> fields are properly fielded, I don't think it will help much, and so I
> suspect it would just be an annoyance to new, not-yet-"jira contributor"
> users that are willing to fill all the required fields seriously (but will
> see their ticket stuck in triage until they either get added, or some other
> random user flip the switch). And why assume people will mis-field stuffs?
> So I'd vote for just letting anyone transition out of triage as long as all
> required field are there. Side-note: fwiw, I'd very much be in favor of
> removing the "jira contributor" concept for the reasons exposed above: I
> never felt it was anything else than an hindrance.

I realise we have no real barrier to becoming a contributor, and that many of 
these permissions are going to have limited impact.  But I think a really easy 
to jump gate can still be helpful, and I don’t recall contributors overstepping 
their role.  But this isn’t a critical point, and it would be great to hear 
other’s opinions.

> - Once we have 'complexity' and 'severity', I'm not entirely sure what
> 'priority' really means in a voluntary-based project? Is it the gut-feeling
> for how useful the ticket is of whomever triage the ticket? If that,
> outside of not being convinced of the value, I'd argue that 1) it doesn't
> make sense for bugs and 2) it's sufficiently imprecise that it's imo worth
> keeping it simple, something like low/normal/high ought to be enough. If
> it's not that, then what is it, cause it's genuinely not immediately
> obvious to me?

Well, if nothing else Priority is the thing I sort my outstanding work by, and 
for this reason I have a preference for it being present for all ticket types.  
But I do see your point.

In particular, Urgent probably is something we’re only likely to use for 
critical bugs.  It’s possible we could even automatically populate this for a 
Bug type, and potentially not show this option for non-bugs.  But I suspect we 
would need something like the ScriptRunner plugin for this.

In my view Priority is essentially Low or Normal (or Urgent if critical bug) on 
initial filing.  But a High priority can be set by a contributor who 
particularly values the ticket, for their own work prioritisation.  Wish is a 
priority to make room for the Wish ticket type we are removing, and for those 
occasional requests that come in that have no realistic timeline for being 

Re: JIRA Workflow Proposals

[Sylvain Lebresne]

Thanks for all those that contributed to the proposal, and specifically to
Benedict for leading the discussion.

On the general proposal, I suspect there is a few details we may have to
tweak going forward, but hard to be sure before trying and as I do think
it's progress, I'm personally happy to move forward with this. But for the
sake of discussions, a minor remarks that I don't think have been mentioned
above:
- at least the platform and feature fields will be moving targets (the
features hopefully more so than the platform, but new java version gets
release regularly for instance). Do we know technically if we can get those
easily updated without requiring an infra JIRA ticket?
- I'd personally probably remove the condition of being "jira contributor"
to move tickets out of triage. Being a "jira contributor" is a pretty
arbitrary in practice. Anyone that ever asked has been added, no question
asked, but it can actually be annoying to get added if no-one that knows
how to do it is around. So if, as I assume, the goal is to ensure that
fields are properly fielded, I don't think it will help much, and so I
suspect it would just be an annoyance to new, not-yet-"jira contributor"
users that are willing to fill all the required fields seriously (but will
see their ticket stuck in triage until they either get added, or some other
random user flip the switch). And why assume people will mis-field stuffs?
So I'd vote for just letting anyone transition out of triage as long as all
required field are there. Side-note: fwiw, I'd very much be in favor of
removing the "jira contributor" concept for the reasons exposed above: I
never felt it was anything else than an hindrance.
- Once we have 'complexity' and 'severity', I'm not entirely sure what
'priority' really means in a voluntary-based project? Is it the gut-feeling
for how useful the ticket is of whomever triage the ticket? If that,
outside of not being convinced of the value, I'd argue that 1) it doesn't
make sense for bugs and 2) it's sufficiently imprecise that it's imo worth
keeping it simple, something like low/normal/high ought to be enough. If
it's not that, then what is it, cause it's genuinely not immediately
obvious to me?

And with that, my poll results:
1:A
2:+1
3:+1
4:Don't mind
5:Don't mind
--
Sylvain


On Tue, Dec 4, 2018 at 8:12 PM Benedict Elliott Smith 
wrote:

> Ok, so after an initial flurry everyone has lost interest :)
>
> I think we should take a quick poll (not a vote), on people’s positions on
> the questions raised so far.  If people could try to take the time to stake
> a +1/-1, or A/B, for each item, that would be really great.  This poll will
> not be the end of discussions, but will (hopefully) at least draw a line
> under the current open questions.
>
> I will start with some verbiage, then summarise with options for everyone
> to respond to.  You can scroll to the summary immediately if you like.
>
> - 1. Component: Multi-select or Cascading-select (i.e. only one component
> possible per ticket, but neater UX)
> - 2. Labels: rather than litigate people’s positions, I propose we do the
> least controversial thing, which is to simply leave labels intact, and only
> supplement them with the new schema information.  We can later revisit if
> we decide it’s getting messy.
> - 3. "First review completed; second review ongoing": I don’t think we
> need to complicate the process; if there are two reviews in flight, the
> first reviewer can simply comment that they are done when ready, and the
> second reviewer can move the status once they are done.  If the first
> reviewer wants substantive changes, they can move the status to "Change
> Request” before the other reviewer completes, if they like.  Everyone
> involved can probably negotiate this fairly well, but we can introduce some
> specific guidance on how to conduct yourself here in a follow-up.
> - 4. Priorities: Option A: Wish, Low, Normal, High, Urgent; Option B:
> Wish, Low, Normal, Urgent
> - 5. Mandatory Platform and Feature. Make mandatory by introducing new
> “All” and “None” (respectively) options, so always possible to select an
> option.
> - 6. Environment field: Remove?
>
> I think this captures everything that has been brought up so far, except
> for the suggestion to make "Since Version” a “Version” - but that needs
> more discussion, as I don’t think there’s a clear alternative proposal yet.
>
> Summary:
>
> 1: Component. (A) Multi-select; (B) Cascading-select
> 2: Labels: leave alone +1/-1
> 3: No workflow changes for first/second review: +1/-1
> 4: Priorities: Including High +1/-1
> 5: Mandatory Platform and Feature: +1/-1
> 6: Remove Environment field: +1/-1
>
> I will begin.
>
> 1: A
> 2: +1
> 3: +1
> 4: +1
> 5: Don’t mind
> 6: +1
>
>
>
>
> > On 29 Nov 2018, at 22:04, Scott Andreas  wrote:
> >
> > If I read Josh’s reply right, I think the suggestion is to periodically
> review active labels and promote those that are demonstrably useful to
> components (cf.