Re: JIRA Workflow Proposals

[Sylvain Lebresne]

Not much to add really, but just to close the loop, responses inline.

On Wed, Dec 5, 2018 at 11:58 AM 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.
>

That's what I feared, and that sucks. And I'm coming short as well of a
good alternative that don't require plugins.
That said, if push comes to shove, if we just make them free-form but
mandatory to get out of triage (with "all" and "none" being explicitly ok
values), and have a bit of documentation, there is still a good change
we'll get meaningful information out of this. Better than what we have at
least.


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

Yeah, curious to see how other feel. That said, to be clear, I'm not really
feeling any strong on this. I'd just prefer trusting people by default to
do the right thing, especially when the "JIRA contributor" barrier is so
low/largely meaningless, and save ourselves the trouble of having to add
people to the "JIRA contributor" list (which, unless something changed, is
a tiny bit annoying). Knowing that we can always change the rule to be
stricter if people get it wrong too often. But anyway, not super important,
just a minor preference of mine.


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

Re: JIRA Workflow Proposals

[Mick Semb Wever]

> 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:   0
 5: +0
 6: +1


If bugs have an objective Severity field then why bother with (a subjective) 
Priority field?

The Priority field makes sense in the commercial world, but for an open source 
project? Arn't tickets either an itch to scratch for someone, or not? I might 
have thought labels were better for "Urgent" and "Wish". No strong opinions 
though, just my two cents.

regards,
Mick

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

> 
>> 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:   0
> 5: +0
> 6: +1
> 
> 
> If bugs have an objective Severity field then why bother with (a subjective) 
> Priority field?
> 
> The Priority field makes sense in the commercial world, but for an open 
> source project? Arn't tickets either an itch to scratch for someone, or not? 
> I might have thought labels were better for "Urgent" and "Wish". No strong 
> opinions though, just my two cents.

Well, I had hoped for a world in which labels would cease to exist.  
Particularly because discovery with labels is almost impossible - we have 
almost 500 of them, so good luck guessing which one somebody used (or _should_ 
use).  I can now see the argument for keeping them (so people with a specific 
need can use them), but for regular project functionality I continue to think 
they’re a bad fit.

I’ll be sure anyway to add items to poll #2, on using Priority for the Bug 
issue type, and for the Wish priority.  Thanks.

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

[Sam Tunnicliffe]

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

On the question of keeping the contributors-only restriction on moving from 
Triage->Open, I tend to agree with Benedict that a low barrier can be useful in 
deterring bogus transitions (accidental or malicious) which keeps the general 
noise down. I’m thinking of the current situation where tickets are routinely 
marked "Ready To Commit” and which contributors have to spend time/energy 
watching for and fixing. That said, that only requires hitting a button not 
potentially filling out a bunch of fields so maybe we can afford to be 
permissive in the first instance here and tighten things up if it becomes a 
problem.


> On 6 Dec 2018, at 08:16, Sylvain Lebresne  wrote:
> 
> Not much to add really, but just to close the loop, responses inline.
> 
> On Wed, Dec 5, 2018 at 11:58 AM 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.
>> 
> 
> That's what I feared, and that sucks. And I'm coming short as well of a
> good alternative that don't require plugins.
> That said, if push comes to shove, if we just make them free-form but
> mandatory to get out of triage (with "all" and "none" being explicitly ok
> values), and have a bit of documentation, there is still a good change
> we'll get meaningful information out of this. Better than what we have at
> least.
> 
> 
>>> - 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
>> 

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

Thanks everyone for your feedback so far!  I think we have a pretty strong 
consensus for the first questions.  I will follow-up later with a new poll; 
hopefully this will be the last round, so if you have any more questions that 
haven’t been aired, please do bring them up now.

1: A (+9)
2: +8 -0.1
3: +9
4: +6 -1
5: +2; a lot of meh.  (This may be defunct given the problems Sylvain raised, 
anyway, but we will have to negotiate that with Infra once we have a clear 
mandate to bring to them)
6: +8

Obviously, feel free to keep your poll answers coming, in case you think the 
balance will tip.  But at this point I’m happy to pre-emptively call it.


> On 6 Dec 2018, at 13:55, Sam Tunnicliffe  wrote:
> 
> 1: A
> 2: +1
> 3: +1
> 4: +1
> 5: +0
> 6: +1
> 
> On the question of keeping the contributors-only restriction on moving from 
> Triage->Open, I tend to agree with Benedict that a low barrier can be useful 
> in deterring bogus transitions (accidental or malicious) which keeps the 
> general noise down. I’m thinking of the current situation where tickets are 
> routinely marked "Ready To Commit” and which contributors have to spend 
> time/energy watching for and fixing. That said, that only requires hitting a 
> button not potentially filling out a bunch of fields so maybe we can afford 
> to be permissive in the first instance here and tighten things up if it 
> becomes a problem.
> 
> 
>> On 6 Dec 2018, at 08:16, Sylvain Lebresne  wrote:
>> 
>> Not much to add really, but just to close the loop, responses inline.
>> 
>> On Wed, Dec 5, 2018 at 11:58 AM 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.
>>> 
>> 
>> That's what I feared, and that sucks. And I'm coming short as well of a
>> good alternative that don't require plugins.
>> That said, if push comes to shove, if we just make them free-form but
>> mandatory to get out of triage (with "all" and "none" being explicitly ok
>> values), and have a bit of documentation, there is still a good change
>> we'll get meaningful information out of this. Better than what we have at
>> least.
>> 
>> 
 - 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