Re: JIRA Workflow Proposals

[Aye Tun]

On 2018/11/26 13:39:50, Benedict Elliott Smith  wrote:
> We’ve concluded our efforts to produce a proposal for changes to the JIRA
workflow, and they can be found here:
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
<
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals>>

>
> I hope there will be broad consensus, but I’m sure it won’t be plain
sailing.  It would be great to get a discussion going around the proposal,
so please take some time to read and respond if you think you’ll have a
strong opinion on this topic.>
>
> There remains an undecided question in our initial proposal, that is
highlighted in the wiki.  Specifically, there was no seemingly objective
winner for the suggested changes to Component (though I have a preference,
that I will express in the ensuing discussion).>
>
> Other contentious issues may be:>
>  - The removal of ‘labels’ - which is very noisy, the vast majority of
which provide no value, and we expect can be superseded by other
suggestions>
>  - The introduction of required fields for certain transitions, some of
which are new (complexity, severity, bug/feature category)>
>  - The introduction of some new transitions (Triage, Review in Progress,
Change Requested)>
>
> Look forward to hearing your thoughts!>

Re: JIRA Workflow Proposals

[Sylvain Lebresne]

 to
> components (cf. folksonomy -> taxonomy<
> https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I
> hadn’t read the reply as indicating that labels should be zero’d out
> periodically. In any case, I agree that reviewing active labels and
> re-evaluating our taxonomy from time to time sounds great; I don’t think
> I’d zero them, though.
>
> Responding to a few comments:
>
> –––
>
> – To Joey’s question about issues languishing in Triage: I like the idea
> of an SLO for the “triage” state. I am happy to commit time and resources
> to triaging newly-reported issues, and to JIRA pruning/gardening in
> general. I spent part of the weekend before last adding components to a few
> hundred open issues and preparing the Confluence reports mentioned in the
> other thread. It was calming. We can also figure out how to rotate / share
> this responsibility.
>
> – Labels discussion: If we adopt a more structured component hierarchy to
> treat as our primary method of organization, keep labels around for people
> to use as they’d like (e.g., for custom JQL queries useful to their
> workflows), and periodically promote those that are widely useful, I think
> that sounds like a fine outcome.
>
> – On Sankalp’s question of issue reporter / new contributor burden: I
> actually think the pruning of fields on the “new issue form” makes
> reporting issues easier and ensures that information we need is captured.
> Having the triage step will also provide a nice task queue for screening
> bugs, and ensures a contributor’s taken a look + screened appropriately
> (rather than support requests immediately being marked “Critical/Blocker”
> and assigned a fix version by the reporter).
>
> – On Sankalp’s question of the non-committer’s workflow during first pass
> of review, I think that’s covered here:
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
>
> –––
>
> I also want to step back and thank Benedict and Kurt for all of their
> analysis and information architecture work behind this proposal. "Workflow
> and bug tracker hygiene” can be a thankless endeavor; I want to make sure
> this one’s not. Thank you both!
>
> If we’re nearing consensus on “keeping labels, and considering them for
> promotion to components periodically,” are there other items we need to
> resolve before we generally feel good about the changes?
>
> – Scott
>
>
> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith (
> bened...@apache.org<mailto:bened...@apache.org >)
> wrote:
>
> Hmm. On re-reading your earlier email, I realise I may have anyway gotten
> confused about your suggestion.
>
> Are you suggesting we periodically clear any new labels, once we have
> replacements, and only leave the old ones that exist today and haven’t been
> categorised?
>
>
> On 26 Nov 2018, at 23:02, Benedict Elliott Smith 
> wrote:
>
> Do we maintain a list of prior rejects? Revisit any that have increased in
> usage since last?
>
> Probably we’re bike shedding this one thing too closely. I would be happy
> with removing it, periodically cleaning it, or leaving it intact. Mining it
> for schema changes, or telling people to ask.
>
> But I fear it will all begin to go to pot again after this effort wanes,
> and my life has only one JIRA cleanup effort to call upon.
>
>
> On 26 Nov 2018, at 18:24, Joshua McKenzie  wrote:
>
> I'm thinking something like "Every 6 months, we query on labels with count
>
> = 4 and consider promoting those. Anything < that only shows if people are
>
> specifically looking for it."
>
> Taking count of occurrence of a label as a proxy for the potential value in
> promoting it to something hardened isn't without flaws, but it's also not
> awful IMO.
>
>
> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> Is there harm in leaving them in, aside from psychologically to all of us
> knowing they're there? =/
>
>
> It would at least make it easier to triage the ‘new' ones and promote
> them. The pain of actually categorising the labels was high, and doing
> that every time would mean it never happens (though maybe there are ways to
> work around this). I also think there’s value in shedding noisy data, in
> an active process to promote good hygiene.
>
> But who said our state of mind isn’t also important :)
>
> This isn’t something I’ll fight hard for, though, I can see it’s at least
> partially a preference for cleanliness. Interested to see what others
> think.
>
> On 26 Nov 2018, at 17:28, Joshua McKenzie  wrote:
>
>
> An alternative route might be to suppo

Re: JIRA Workflow Proposals

[jay.zhu...@yahoo.com.INVALID]

ink that sounds like a 
fine outcome.

– On Sankalp’s question of issue reporter / new contributor burden: I actually 
think the pruning of fields on the “new issue form” makes reporting issues 
easier and ensures that information we need is captured. Having the triage step 
will also provide a nice task queue for screening bugs, and ensures a 
contributor’s taken a look + screened appropriately (rather than support 
requests immediately being marked “Critical/Blocker” and assigned a fix version 
by the reporter).

– On Sankalp’s question of the non-committer’s workflow during first pass of 
review, I think that’s covered here: 
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow

–––

I also want to step back and thank Benedict and Kurt for all of their analysis 
and information architecture work behind this proposal. "Workflow and bug 
tracker hygiene” can be a thankless endeavor; I want to make sure this one’s 
not. Thank you both!

If we’re nearing consensus on “keeping labels, and considering them for 
promotion to components periodically,” are there other items we need to resolve 
before we generally feel good about the changes?

– Scott


On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith 
(bened...@apache.org<mailto:bened...@apache.org>) wrote:

Hmm. On re-reading your earlier email, I realise I may have anyway gotten 
confused about your suggestion.

Are you suggesting we periodically clear any new labels, once we have 
replacements, and only leave the old ones that exist today and haven’t been 
categorised?



On 26 Nov 2018, at 23:02, Benedict Elliott Smith  wrote:

Do we maintain a list of prior rejects? Revisit any that have increased in 
usage since last?

Probably we’re bike shedding this one thing too closely. I would be happy with 
removing it, periodically cleaning it, or leaving it intact. Mining it for 
schema changes, or telling people to ask.

But I fear it will all begin to go to pot again after this effort wanes, and my 
life has only one JIRA cleanup effort to call upon.



On 26 Nov 2018, at 18:24, Joshua McKenzie  wrote:

I'm thinking something like "Every 6 months, we query on labels with count

= 4 and consider promoting those. Anything < that only shows if people are

specifically looking for it."

Taking count of occurrence of a label as a proxy for the potential value in
promoting it to something hardened isn't without flaws, but it's also not
awful IMO.


On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith 
wrote:



Is there harm in leaving them in, aside from psychologically to all of us
knowing they're there? =/


It would at least make it easier to triage the ‘new' ones and promote
them. The pain of actually categorising the labels was high, and doing
that every time would mean it never happens (though maybe there are ways to
work around this). I also think there’s value in shedding noisy data, in
an active process to promote good hygiene.

But who said our state of mind isn’t also important :)

This isn’t something I’ll fight hard for, though, I can see it’s at least
partially a preference for cleanliness. Interested to see what others
think.


On 26 Nov 2018, at 17:28, Joshua McKenzie  wrote:



An alternative route might be to support labels, and (e.g.) bi-annually
promote any useful ones to the schema, and clear the rest?


+1 to promoting, probably should case-by-case the clearing (but mostly

just

clear)

The present labels are much too painful to clean up. I categorised the

top


100 or so, and will migrate them (there’s a CSV embedded in the proposal
you can look at). The rest have < 5 occurrences, so I cannot see what
value they really provide us.


Is there harm in leaving them in, aside from psychologically to all of us
knowing they're there? =/

I _think_ several of your concerns are addressed by the new Triage state.

The idea is for users to create a ticket without any field requirements.
Contributors should liaise with the user to understand the problem, and
transition it to Open.


Shit, my bad, totally missed / didn't grok that. That makes a lot more
sense.

On Mon, Nov 26, 2018 at 11:58 AM Benedict Elliott Smith <

bened...@apache.org>

wrote:


Sorry, I failed to respond to point (2) in the aggregate email.

I’m not sure it’s worth complicating the flow for this scenario, as the
ticket can simply return to ‘Patch Available’. But, I’m really unsure


of


the best option here. Does anyone else have any strong opinions /


thoughts?





On 26 Nov 2018, at 14:33, Sankalp Kohli 



wrote:




I have following initial comments on the proposal.
1. Creating a JIRA should have few fields mandatory like platform,

version, etc. We want to put less burden on someone creating a ticket


but I


feel these are required for opening bugs.


2. What is the flow when a non committer does the first pass of review?




On Nov 26, 2018, at 7:46 PM, Joshua McKenzie 


wr

Re: JIRA Workflow Proposals

[Ariel Weisberg]

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<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>).
> > >>>>>  I hadn’t read the reply as indicating that labels should be zero’d 
> > >>>>> out periodically. In any case, I agree that reviewing active labels 
> > >>>>> and re-evaluating our taxonomy from time to time sounds great; I 
> > >>>>> don’t think I’d zero them, though.
> > >>>>> 
> > >>>>> Responding to a few comments:
> > >>>>> 
> > >>>>> –––
> > >>>>> 
> > >>>>> – To Joey’s question about issues languishing in Triage: I like the 
> > >>>>> idea of an SLO for the “triage” state. I am happy to commit time and 
> > >>>>> resources to triaging newly-reported issues, and to JIRA 
> > >>>>> pruning/gardening in general. I spent part of the weekend before last 
> > >>>>> adding components to a few hundred open issues and preparing the 
> > >>>>> Confluence reports mentioned in the other thread. It was calming. We 
> > >>>>> can also figure out how to rotate / share this responsibility.
> > >>>>> 
> > >>>>> – Labels discussion: If we adopt a more structured component 
> > >>>>> hierarchy to treat as our primary method of organization, keep labels 
> > >>>>> around for people to use as they’d like (e.g., for custom JQL queries 
> > >>>>> useful to their workflows), and periodically promote those that are 
> > >>>>> widely useful, I think that sounds like a fine outcome.
> > >>>>> 
> > >>>>> – On Sankalp’s question of issue reporter / new contributor burden: I 
> > >>>>> actually think the pruning of fields on the “new issue form” makes 
> > >>>>> reporting issues easier and ensures that information we need is 
> > >>>>> captured. Having the triage step will also provide a nice task queue 
> > >>>>> for screening bugs, and ensures a contributor’s taken a look + 
> > >>>>> screened appropriately (rather than support requests immediately 
> > >>>>> being marked “Critical/Blocker” and assigned a fix version by the 
> > >>>>> reporter).
> > >>>>> 
> > >>>>> – On Sankalp’s question of the non-committer’s workflow during first 
> > >>>>> pass of review, I think that’s covered here: 
> > >>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
>

Re: JIRA Workflow Proposals

[Marcus Eriksson]

1. D C B A E
2. B C A
3. A
4. -0.5, leaning towards remove but don't really care

On Tue, Dec 11, 2018 at 06:42:09PM +, Aleksey Yeshchenko wrote:
> 1. C, D, A, B, E
> 2. B, C, A
> 3. A
> 4. Meh
> 
> > On 11 Dec 2018, at 16:28, Benedict Elliott Smith  
> > wrote:
> > 
> > Just to re-summarise the questions for people:
> > 
> > 1. (A) Only contributors may edit or transition issues; (B) Only 
> > contributors may transition issues; (C) Only Jira-users may transition 
> > issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as 
> > they are today
> > 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C) 
> > leave it.  Please rank.
> > 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation of 
> > why I chose Urgent 
> >  >  
> > >.
> > 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
> > 
> > With my answers (again, sorry):
> > 
> > 1: A B C D E
> > 2: B C A
> > 3: A
> > 4: +0.5
> > 
> >> On 11 Dec 2018, at 16:25, Benedict Elliott Smith  
> >> wrote:
> >> 
> >> It looks like we have a multiplicity of views on permissions, so perhaps 
> >> we should complicate this particular vote with all of the possible options 
> >> that have been raised so far (including one off-list).  Sorry everyone for 
> >> the confusion.
> >> 
> >> (A) Only contributors may edit or transition issues; (B) Only contributors 
> >> may transition issues; (C) Only Jira-users may transition issues*; (D) 
> >> (C)+Remove contributor role entirely; (E) Leave permission as they are 
> >> today
> >> 
> >> * Today apparently ‘Anyone’ can perform this operation
> >> 
> >> A ranked vote, please.  This makes my votes:
> >> 
> >> 1: A B C D E
> >> 2: B C A
> >> 3: A
> >> 4: +0.5
> >> 
> >> 
> >>> On 11 Dec 2018, at 05:51, Dinesh Joshi  
> >>> wrote:
> >>> 
> >>> I agree with this. I generally am on the side of freedom and 
> >>> responsibility. Limiting edits to certain fields turns people off. 
> >>> Something I want to very much avoid if we can. 
> >>> 
> >>> Dinesh
> >>> 
>  On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan 
>   wrote:
>  
>  On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>   wrote:
> > 
> >> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
> >> 
> >> Hi,
> >> 
> >> RE #1, does this mean if you submit a ticket and you are not a 
> >> contributor you can't modify any of the fields including description 
> >> or adding/removing attachments?
> > 
> > Attachment operations have their own permissions, like comments.  
> > Description would be prohibited though.  I don’t see this as a major 
> > problem, really; it is generally much more useful to add comments.  If 
> > we particularly want to make a subset of fields editable there is a 
> > workaround, though I’m not sure anybody would have the patience to 
> > implement it:  
> > https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
> >  
> > 
> > 
>  
>  That would be disappointing. Descriptions with broken or no formatting
>  aren't rare (say, command output without code formatting). And every
>  now and then the description might need to be updated. For example, in
>  https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
>  paper had rotted, but I managed to find a new one, so I could edit it
>  in. If such a change had to be posted as a comment, it might easily
>  get lost in some of the more active issues.
>  
>  -
>  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
> >>> 
> >> 
> >> 
> >> -
> >> 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
> 

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

Re: JIRA Workflow Proposals

[Sam Tunnicliffe]

1: D C B A E
2: B C A
3: A 
4: -1 (get rid of Wish entirely)

Thanks,
Sam


> On 11 Dec 2018, at 22:01, Joseph Lynch  wrote:
> 
> Just my 2c
> 
> 1. D C B E A
> 2. B, C, A
> 3. A
> 4. +0.5
> 
> -Joey
> 
> On Tue, Dec 11, 2018 at 8:28 AM Benedict Elliott Smith 
> wrote:
> 
>> Just to re-summarise the questions for people:
>> 
>> 1. (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
>> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C)
>> leave it.  Please rank.
>> 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation of
>> why I chose Urgent <
>> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
>> <
>> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
 .
>> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
>> 
>> With my answers (again, sorry):
>> 
>> 1: A B C D E
>> 2: B C A
>> 3: A
>> 4: +0.5
>> 
>>> On 11 Dec 2018, at 16:25, Benedict Elliott Smith 
>> wrote:
>>> 
>>> It looks like we have a multiplicity of views on permissions, so perhaps
>> we should complicate this particular vote with all of the possible options
>> that have been raised so far (including one off-list).  Sorry everyone for
>> the confusion.
>>> 
>>> (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
>>> 
>>> * Today apparently ‘Anyone’ can perform this operation
>>> 
>>> A ranked vote, please.  This makes my votes:
>>> 
>>> 1: A B C D E
>>> 2: B C A
>>> 3: A
>>> 4: +0.5
>>> 
>>> 
 On 11 Dec 2018, at 05:51, Dinesh Joshi 
>> wrote:
 
 I agree with this. I generally am on the side of freedom and
>> responsibility. Limiting edits to certain fields turns people off.
>> Something I want to very much avoid if we can.
 
 Dinesh
 
> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
>> murukesh.moha...@gmail.com> wrote:
> 
> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>  wrote:
>> 
>>> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
>>> 
>>> Hi,
>>> 
>>> RE #1, does this mean if you submit a ticket and you are not a
>> contributor you can't modify any of the fields including description or
>> adding/removing attachments?
>> 
>> Attachment operations have their own permissions, like comments.
>> Description would be prohibited though.  I don’t see this as a major
>> problem, really; it is generally much more useful to add comments.  If we
>> particularly want to make a subset of fields editable there is a
>> workaround, though I’m not sure anybody would have the patience to
>> implement it:
>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>> <
>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>>> 
>> 
> 
> That would be disappointing. Descriptions with broken or no formatting
> aren't rare (say, command output without code formatting). And every
> now and then the description might need to be updated. For example, in
> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
> paper had rotted, but I managed to find a new one, so I could edit it
> in. If such a change had to be posted as a comment, it might easily
> get lost in some of the more active issues.
> 
> -
> 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
 
>>> 
>>> 
>>> -
>>> 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

[Joseph Lynch]

Just my 2c

1. D C B E A
2. B, C, A
3. A
4. +0.5

-Joey

On Tue, Dec 11, 2018 at 8:28 AM Benedict Elliott Smith 
wrote:

> Just to re-summarise the questions for people:
>
> 1. (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users may transition
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C)
> leave it.  Please rank.
> 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation of
> why I chose Urgent <
> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
> <
> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
> >>.
> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
>
> With my answers (again, sorry):
>
> 1: A B C D E
> 2: B C A
> 3: A
> 4: +0.5
>
> > On 11 Dec 2018, at 16:25, Benedict Elliott Smith 
> wrote:
> >
> > It looks like we have a multiplicity of views on permissions, so perhaps
> we should complicate this particular vote with all of the possible options
> that have been raised so far (including one off-list).  Sorry everyone for
> the confusion.
> >
> > (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users may transition
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> >
> > * Today apparently ‘Anyone’ can perform this operation
> >
> > A ranked vote, please.  This makes my votes:
> >
> > 1: A B C D E
> > 2: B C A
> > 3: A
> > 4: +0.5
> >
> >
> >> On 11 Dec 2018, at 05:51, Dinesh Joshi 
> wrote:
> >>
> >> I agree with this. I generally am on the side of freedom and
> responsibility. Limiting edits to certain fields turns people off.
> Something I want to very much avoid if we can.
> >>
> >> Dinesh
> >>
> >>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
> murukesh.moha...@gmail.com> wrote:
> >>>
> >>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
> >>>  wrote:
> 
> > On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
> >
> > Hi,
> >
> > RE #1, does this mean if you submit a ticket and you are not a
> contributor you can't modify any of the fields including description or
> adding/removing attachments?
> 
>  Attachment operations have their own permissions, like comments.
> Description would be prohibited though.  I don’t see this as a major
> problem, really; it is generally much more useful to add comments.  If we
> particularly want to make a subset of fields editable there is a
> workaround, though I’m not sure anybody would have the patience to
> implement it:
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
> <
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
> >
> 
> >>>
> >>> That would be disappointing. Descriptions with broken or no formatting
> >>> aren't rare (say, command output without code formatting). And every
> >>> now and then the description might need to be updated. For example, in
> >>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
> >>> paper had rotted, but I managed to find a new one, so I could edit it
> >>> in. If such a change had to be posted as a comment, it might easily
> >>> get lost in some of the more active issues.
> >>>
> >>> -
> >>> 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
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>

Re: JIRA Workflow Proposals

[andre wilkinson]

Hey Benedict,
Thank you.

In that case
A D E B C

> On Dec 11, 2018, at 12:37 PM, Benedict Elliott Smith  
> wrote:
> 
> Hi Andre,
> 
> It’s ranked vote, i.e. for each question, what is your preference order for 
> the outcome?
> 
> So, for question 1, the possible outcomes are:
> 
> (A) Only contributors may edit or transition issues; 
> (B) Only contributors may transition issues; 
> (C) Only Jira-users may transition issues; 
> (D) (C)+Remove contributor role entirely; 
> (E) Leave permission as they are today
> 
> Sylvain’s vote was D C E B A, meaning he prefers option D first, option C 
> second, option E third, etc.
> 
> There are multiple ranked voting 
>  schemes, but unless anyone 
> objects I will resolve the answers with instant-runoff voting 
> , which is equivalent to 
> single transferable voting 
>  when there is only a 
> single outcome, as there is here.
> 
> 
>> On 11 Dec 2018, at 20:25, andre wilkinson  wrote:
>> 
>> Hey everyone,
>> Im just trying to keep up but I don’t think everyone needs permissions just 
>> contributors im trying to understand the letter voting system so I could 
>> better be of service to the community. Sorry if I sound naive. 
>> 
>>> On Dec 11, 2018, at 12:12 PM, Sylvain Lebresne  wrote:
>>> 
>>> 1: D C E B A (with a particularly strong feeling against A)
>>> 2: A B C
>>> 3: A (but don't mind much overall)
>>> 4: Don't mind (I neither particularly like 'wish' as a priority or issue
>>> type really)
>>> --
>>> Sylvain
>>> 
>>> 
>>> On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
>>>  wrote:
>>> 
 1. C, D, A, B, E
 2. B, C, A
 3. A
 4. Meh
 
> On 11 Dec 2018, at 16:28, Benedict Elliott Smith 
 wrote:
> 
> Just to re-summarise the questions for people:
> 
> 1. (A) Only contributors may edit or transition issues; (B) Only
 contributors may transition issues; (C) Only Jira-users may transition
 issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
 they are today
> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C)
 leave it.  Please rank.
> 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation
 of why I chose Urgent <
 https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
 <
 https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
>> .
> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
> 
> With my answers (again, sorry):
> 
> 1: A B C D E
> 2: B C A
> 3: A
> 4: +0.5
> 
>> On 11 Dec 2018, at 16:25, Benedict Elliott Smith 
 wrote:
>> 
>> It looks like we have a multiplicity of views on permissions, so
 perhaps we should complicate this particular vote with all of the possible
 options that have been raised so far (including one off-list).  Sorry
 everyone for the confusion.
>> 
>> (A) Only contributors may edit or transition issues; (B) Only
 contributors may transition issues; (C) Only Jira-users may transition
 issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
 they are today
>> 
>> * Today apparently ‘Anyone’ can perform this operation
>> 
>> A ranked vote, please.  This makes my votes:
>> 
>> 1: A B C D E
>> 2: B C A
>> 3: A
>> 4: +0.5
>> 
>> 
>>> On 11 Dec 2018, at 05:51, Dinesh Joshi 
 wrote:
>>> 
>>> I agree with this. I generally am on the side of freedom and
 responsibility. Limiting edits to certain fields turns people off.
 Something I want to very much avoid if we can.
>>> 
>>> Dinesh
>>> 
 On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
 murukesh.moha...@gmail.com> wrote:
 
 On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
  wrote:
> 
>> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
>> 
>> Hi,
>> 
>> RE #1, does this mean if you submit a ticket and you are not a
 contributor you can't modify any of the fields including description or
 adding/removing attachments?
> 
> Attachment operations have their own permissions, like comments.
 Description would be prohibited though.  I don’t see this as a major
 problem, really; it is generally much more useful to add comments.  If we
 particularly want to make a subset of fields editable there is a
 workaround, though I’m not sure anybody would have the patience to
 implement it:
 https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
 <
 

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

Hi Andre,

It’s ranked vote, i.e. for each question, what is your preference order for the 
outcome?

So, for question 1, the possible outcomes are:

(A) Only contributors may edit or transition issues; 
(B) Only contributors may transition issues; 
(C) Only Jira-users may transition issues; 
(D) (C)+Remove contributor role entirely; 
(E) Leave permission as they are today

Sylvain’s vote was D C E B A, meaning he prefers option D first, option C 
second, option E third, etc.

There are multiple ranked voting  
schemes, but unless anyone objects I will resolve the answers with 
instant-runoff voting , 
which is equivalent to single transferable voting 
 when there is only a 
single outcome, as there is here.


> On 11 Dec 2018, at 20:25, andre wilkinson  wrote:
> 
> Hey everyone,
> Im just trying to keep up but I don’t think everyone needs permissions just 
> contributors im trying to understand the letter voting system so I could 
> better be of service to the community. Sorry if I sound naive. 
> 
>> On Dec 11, 2018, at 12:12 PM, Sylvain Lebresne  wrote:
>> 
>> 1: D C E B A (with a particularly strong feeling against A)
>> 2: A B C
>> 3: A (but don't mind much overall)
>> 4: Don't mind (I neither particularly like 'wish' as a priority or issue
>> type really)
>> --
>> Sylvain
>> 
>> 
>> On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
>>  wrote:
>> 
>>> 1. C, D, A, B, E
>>> 2. B, C, A
>>> 3. A
>>> 4. Meh
>>> 
 On 11 Dec 2018, at 16:28, Benedict Elliott Smith 
>>> wrote:
 
 Just to re-summarise the questions for people:
 
 1. (A) Only contributors may edit or transition issues; (B) Only
>>> contributors may transition issues; (C) Only Jira-users may transition
>>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>>> they are today
 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C)
>>> leave it.  Please rank.
 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation
>>> of why I chose Urgent <
>>> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
>>> <
>>> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
> .
 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
 
 With my answers (again, sorry):
 
 1: A B C D E
 2: B C A
 3: A
 4: +0.5
 
> On 11 Dec 2018, at 16:25, Benedict Elliott Smith 
>>> wrote:
> 
> It looks like we have a multiplicity of views on permissions, so
>>> perhaps we should complicate this particular vote with all of the possible
>>> options that have been raised so far (including one off-list).  Sorry
>>> everyone for the confusion.
> 
> (A) Only contributors may edit or transition issues; (B) Only
>>> contributors may transition issues; (C) Only Jira-users may transition
>>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>>> they are today
> 
> * Today apparently ‘Anyone’ can perform this operation
> 
> A ranked vote, please.  This makes my votes:
> 
> 1: A B C D E
> 2: B C A
> 3: A
> 4: +0.5
> 
> 
>> On 11 Dec 2018, at 05:51, Dinesh Joshi 
>>> wrote:
>> 
>> I agree with this. I generally am on the side of freedom and
>>> responsibility. Limiting edits to certain fields turns people off.
>>> Something I want to very much avoid if we can.
>> 
>> Dinesh
>> 
>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
>>> murukesh.moha...@gmail.com> wrote:
>>> 
>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>>  wrote:
 
> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
> 
> Hi,
> 
> RE #1, does this mean if you submit a ticket and you are not a
>>> contributor you can't modify any of the fields including description or
>>> adding/removing attachments?
 
 Attachment operations have their own permissions, like comments.
>>> Description would be prohibited though.  I don’t see this as a major
>>> problem, really; it is generally much more useful to add comments.  If we
>>> particularly want to make a subset of fields editable there is a
>>> workaround, though I’m not sure anybody would have the patience to
>>> implement it:
>>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>>> <
>>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
 
 
>>> 
>>> That would be disappointing. Descriptions with broken or no formatting
>>> aren't rare (say, command output without code formatting). And every
>>> now and then the description 

Re: JIRA Workflow Proposals

[andre wilkinson]

Hey everyone,
Im just trying to keep up but I don’t think everyone needs permissions just 
contributors im trying to understand the letter voting system so I could better 
be of service to the community. Sorry if I sound naive. 

> On Dec 11, 2018, at 12:12 PM, Sylvain Lebresne  wrote:
> 
> 1: D C E B A (with a particularly strong feeling against A)
> 2: A B C
> 3: A (but don't mind much overall)
> 4: Don't mind (I neither particularly like 'wish' as a priority or issue
> type really)
> --
> Sylvain
> 
> 
> On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
>  wrote:
> 
>> 1. C, D, A, B, E
>> 2. B, C, A
>> 3. A
>> 4. Meh
>> 
>>> On 11 Dec 2018, at 16:28, Benedict Elliott Smith 
>> wrote:
>>> 
>>> Just to re-summarise the questions for people:
>>> 
>>> 1. (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
>>> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C)
>> leave it.  Please rank.
>>> 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation
>> of why I chose Urgent <
>> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
>> <
>> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
 .
>>> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
>>> 
>>> With my answers (again, sorry):
>>> 
>>> 1: A B C D E
>>> 2: B C A
>>> 3: A
>>> 4: +0.5
>>> 
 On 11 Dec 2018, at 16:25, Benedict Elliott Smith 
>> wrote:
 
 It looks like we have a multiplicity of views on permissions, so
>> perhaps we should complicate this particular vote with all of the possible
>> options that have been raised so far (including one off-list).  Sorry
>> everyone for the confusion.
 
 (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
 
 * Today apparently ‘Anyone’ can perform this operation
 
 A ranked vote, please.  This makes my votes:
 
 1: A B C D E
 2: B C A
 3: A
 4: +0.5
 
 
> On 11 Dec 2018, at 05:51, Dinesh Joshi 
>> wrote:
> 
> I agree with this. I generally am on the side of freedom and
>> responsibility. Limiting edits to certain fields turns people off.
>> Something I want to very much avoid if we can.
> 
> Dinesh
> 
>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
>> murukesh.moha...@gmail.com> wrote:
>> 
>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>  wrote:
>>> 
 On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
 
 Hi,
 
 RE #1, does this mean if you submit a ticket and you are not a
>> contributor you can't modify any of the fields including description or
>> adding/removing attachments?
>>> 
>>> Attachment operations have their own permissions, like comments.
>> Description would be prohibited though.  I don’t see this as a major
>> problem, really; it is generally much more useful to add comments.  If we
>> particularly want to make a subset of fields editable there is a
>> workaround, though I’m not sure anybody would have the patience to
>> implement it:
>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>> <
>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>>> 
>>> 
>> 
>> That would be disappointing. Descriptions with broken or no formatting
>> aren't rare (say, command output without code formatting). And every
>> now and then the description might need to be updated. For example, in
>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to
>> the
>> paper had rotted, but I managed to find a new one, so I could edit it
>> in. If such a change had to be posted as a comment, it might easily
>> get lost in some of the more active issues.
>> 
>> -
>> 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
> 
 
 
 -
 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.  To clarify, a negative result for Q4 had intended to be interpreted as 
the elimination of ‘Wish’ entirely; nobody has indicated any love for the Wish 
issue type as yet, so not replacing it would mean it disappears.  That is, 
unless there are several strong sentiments otherwise.

It sounds like you may have meant to indicate -1, but not sure.


> On 11 Dec 2018, at 20:12, Sylvain Lebresne  wrote:
> 
> 1: D C E B A (with a particularly strong feeling against A)
> 2: A B C
> 3: A (but don't mind much overall)
> 4: Don't mind (I neither particularly like 'wish' as a priority or issue
> type really)
> --
> Sylvain
> 
> 
> On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
>  wrote:
> 
>> 1. C, D, A, B, E
>> 2. B, C, A
>> 3. A
>> 4. Meh
>> 
>>> On 11 Dec 2018, at 16:28, Benedict Elliott Smith 
>> wrote:
>>> 
>>> Just to re-summarise the questions for people:
>>> 
>>> 1. (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
>>> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C)
>> leave it.  Please rank.
>>> 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation
>> of why I chose Urgent <
>> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
>> <
>> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
 .
>>> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
>>> 
>>> With my answers (again, sorry):
>>> 
>>> 1: A B C D E
>>> 2: B C A
>>> 3: A
>>> 4: +0.5
>>> 
 On 11 Dec 2018, at 16:25, Benedict Elliott Smith 
>> wrote:
 
 It looks like we have a multiplicity of views on permissions, so
>> perhaps we should complicate this particular vote with all of the possible
>> options that have been raised so far (including one off-list).  Sorry
>> everyone for the confusion.
 
 (A) Only contributors may edit or transition issues; (B) Only
>> contributors may transition issues; (C) Only Jira-users may transition
>> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
>> they are today
 
 * Today apparently ‘Anyone’ can perform this operation
 
 A ranked vote, please.  This makes my votes:
 
 1: A B C D E
 2: B C A
 3: A
 4: +0.5
 
 
> On 11 Dec 2018, at 05:51, Dinesh Joshi 
>> wrote:
> 
> I agree with this. I generally am on the side of freedom and
>> responsibility. Limiting edits to certain fields turns people off.
>> Something I want to very much avoid if we can.
> 
> Dinesh
> 
>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
>> murukesh.moha...@gmail.com> wrote:
>> 
>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>  wrote:
>>> 
 On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
 
 Hi,
 
 RE #1, does this mean if you submit a ticket and you are not a
>> contributor you can't modify any of the fields including description or
>> adding/removing attachments?
>>> 
>>> Attachment operations have their own permissions, like comments.
>> Description would be prohibited though.  I don’t see this as a major
>> problem, really; it is generally much more useful to add comments.  If we
>> particularly want to make a subset of fields editable there is a
>> workaround, though I’m not sure anybody would have the patience to
>> implement it:
>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>> <
>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>>> 
>>> 
>> 
>> That would be disappointing. Descriptions with broken or no formatting
>> aren't rare (say, command output without code formatting). And every
>> now and then the description might need to be updated. For example, in
>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to
>> the
>> paper had rotted, but I managed to find a new one, so I could edit it
>> in. If such a change had to be posted as a comment, it might easily
>> get lost in some of the more active issues.
>> 
>> -
>> 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
> 
 
 
 -
 To unsubscribe, e-mail: 

Re: JIRA Workflow Proposals

[Sylvain Lebresne]

1: D C E B A (with a particularly strong feeling against A)
2: A B C
3: A (but don't mind much overall)
4: Don't mind (I neither particularly like 'wish' as a priority or issue
type really)
--
Sylvain


On Tue, Dec 11, 2018 at 7:42 PM Aleksey Yeshchenko
 wrote:

> 1. C, D, A, B, E
> 2. B, C, A
> 3. A
> 4. Meh
>
> > On 11 Dec 2018, at 16:28, Benedict Elliott Smith 
> wrote:
> >
> > Just to re-summarise the questions for people:
> >
> > 1. (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users may transition
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> > 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C)
> leave it.  Please rank.
> > 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation
> of why I chose Urgent <
> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
> <
> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
> >>.
> > 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
> >
> > With my answers (again, sorry):
> >
> > 1: A B C D E
> > 2: B C A
> > 3: A
> > 4: +0.5
> >
> >> On 11 Dec 2018, at 16:25, Benedict Elliott Smith 
> wrote:
> >>
> >> It looks like we have a multiplicity of views on permissions, so
> perhaps we should complicate this particular vote with all of the possible
> options that have been raised so far (including one off-list).  Sorry
> everyone for the confusion.
> >>
> >> (A) Only contributors may edit or transition issues; (B) Only
> contributors may transition issues; (C) Only Jira-users may transition
> issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as
> they are today
> >>
> >> * Today apparently ‘Anyone’ can perform this operation
> >>
> >> A ranked vote, please.  This makes my votes:
> >>
> >> 1: A B C D E
> >> 2: B C A
> >> 3: A
> >> 4: +0.5
> >>
> >>
> >>> On 11 Dec 2018, at 05:51, Dinesh Joshi 
> wrote:
> >>>
> >>> I agree with this. I generally am on the side of freedom and
> responsibility. Limiting edits to certain fields turns people off.
> Something I want to very much avoid if we can.
> >>>
> >>> Dinesh
> >>>
>  On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan <
> murukesh.moha...@gmail.com> wrote:
> 
>  On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>   wrote:
> >
> >> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
> >>
> >> Hi,
> >>
> >> RE #1, does this mean if you submit a ticket and you are not a
> contributor you can't modify any of the fields including description or
> adding/removing attachments?
> >
> > Attachment operations have their own permissions, like comments.
> Description would be prohibited though.  I don’t see this as a major
> problem, really; it is generally much more useful to add comments.  If we
> particularly want to make a subset of fields editable there is a
> workaround, though I’m not sure anybody would have the patience to
> implement it:
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
> <
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
> >
> >
> 
>  That would be disappointing. Descriptions with broken or no formatting
>  aren't rare (say, command output without code formatting). And every
>  now and then the description might need to be updated. For example, in
>  https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to
> the
>  paper had rotted, but I managed to find a new one, so I could edit it
>  in. If such a change had to be posted as a comment, it might easily
>  get lost in some of the more active issues.
> 
>  -
>  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
> >>>
> >>
> >>
> >> -
> >> 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

[Aleksey Yeshchenko]

1. C, D, A, B, E
2. B, C, A
3. A
4. Meh

> On 11 Dec 2018, at 16:28, Benedict Elliott Smith  wrote:
> 
> Just to re-summarise the questions for people:
> 
> 1. (A) Only contributors may edit or transition issues; (B) Only contributors 
> may transition issues; (C) Only Jira-users may transition issues*; (D) 
> (C)+Remove contributor role entirely; (E) Leave permission as they are today
> 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C) leave 
> it.  Please rank.
> 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation of why 
> I chose Urgent 
>   
> >.
> 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
> 
> With my answers (again, sorry):
> 
> 1: A B C D E
> 2: B C A
> 3: A
> 4: +0.5
> 
>> On 11 Dec 2018, at 16:25, Benedict Elliott Smith  wrote:
>> 
>> It looks like we have a multiplicity of views on permissions, so perhaps we 
>> should complicate this particular vote with all of the possible options that 
>> have been raised so far (including one off-list).  Sorry everyone for the 
>> confusion.
>> 
>> (A) Only contributors may edit or transition issues; (B) Only contributors 
>> may transition issues; (C) Only Jira-users may transition issues*; (D) 
>> (C)+Remove contributor role entirely; (E) Leave permission as they are today
>> 
>> * Today apparently ‘Anyone’ can perform this operation
>> 
>> A ranked vote, please.  This makes my votes:
>> 
>> 1: A B C D E
>> 2: B C A
>> 3: A
>> 4: +0.5
>> 
>> 
>>> On 11 Dec 2018, at 05:51, Dinesh Joshi  
>>> wrote:
>>> 
>>> I agree with this. I generally am on the side of freedom and 
>>> responsibility. Limiting edits to certain fields turns people off. 
>>> Something I want to very much avoid if we can. 
>>> 
>>> Dinesh
>>> 
 On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan  
 wrote:
 
 On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
  wrote:
> 
>> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
>> 
>> Hi,
>> 
>> RE #1, does this mean if you submit a ticket and you are not a 
>> contributor you can't modify any of the fields including description or 
>> adding/removing attachments?
> 
> Attachment operations have their own permissions, like comments.  
> Description would be prohibited though.  I don’t see this as a major 
> problem, really; it is generally much more useful to add comments.  If we 
> particularly want to make a subset of fields editable there is a 
> workaround, though I’m not sure anybody would have the patience to 
> implement it:  
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>  
> 
> 
 
 That would be disappointing. Descriptions with broken or no formatting
 aren't rare (say, command output without code formatting). And every
 now and then the description might need to be updated. For example, in
 https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
 paper had rotted, but I managed to find a new one, so I could edit it
 in. If such a change had to be posted as a comment, it might easily
 get lost in some of the more active issues.
 
 -
 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
>>> 
>> 
>> 
>> -
>> 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]

Just to re-summarise the questions for people:

1. (A) Only contributors may edit or transition issues; (B) Only contributors 
may transition issues; (C) Only Jira-users may transition issues*; (D) 
(C)+Remove contributor role entirely; (E) Leave permission as they are today
2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C) leave 
it.  Please rank.
3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation of why I 
chose Urgent 
>.
4. Priority keep ‘Wish’ (to replace issue type): +1/-1

With my answers (again, sorry):

1: A B C D E
2: B C A
3: A
4: +0.5

> On 11 Dec 2018, at 16:25, Benedict Elliott Smith  wrote:
> 
> It looks like we have a multiplicity of views on permissions, so perhaps we 
> should complicate this particular vote with all of the possible options that 
> have been raised so far (including one off-list).  Sorry everyone for the 
> confusion.
> 
> (A) Only contributors may edit or transition issues; (B) Only contributors 
> may transition issues; (C) Only Jira-users may transition issues*; (D) 
> (C)+Remove contributor role entirely; (E) Leave permission as they are today
> 
> * Today apparently ‘Anyone’ can perform this operation
> 
> A ranked vote, please.  This makes my votes:
> 
> 1: A B C D E
> 2: B C A
> 3: A
> 4: +0.5
> 
> 
>> On 11 Dec 2018, at 05:51, Dinesh Joshi  
>> wrote:
>> 
>> I agree with this. I generally am on the side of freedom and responsibility. 
>> Limiting edits to certain fields turns people off. Something I want to very 
>> much avoid if we can. 
>> 
>> Dinesh
>> 
>>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan  
>>> wrote:
>>> 
>>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>>  wrote:
 
> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
> 
> Hi,
> 
> RE #1, does this mean if you submit a ticket and you are not a 
> contributor you can't modify any of the fields including description or 
> adding/removing attachments?
 
 Attachment operations have their own permissions, like comments.  
 Description would be prohibited though.  I don’t see this as a major 
 problem, really; it is generally much more useful to add comments.  If we 
 particularly want to make a subset of fields editable there is a 
 workaround, though I’m not sure anybody would have the patience to 
 implement it:  
 https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
  
 
 
>>> 
>>> That would be disappointing. Descriptions with broken or no formatting
>>> aren't rare (say, command output without code formatting). And every
>>> now and then the description might need to be updated. For example, in
>>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
>>> paper had rotted, but I managed to find a new one, so I could edit it
>>> in. If such a change had to be posted as a comment, it might easily
>>> get lost in some of the more active issues.
>>> 
>>> -
>>> 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
>> 
> 
> 
> -
> 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]

It looks like we have a multiplicity of views on permissions, so perhaps we 
should complicate this particular vote with all of the possible options that 
have been raised so far (including one off-list).  Sorry everyone for the 
confusion.

(A) Only contributors may edit or transition issues; (B) Only contributors may 
transition issues; (C) Only Jira-users may transition issues*; (D) (C)+Remove 
contributor role entirely; (E) Leave permission as they are today

* Today apparently ‘Anyone’ can perform this operation

A ranked vote, please.  This makes my votes:

1: A B C D E
2: B C A
3: A
4: +0.5


> On 11 Dec 2018, at 05:51, Dinesh Joshi  wrote:
> 
> I agree with this. I generally am on the side of freedom and responsibility. 
> Limiting edits to certain fields turns people off. Something I want to very 
> much avoid if we can. 
> 
> Dinesh
> 
>> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan  
>> wrote:
>> 
>> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>>  wrote:
>>> 
 On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
 
 Hi,
 
 RE #1, does this mean if you submit a ticket and you are not a contributor 
 you can't modify any of the fields including description or 
 adding/removing attachments?
>>> 
>>> Attachment operations have their own permissions, like comments.  
>>> Description would be prohibited though.  I don’t see this as a major 
>>> problem, really; it is generally much more useful to add comments.  If we 
>>> particularly want to make a subset of fields editable there is a 
>>> workaround, though I’m not sure anybody would have the patience to 
>>> implement it:  
>>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>>>  
>>> 
>>> 
>> 
>> That would be disappointing. Descriptions with broken or no formatting
>> aren't rare (say, command output without code formatting). And every
>> now and then the description might need to be updated. For example, in
>> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
>> paper had rotted, but I managed to find a new one, so I could edit it
>> in. If such a change had to be posted as a comment, it might easily
>> get lost in some of the more active issues.
>> 
>> -
>> 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
> 


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

Re: JIRA Workflow Proposals

[Ariel Weisberg]

 >>>> 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<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>).
> >>>>>  I hadn’t read the reply as indicating that labels should be zero’d out 
> >>>>> periodically. In any case, I agree that reviewing active labels and 
> >>>>> re-evaluating our taxonomy from time to time sounds great; I don’t 
> >>>>> think I’d zero them, though.
> >>>>> 
> >>>>> Responding to a few comments:
> >>>>> 
> >>>>> –––
> >>>>> 
> >>>>> – To Joey’s question about issues languishing in Triage: I like the 
> >>>>> idea of an SLO for the “triage” state. I am happy to commit time and 
> >>>>> resources to triaging newly-reported issues, and to JIRA 
> >>>>> pruning/gardening in general. I spent part of the weekend before last 
> >>>>> adding components to a few hundred open issues and preparing the 
> >>>>> Confluence reports mentioned in the other thread. It was calming. We 
> >>>>> can also figure out how to rotate / share this responsibility.
> >>>>> 
> >>>>> – Labels discussion: If we adopt a more structured component hierarchy 
> >>>>> to treat as our primary method of organization, keep labels around for 
> >>>>> people to use as they’d like (e.g., for custom JQL queries useful to 
> >>>>> their workflows), and periodically promote those that are widely 
> >>>>> useful, I think that sounds like a fine outcome.
> >>>>> 
> >>>>> – On Sankalp’s question of issue reporter / new contributor burden: I 
> >>>>> actually think the pruning of fields on the “new issue form” makes 
> >>>>> reporting issues easier and ensures that information we need is 
> >>>>> captured. Having the triage step will also provide a nice task queue 
> >>>>> for screening bugs, and ensures a contributor’s taken a look + screened 
> >>>>> appropriately (rather than support requests immediately being marked 
> >>>>> “Critical/Blocker” and assigned a fix version by the reporter).
> >>>>> 
> >>>>> – On Sankalp’s question of the non-committer’s workflow during first 
> >>>>> pass of review, I think that’s covered here: 
> >>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
> >>>>> 
> >>>>> –––
> >>>>> 
> >>>>> I also want to step back and thank Benedict and Kurt for all of their 
> >>>>> analysis and information architecture work behind this proposal. 
> >>>>> "Workflow and bug tracker hygiene” can be a thankless endeavor; I want 
> >>>>> to make sure this one’s not. Thank you both!
> >>>>> 
> >>>>> If we’re nearing consensus on “keeping labels, and considering them for 
> >>>>> promotion to components periodically,” are there other items we need to 
> >>>>> resolve before we generally feel good about the changes?
> >>>>> 
> >>>>> – Scott
> >>>>> 
> >>>>> 
> >>>>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith 
> >>>>> (bened...@apache.org<mailto:bened...@apache.org>) wrote:
> >>>>> 
> >>>>> Hmm. On re-reading your earlier email, I realise I may have anyway 
> >>>>> gotten confused about your suggestion.
> >>>>> 
> >>>>> Are you suggesting we periodically clear any new labels, once we have 
> >>>>> replacements, and only leave the old ones that exist today and haven’t 
> >>>>> been categorised?
> >>>>> 
> >>>>> 
> >>>>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith  
> >>>>>> wrote:
> >>>>>> 
> >>>>>> Do we maintain a list of prior

Re: JIRA Workflow Proposals

[Dinesh Joshi]

I agree with this. I generally am on the side of freedom and responsibility. 
Limiting edits to certain fields turns people off. Something I want to very 
much avoid if we can. 

Dinesh

> On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan  
> wrote:
> 
> On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>  wrote:
>> 
>>> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
>>> 
>>> Hi,
>>> 
>>> RE #1, does this mean if you submit a ticket and you are not a contributor 
>>> you can't modify any of the fields including description or adding/removing 
>>> attachments?
>> 
>> Attachment operations have their own permissions, like comments.  
>> Description would be prohibited though.  I don’t see this as a major 
>> problem, really; it is generally much more useful to add comments.  If we 
>> particularly want to make a subset of fields editable there is a workaround, 
>> though I’m not sure anybody would have the patience to implement it:  
>> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>>  
>> 
>> 
> 
> That would be disappointing. Descriptions with broken or no formatting
> aren't rare (say, command output without code formatting). And every
> now and then the description might need to be updated. For example, in
> https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
> paper had rotted, but I managed to find a new one, so I could edit it
> in. If such a change had to be posted as a comment, it might easily
> get lost in some of the more active issues.
> 
> -
> 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

[Murukesh Mohanan]

On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
 wrote:
>
> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
> >
> > Hi,
> >
> > RE #1, does this mean if you submit a ticket and you are not a contributor 
> > you can't modify any of the fields including description or adding/removing 
> > attachments?
>
> Attachment operations have their own permissions, like comments.  Description 
> would be prohibited though.  I don’t see this as a major problem, really; it 
> is generally much more useful to add comments.  If we particularly want to 
> make a subset of fields editable there is a workaround, though I’m not sure 
> anybody would have the patience to implement it:  
> https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
>  
> 
>

That would be disappointing. Descriptions with broken or no formatting
aren't rare (say, command output without code formatting). And every
now and then the description might need to be updated. For example, in
https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
paper had rotted, but I managed to find a new one, so I could edit it
in. If such a change had to be posted as a comment, it might easily
get lost in some of the more active issues.

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

t; structured. How often do we search or require structure on this field?
>>> 
>>> Ariel
>>> 
>>> On Tue, Dec 4, 2018, at 2: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. folksonomy -> 
>>>>> taxonomy<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>).
>>>>>  I hadn’t read the reply as indicating that labels should be zero’d out 
>>>>> periodically. In any case, I agree that reviewing active labels and 
>>>>> re-evaluating our taxonomy from time to time sounds great; I don’t think 
>>>>> I’d zero them, though.
>>>>> 
>>>>> Responding to a few comments:
>>>>> 
>>>>> –––
>>>>> 
>>>>> – To Joey’s question about issues languishing in Triage: I like the idea 
>>>>> of an SLO for the “triage” state. I am happy to commit time and resources 
>>>>> to triaging newly-reported issues, and to JIRA pruning/gardening in 
>>>>> general. I spent part of the weekend before last adding components to a 
>>>>> few hundred open issues and preparing the Confluence reports mentioned in 
>>>>> the other thread. It was calming. We can also figure out h

Re: JIRA Workflow Proposals

[Ariel Weisberg]

 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<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>).
> >>>  I hadn’t read the reply as indicating that labels should be zero’d out 
> >>> periodically. In any case, I agree that reviewing active labels and 
> >>> re-evaluating our taxonomy from time to time sounds great; I don’t think 
> >>> I’d zero them, though.
> >>> 
> >>> Responding to a few comments:
> >>> 
> >>> –––
> >>> 
> >>> – To Joey’s question about issues languishing in Triage: I like the idea 
> >>> of an SLO for the “triage” state. I am happy to commit time and resources 
> >>> to triaging newly-reported issues, and to JIRA pruning/gardening in 
> >>> general. I spent part of the weekend before last adding components to a 
> >>> few hundred open issues and preparing the Confluence reports mentioned in 
> >>> the other thread. It was calming. We can also figure out how to rotate / 
> >>> share this responsibility.
> >>> 
> >>> – Labels discussion: If we adopt a more structured component hierarchy to 
> >>> treat as our primary method of organization, keep labels around for 
> >>> people to use as they’d like (e.g., for custom JQL queries useful to 
> >>> their workflows), and periodically promote those that are widely useful, 
> >>> I think that sounds like a fine outcome.
> >>> 
> >>> – On Sankalp’s question of issue reporter / new contributor burden: I 
> >>> actually think the pruning of fields on the “new issue form” makes 
> >>> reporting issues easier and ensures that information we need is captured. 
> >>> Having the triage step will also provide a nice task queue for screening 
> >>> bugs, and ensures a contributor’s taken a look + screened appropriately 
> >>> (rather than support requests immediately being marked “Critical/Blocker” 
> >>> and assigned a fix version by the reporter).
> >>> 
> >>> – On Sankalp’s question of the non-committer’s workflow during first pass 
> >>> of review, I think that’s covered here: 
> >>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
> >>> 
> >>> –––
> >>> 
> >>> I also want to step back and thank Benedict and Kurt for all of their 
> >>> analysis and information architecture work behind this proposal. 
> >>> "Workflow and bug tracker hygiene” can be a thankless endeavor; 

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

s 
>> 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<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>).
>>>  I hadn’t read the reply as indicating that labels should be zero’d out 
>>> periodically. In any case, I agree that reviewing active labels and 
>>> re-evaluating our taxonomy from time to time sounds great; I don’t think 
>>> I’d zero them, though.
>>> 
>>> Responding to a few comments:
>>> 
>>> –––
>>> 
>>> – To Joey’s question about issues languishing in Triage: I like the idea of 
>>> an SLO for the “triage” state. I am happy to commit time and resources to 
>>> triaging newly-reported issues, and to JIRA pruning/gardening in general. I 
>>> spent part of the weekend before last adding components to a few hundred 
>>> open issues and preparing the Confluence reports mentioned in the other 
>>> thread. It was calming. We can also figure out how to rotate / share this 
>>> responsibility.
>>> 
>>> – Labels discussion: If we adopt a more structured component hierarchy to 
>>> treat as our primary method of organization, keep labels around for people 
>>> to use as they’d like (e.g., for custom JQL queries useful to their 
>>> workflows), and periodically promote those that are widely useful, I think 
>>> that sounds like a fine outcome.
>>> 
>>> – On Sankalp’s question of issue reporter / new contributor burden: I 
>>> actually think the pruning of fields on the “new issue form” makes 
>>> reporting issues easier and ensures that information we need is captured. 
>>> Having the triage step will also provide a nice task queue for screening 
>>> bugs, and ensures a contributor’s taken a look + screened appropriately 
>>> (rather than support requests immediately being marked “Critical/Blocker” 
>>> and assigned a fix version by the reporter).
>>> 
>>> – On Sankalp’s question of the non-committer’s workflow during first pass 
>>> of review, I think that’s covered here: 
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
>>> 
>>> –––
>>> 
>>> I also want to step back and thank Benedict and Kurt for all of their 
>>> analysis and information architecture work behind this proposal. "Workflow 
>>> and bug tracker hygiene” can be a thankless endeavor; I want to make sure 
>>> this one’s not. Thank you both!
>>> 
>>> If we’re nearing consensus on “keeping labels, and considering them for 
>>> promotion to components periodically,” are there other items we need to 
>>> resolve before we generally feel good about the changes?
>>> 
>>> – Scott
>>> 
>>> 
>>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith 
>>> (bened...@apache.org<mailto:bened...@apache.org>) wrote:
>>> 
>>> Hmm. On re-reading your earlier email, I realise I may have anyway gotten 
>>> confused about your suggestion.
>>> 
>>> Are you suggesting we periodically clear any new labels, once we have 
>>> replacements, and only leave the old ones that exist today and haven’t been 
>>> categorised?
>>> 
>>> 
>>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith  
>>>> wrote:
>>>> 
>>>> Do we maintain a list of prior rejects? Revisit any that have increased in 
>>>> usage since last?
>>>> 
>>>> Probably we’re bike shedding this one thing too closely. I would be happy 
>>>> with removing it, periodically cleaning it, or leaving it intact. Mining 
>>>> it for schema changes, or telling people to ask.
>>>> 
>>>> But I fear it will a

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

The “Impact” field idea sounds like a good potential follow-up discussion.  I’d 
prefer not to complicate this process when we’re seemingly nearing consensus, 
particularly as I’m not personally sure what form such a field would take.  But 
it would be a relatively small modification, if you want to come up with a 
proposal when we’ve finished modifying JIRA with whatever consensus we reach 
here.  Does that sound reasonable?

Similarly, the CIP process is something I think we need to drive a separate 
discussion on, similar to this one.  It’s a huge rabbit hole that could easily 
derail this discussion.


> On 9 Dec 2018, at 03:03, Mick Semb Wever  wrote:
> 
> 
> 
>> Of course, if we remove Priority from the Bug type, I agree with others 
>> that the top level priority ceases to mean anything, and there probably 
>> shouldn’t be one.
> 
> 
> Benedict, another idea, and this might be for down the road, is to have 
> "Severity" or bug types and "Impact" on non-bug types. Removing everywhere 
> the need for a subjective Priority field. Such an "Impact" field would permit 
> more descriptive values for improvements and features. We can also add some 
> documentation as to what qualifies for the different values to both Severity 
> and Impact. 
> 
> And on the topic of Feature types, what are people's thoughts on the 
> "Cassandra improvement Proposal" written up at 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
> 
> If we agree on this then can we have a (mandatory) field on Feature for the 
> CIP? If people are entering requests for new Features then shouldn't they 
> also be willing to do some homework and write up a CIP?
> 
> 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

[Mick Semb Wever]

> Of course, if we remove Priority from the Bug type, I agree with others 
> that the top level priority ceases to mean anything, and there probably 
> shouldn’t be one.


Benedict, another idea, and this might be for down the road, is to have 
"Severity" or bug types and "Impact" on non-bug types. Removing everywhere the 
need for a subjective Priority field. Such an "Impact" field would permit more 
descriptive values for improvements and features. We can also add some 
documentation as to what qualifies for the different values to both Severity 
and Impact. 

And on the topic of Feature types, what are people's thoughts on the "Cassandra 
improvement Proposal" written up at 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201

If we agree on this then can we have a (mandatory) field on Feature for the 
CIP? If people are entering requests for new Features then shouldn't they also 
be willing to do some homework and write up a CIP?

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]

select list, we will 
>> probably not make it mandatory. Here we’re trying to gauge an ideal end 
>> state - some things may need revisiting if JIRA does not play ball, 
>> though that should not affect many items.
>> 
>>> 
>>> Ariel
>>> 
>>> On Tue, Dec 4, 2018, at 2: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. folksonomy -> 
>>>>> taxonomy<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>).
>>>>>  I hadn’t read the reply as indicating that labels should be zero’d out 
>>>>> periodically. In any case, I agree that reviewing active labels and 
>>>>> re-evaluating our taxonomy from time to time sounds great; I don’t think 
>>>>> I’d zero them, though.
>>>>> 
>>>>> Responding to a few comments:
>>>>> 
>>>>> –––
>>>>> 
>>>>> – To Joey’s question about issues languishing in Triage: I like the idea 
>>>>> of an SLO for the “triage” state. I am happy to commit time and resources 
>>>>> to triaging newly-reported issues, and to JIRA pruning/gardening in 
>>>>> general. I spent part of the weekend before last adding components to a 
>>

Re: JIRA Workflow Proposals

[Ariel Weisberg]

;> 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<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>).
> >>>  I hadn’t read the reply as indicating that labels should be zero’d out 
> >>> periodically. In any case, I agree that reviewing active labels and 
> >>> re-evaluating our taxonomy from time to time sounds great; I don’t think 
> >>> I’d zero them, though.
> >>> 
> >>> Responding to a few comments:
> >>> 
> >>> –––
> >>> 
> >>> – To Joey’s question about issues languishing in Triage: I like the idea 
> >>> of an SLO for the “triage” state. I am happy to commit time and resources 
> >>> to triaging newly-reported issues, and to JIRA pruning/gardening in 
> >>> general. I spent part of the weekend before last adding components to a 
> >>> few hundred open issues and preparing the Confluence reports mentioned in 
> >>> the other thread. It was calming. We can also figure out how to rotate / 
> >>> share this responsibility.
> >>> 
> >>> – Labels discussion: If we adopt a more structured component hierarchy to 
> >>> treat as our primary method of organization, keep labels around for 
> >>> people to use as they’d like (e.g., for custom JQL queries useful to 
> >>> their workflows), and periodically promote those that are widely useful, 
> >>> I think that sounds like a fine outcome.
> >>> 
> >>> – On Sankalp’s question of issue reporter / new contributor burden: I 
> >>> actually think the pruning of fields on the “new issue form” makes 
> >>> reporting issues easier and ensures that information we need is captured. 
> >>> Having the triage step will also provide a nice task queue for screening 
> >>> bugs, and ensures a contributor’s taken a look + screened appropriately 
> >>> (rather than support requests immediately being marked “Critical/Blocker” 
> >>> and assigned a fix version by the reporter).
> >>> 
> >>> – On Sankalp’s question of the non-committer’s workflow during first pass 
&

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

gt;> - 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<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>).
>>>  I hadn’t read the reply as indicating that labels should be zero’d out 
>>> periodically. In any case, I agree that reviewing active labels and 
>>> re-evaluating our taxonomy from time to time sounds great; I don’t think 
>>> I’d zero them, though.
>>> 
>>> Responding to a few comments:
>>> 
>>> –––
>>> 
>>> – To Joey’s question about issues languishing in Triage: I like the idea of 
>>> an SLO for the “triage” state. I am happy to commit time and resources to 
>>> triaging newly-reported issues, and to JIRA pruning/gardening in general. I 
>>> spent part of the weekend before last adding components to a few hundred 
>>> open issues and preparing the Confluence reports mentioned in the other 
>>> thread. It was calming. We can also figure out how to rotate / share this 
>>> responsibility.
>>> 
>>> – Labels discussion: If we adopt a more structured component hierarchy to 
>>> treat as our primary method of organization, keep labels around for people 
>>> to use as they’d like (e.g., for custom JQL queries useful to their 
>>> workflows), and periodically promote those that are widely useful, I think 
>>> that sounds like a fine outcome.
>>> 
>>> – On Sankalp’s question of issue reporter / new contributor burden: I 
>>> actually think the pruning of fields on the “new issue form” makes 
>>> reporting issues easier and ensures that information we need is captured. 
>>> Having the triage step will also provide a nice task queue for screening 
>>> bugs, and ensures a contributor’s taken a look + screened appropriately 
>>> (rather than support requests immediately being marked “Critical/Blocker” 
>>> and assigned a fix version by the reporter).
>>> 
>>> – On Sankalp’s question of the non-committer’s workflow during first pass 
>>> of review, I think that’s covered here: 
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
>>> 
>>> –––
>>> 
>>> I also want to step back and thank Benedict and Kurt for all of their 
>>> analysis and information architecture work behind this proposal. "Workflow 
>>> and bug tracker hygiene” can be a thankless endeavor; I want to make sure 
>>> this one’s not. Thank you both!
>>> 
>>> If we’re nearing consensus on “keeping labels, and considering them for 
>>> promotion to components periodically,” are there other items we need to 
>>> resolve before we generally feel good about the changes?
>>> 
>>> – Scott
>>> 
>>> 
>>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith 
>>> (bened...@apache.org<mailto:bened...@apache.org>) wrote:
>>> 
>>> Hmm. On re-reading your earlier email, I realise I may have anyway gotten 
>>> confused about your suggestion.
>>> 
>>> Are you suggesting we periodically clear any new labels, once we have 
>>> replacements, and only leave the old ones that exist today and haven’t been 
>>> categorised?
>>> 
>>> 
>>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith  
>>>> wrote:
>>>> 
>>>> Do we maintain a list of prior rejects? Revisit any that have increased in 
>>>> usage since last?
>>>> 
>>>> Probably we’re bike shedding this one thing too closely. I would

Re: JIRA Workflow Proposals

[Ariel Weisberg]

 our primary method of organization, keep labels around for people 
> > to use as they’d like (e.g., for custom JQL queries useful to their 
> > workflows), and periodically promote those that are widely useful, I think 
> > that sounds like a fine outcome.
> > 
> > – On Sankalp’s question of issue reporter / new contributor burden: I 
> > actually think the pruning of fields on the “new issue form” makes 
> > reporting issues easier and ensures that information we need is captured. 
> > Having the triage step will also provide a nice task queue for screening 
> > bugs, and ensures a contributor’s taken a look + screened appropriately 
> > (rather than support requests immediately being marked “Critical/Blocker” 
> > and assigned a fix version by the reporter).
> > 
> > – On Sankalp’s question of the non-committer’s workflow during first pass 
> > of review, I think that’s covered here: 
> > https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
> > 
> > –––
> > 
> > I also want to step back and thank Benedict and Kurt for all of their 
> > analysis and information architecture work behind this proposal. "Workflow 
> > and bug tracker hygiene” can be a thankless endeavor; I want to make sure 
> > this one’s not. Thank you both!
> > 
> > If we’re nearing consensus on “keeping labels, and considering them for 
> > promotion to components periodically,” are there other items we need to 
> > resolve before we generally feel good about the changes?
> > 
> > – Scott
> > 
> > 
> > On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith 
> > (bened...@apache.org<mailto:bened...@apache.org>) wrote:
> > 
> > Hmm. On re-reading your earlier email, I realise I may have anyway gotten 
> > confused about your suggestion.
> > 
> > Are you suggesting we periodically clear any new labels, once we have 
> > replacements, and only leave the old ones that exist today and haven’t been 
> > categorised?
> > 
> > 
> >> On 26 Nov 2018, at 23:02, Benedict Elliott Smith  
> >> wrote:
> >> 
> >> Do we maintain a list of prior rejects? Revisit any that have increased in 
> >> usage since last?
> >> 
> >> Probably we’re bike shedding this one thing too closely. I would be happy 
> >> with removing it, periodically cleaning it, or leaving it intact. Mining 
> >> it for schema changes, or telling people to ask.
> >> 
> >> But I fear it will all begin to go to pot again after this effort wanes, 
> >> and my life has only one JIRA cleanup effort to call upon.
> >> 
> >> 
> >>> On 26 Nov 2018, at 18:24, Joshua McKenzie  wrote:
> >>> 
> >>> I'm thinking something like "Every 6 months, we query on labels with count
> >>>> = 4 and consider promoting those. Anything < that only shows if people 
> >>>> are
> >>> specifically looking for it."
> >>> 
> >>> Taking count of occurrence of a label as a proxy for the potential value 
> >>> in
> >>> promoting it to something hardened isn't without flaws, but it's also not
> >>> awful IMO.
> >>> 
> >>> 
> >>> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith 
> >>> 
> >>> wrote:
> >>> 
> >>>>> Is there harm in leaving them in, aside from psychologically to all of 
> >>>>> us
> >>>>> knowing they're there? =/
> >>>> 
> >>>> It would at least make it easier to triage the ‘new' ones and promote
> >>>> them. The pain of actually categorising the labels was high, and doing
> >>>> that every time would mean it never happens (though maybe there are ways 
> >>>> to
> >>>> work around this). I also think there’s value in shedding noisy data, in
> >>>> an active process to promote good hygiene.
> >>>> 
> >>>> But who said our state of mind isn’t also important :)
> >>>> 
> >>>> This isn’t something I’ll fight hard for, though, I can see it’s at least
> >>>> partially a preference for cleanliness. Interested to see what others
> >>>> think.
> >>>> 
> >>>>> On 26 Nov 2018, at 17:28, Joshua McKenzie  wrote:
> >>>>> 
> >>>>>> 
> >>>>>> An alternative route might be to support labels, and (e.g.) bi-annually
> >>

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

ened...@apache.org>
>>>> 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<
>>>>> https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I
>>>>> hadn’t read the reply as indicating that labels should be zero’d out
>>>>> periodically. In any case, I agree that reviewing active labels and
>>>>> re-evaluating our taxonomy from time to time sounds great; I don’t think
>>>>> I’d zero them, though.
>>>>>> 
>>>>>> Responding to a few comments:
>>>>>> 
>>>>>> –––
>>>>>> 
>>>>>> – To Joey’s question about issues languishing in Triage: I like the
>>> idea
>>>>> of an SLO for the “triage” state. I am happy to commit time and
>>> resources
>>>>> to triaging newly-reported issues, and to JIRA pruning/gardening in
>>>>> general. I spent part of the weeke

Re: JIRA Workflow Proposals

[Sam Tunnicliffe]

>>>> 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<
>>>> https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I
>>>> hadn’t read the reply as indicating that labels should be zero’d out
>>>> periodically. In any case, I agree that reviewing active labels and
>>>> re-evaluating our taxonomy from time to time sounds great; I don’t think
>>>> I’d zero them, though.
>>>>> 
>>>>> Responding to a few comments:
>>>>> 
>>>>> –––
>>>>> 
>>>>> – To Joey’s question about issues languishing in Triage: I like the
>> idea
>>>> of an SLO for the “triage” state. I am happy to commit time and
>> resources
>>>> to triaging newly-reported issues, and to JIRA pruning/gardening in
>>>> general. I spent part of the weekend before last adding components to a
>> few
>>>> hundred open issues and preparing the Confluence reports mentioned in
>> the
>>>> other thread. It was calming. We can also figure out how to rotate /
>> share
>>>> this responsibility.
>>>>> 
>>>>> – Labels discussion: If we adopt a more structured component hierarchy
>>>> to treat as our primary method of organization, keep labels around for
>>>> people to use as they’d like (e.g., for custom JQL queries useful to
>> their
>>>> workflows), and periodically promote those that are widely useful, I
>> think
>>>> that sounds like a fine outcome.
>>>>> 
>>>>> – On Sankalp’s question of issue reporter / new contributor burden: I
>>>> actually think the pruning of fields on the “new issue form” makes
>>>> reporting issues easier and ensures that information we need is
>> captured.
>>>> Having the triage step will also provide a nice task queue for screening
>>>> bugs, and ensures a contributor’s taken a look + screened appropriately
>>>> (rather than support requests immediately being marked
>> “Critical/Blocker”
>>>> and assigned a fix version by the reporter).
>>>>> 
>>>>> – On Sankalp’s question of the non-committer’s workflow during first
>>>> pass of review, I think that’s covered here:
>>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
>>>>> 
>>>>> –––
>>>>> 
>>>>> 

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

[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

[Sylvain Lebresne]

-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<
> >> https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I
> >> hadn’t read the reply as indicating that labels should be zero’d out
> >> periodically. In any case, I agree that reviewing active labels and
> >> re-evaluating our taxonomy from time to time sounds great; I don’t think
> >> I’d zero them, though.
> >>>
> >>> Responding to a few comments:
> >>>
> >>> –––
> >>>
> >>> – To Joey’s question about issues languishing in Triage: I like the
> idea
> >> of an SLO for the “triage” state. I am happy to commit time and
> resources
> >> to triaging newly-reported issues, and to JIRA pruning/gardening in
> >> general. I spent part of the weekend before last adding components to a
> few
> >> hundred open issues and preparing the Confluence reports mentioned in
> the
> >> other thread. It was calming. We can also figure out how to rotate /
> share
> >> this responsibility.
> >>>
> >>> – Labels discussion: If we adopt a more structured component hierarchy
> >> to treat as our primary method of organization, keep labels around for
> >> people to use as they’d like (e.g., for custom JQL queries useful to
> their
> >> workflows), and periodically promote those that are widely useful, I
> think
> >> that sounds like a fine outcome.
> >>>
> >>> – On Sankalp’s question of issue reporter / new contributor burden: I
> >> actually think the pruning of fields on the “new issue form” makes
> >> reporting issues easier and ensures that information we need is
> captured.
> >> Having the triage step will also provide a nice task queue for screening
> >> bugs, and ensures a contributor’s taken a look + screened appropriately
> >> (rather than support requests immediately being marked
> “Critical/Blocker”
> >> and assigned a fix version by the reporter).
> >>>
> >>> – On Sankalp’s question of the non-committer’s workflow during first
> >> pass of review, I think that’s covered here:
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
> >>>
> >>> –––
> >>>
> >>> I also want to step back and thank Benedict and Kurt for all of their
> >> analysis and information architecture work behind this proposal.
> "Workflow
> >> and bug tracker hygiene” can be a thankless endeavor; I want to make
> sure
> >> this one’s not. Thank you both!
> >>>
> >>> If we’re nearing consensus on “keeping labels, and considering them for
> >> promotion to components periodically,” are there other items we need to
> >> resolve before we generally feel good about the changes?
> >>>
> >>> – Scott
> >>>
> >>>
> >>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith (
> >> bened...@apache.org<mailto:bened...@apache.org>) wrote:
> >>>
> >>> Hmm. On re-reading your earlier email, I realise I may have anyway
> >> gotten confused about your suggestion.
> >>>
> >>> Are you suggesting we periodically clear any new labels, once we have
> >> replacements, and only leave the old ones that exist today and haven’t
> been
> >> categorised?
> >>>
> >>>
> >>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith  >
> >> wrote:
> >>>>
> >>>> Do we maintain a list of prior rejects? Revisit any that have
> increased
> >> in usage since last?
> >>>>
> >>>> Probably we’re bike shedding this one thing too closely. I would be
> >> happy with removing it, periodically cleaning it, or leaving it intact.
> >> Mining it for schema changes, or telling people to ask.
> >>>>
> >>>> Bu

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

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<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>).
>>>  I hadn’t read the reply as indicating that labels should be zero’d out 
>>> periodically. In any case, I agree that reviewing active labels and 
>>> re-evaluating our taxonomy from time to time sounds great; I don’t think 
>>> I’d zero them, though.
>>> 
>>> Responding to a few comments:
>>> 
>>> –––
>>> 
>>> – To Joey’s question about issues languishing in Triage: I like the idea of 
>>> an SLO for the “triage” state. I am happy to commit time and resources to 
>>> triaging newly-reported issues, and to JIRA pruning/gardening in general. I 
>>> spent part of the weekend before last adding components to a few hundred 
>>> open issues and preparing the Confluence reports mentioned in the other 
>>> thread. It was calming. We can also figure out how to rotate / share this 
>>> responsibility.
>>> 
>>> – Labels discussion: If we adopt a more structured component hierarchy to 
>>> treat as our primary method of organization, keep labels around for people 
>>> to use as they’d like (e.g., for custom JQL queries useful to their 
>>> workflows), and periodically promote those that are widely useful, I think 
>>> that sounds like a fine outcome.
>>> 
>>> – On Sankalp’s question of issue reporter / new contributor burden: I 
>>> actually think the pruning of fields on the “new issue form” makes 
>>> reporting issues easier and ensures that information we need is captured. 
>>> Having the triage step will also provide a nice task queue for screening 
>>> bugs, and ensures a contributor’s taken a look + screened appropriately 
>>> (rather than support requests immediately being marked “Critical/Blocker” 
>>> and assigned a fix version by the reporter).
>>>

Re: JIRA Workflow Proposals

[Stefan Podkowinski]

is to periodically 
>> review active labels and promote those that are demonstrably useful to 
>> components (cf. folksonomy -> 
>> taxonomy<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). 
>> I hadn’t read the reply as indicating that labels should be zero’d out 
>> periodically. In any case, I agree that reviewing active labels and 
>> re-evaluating our taxonomy from time to time sounds great; I don’t think I’d 
>> zero them, though.
>>
>> Responding to a few comments:
>>
>> –––
>>
>> – To Joey’s question about issues languishing in Triage: I like the idea of 
>> an SLO for the “triage” state. I am happy to commit time and resources to 
>> triaging newly-reported issues, and to JIRA pruning/gardening in general. I 
>> spent part of the weekend before last adding components to a few hundred 
>> open issues and preparing the Confluence reports mentioned in the other 
>> thread. It was calming. We can also figure out how to rotate / share this 
>> responsibility.
>>
>> – Labels discussion: If we adopt a more structured component hierarchy to 
>> treat as our primary method of organization, keep labels around for people 
>> to use as they’d like (e.g., for custom JQL queries useful to their 
>> workflows), and periodically promote those that are widely useful, I think 
>> that sounds like a fine outcome.
>>
>> – On Sankalp’s question of issue reporter / new contributor burden: I 
>> actually think the pruning of fields on the “new issue form” makes reporting 
>> issues easier and ensures that information we need is captured. Having the 
>> triage step will also provide a nice task queue for screening bugs, and 
>> ensures a contributor’s taken a look + screened appropriately (rather than 
>> support requests immediately being marked “Critical/Blocker” and assigned a 
>> fix version by the reporter).
>>
>> – On Sankalp’s question of the non-committer’s workflow during first pass of 
>> review, I think that’s covered here: 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
>>
>> –––
>>
>> I also want to step back and thank Benedict and Kurt for all of their 
>> analysis and information architecture work behind this proposal. "Workflow 
>> and bug tracker hygiene” can be a thankless endeavor; I want to make sure 
>> this one’s not. Thank you both!
>>
>> If we’re nearing consensus on “keeping labels, and considering them for 
>> promotion to components periodically,” are there other items we need to 
>> resolve before we generally feel good about the changes?
>>
>> – Scott
>>
>>
>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith 
>> (bened...@apache.org<mailto:bened...@apache.org>) wrote:
>>
>> Hmm. On re-reading your earlier email, I realise I may have anyway gotten 
>> confused about your suggestion.
>>
>> Are you suggesting we periodically clear any new labels, once we have 
>> replacements, and only leave the old ones that exist today and haven’t been 
>> categorised?
>>
>>
>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith  
>>> wrote:
>>>
>>> Do we maintain a list of prior rejects? Revisit any that have increased in 
>>> usage since last?
>>>
>>> Probably we’re bike shedding this one thing too closely. I would be happy 
>>> with removing it, periodically cleaning it, or leaving it intact. Mining it 
>>> for schema changes, or telling people to ask.
>>>
>>> But I fear it will all begin to go to pot again after this effort wanes, 
>>> and my life has only one JIRA cleanup effort to call upon.
>>>
>>>
>>>> On 26 Nov 2018, at 18:24, Joshua McKenzie  wrote:
>>>>
>>>> I'm thinking something like "Every 6 months, we query on labels with count
>>>>> = 4 and consider promoting those. Anything < that only shows if people are
>>>> specifically looking for it."
>>>>
>>>> Taking count of occurrence of a label as a proxy for the potential value in
>>>> promoting it to something hardened isn't without flaws, but it's also not
>>>> awful IMO.
>>>>
>>>>
>>>> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith 
>>>> 
>>>> wrote:
>>>>
>>>>>> Is there harm in leaving them in, aside from psychologically to all of us
>>>>>> knowing they're there? =/
>>>>> It would at least make it

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]

emove?
> > >>
> > >> 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<
> > >> https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I
> > >> hadn’t read the reply as indicating that labels should be zero’d out
> > >> periodically. In any case, I agree that reviewing active labels and
> > >> re-evaluating our taxonomy from time to time sounds great; I don’t
> think
> > >> I’d zero them, though.
> > >>>
> > >>> Responding to a few comments:
> > >>>
> > >>> –––
> > >>>
> > >>> – To Joey’s question about issues languishing in Triage: I like the
> > idea
> > >> of an SLO for the “triage” state. I am happy to commit time and
> > resources
> > >> to triaging newly-reported issues, and to JIRA pruning/gardening in
> > >> general. I spent part of the weekend before last adding components to
> a
> > few
> > >> hundred open issues and preparing the Confluence reports mentioned in
> > the
> > >> other thread. It was calming. We can also figure out how to rotate /
> > share
> > >> this responsibility.
> > >>>
> > >>> – Labels discussion: If we adopt a more structured component
> hierarchy
> > >> to treat as our primary method of organization, keep labels around for
> > >> people to use as they’d like (e.g., for custom JQL queries useful to
> > their
> > >> workflows), and periodically promote those that are widely useful, I
> > think
> > >> that sounds like a fine outcome.
> > >>>
> > >>> – On Sankalp’s question of issue reporter / new contributor burden: I
> > >> actually think the pruning of fields on the “new issue form” makes
> > >> reporting issues easier and ensures that information we need is
> > captured.
> > >> Having the triage step will also provide a nice task queue for
> screening
> > >> bugs, and ensures a contributor’s taken a look + screened
> appropriately
> > >> (rather than support requests immediately being marked
> > “Critical/Blocker”
> > >> and assigned a fix version by the reporter).
> > >>>
> > >>> – On Sankalp’s question of the non-committer’s workflow during first
> > >> pass of review, I think that’s covered here:
> > >>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
> > >>>
> > >>> –––
> > >>>
> > >>> I also want to step back and thank Benedict and Kurt for all of their
> > >> analysis and information architecture work behind this proposal.
> > "Workflow
> > >> and bug tracker hygiene” can be a thankless endeavor; I want to make
> > sure
> > >> this one’s not. Thank you both!
> > >>>
> > >>> If we’re nearing consensus on “keeping labels, and considering them
> for
> > >> promotion to components periodically,” are there other items we need
> to
> > >> resolve before we generally feel good about the changes?
> > >>>
> > >>> – Scott
> > >>>
> > >>>
> > >>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith (
> > >> be

Re: JIRA Workflow Proposals

[Jonathan Haddad]

rably useful to
> >> components (cf. folksonomy -> taxonomy<
> >> https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I
> >> hadn’t read the reply as indicating that labels should be zero’d out
> >> periodically. In any case, I agree that reviewing active labels and
> >> re-evaluating our taxonomy from time to time sounds great; I don’t think
> >> I’d zero them, though.
> >>>
> >>> Responding to a few comments:
> >>>
> >>> –––
> >>>
> >>> – To Joey’s question about issues languishing in Triage: I like the
> idea
> >> of an SLO for the “triage” state. I am happy to commit time and
> resources
> >> to triaging newly-reported issues, and to JIRA pruning/gardening in
> >> general. I spent part of the weekend before last adding components to a
> few
> >> hundred open issues and preparing the Confluence reports mentioned in
> the
> >> other thread. It was calming. We can also figure out how to rotate /
> share
> >> this responsibility.
> >>>
> >>> – Labels discussion: If we adopt a more structured component hierarchy
> >> to treat as our primary method of organization, keep labels around for
> >> people to use as they’d like (e.g., for custom JQL queries useful to
> their
> >> workflows), and periodically promote those that are widely useful, I
> think
> >> that sounds like a fine outcome.
> >>>
> >>> – On Sankalp’s question of issue reporter / new contributor burden: I
> >> actually think the pruning of fields on the “new issue form” makes
> >> reporting issues easier and ensures that information we need is
> captured.
> >> Having the triage step will also provide a nice task queue for screening
> >> bugs, and ensures a contributor’s taken a look + screened appropriately
> >> (rather than support requests immediately being marked
> “Critical/Blocker”
> >> and assigned a fix version by the reporter).
> >>>
> >>> – On Sankalp’s question of the non-committer’s workflow during first
> >> pass of review, I think that’s covered here:
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
> >>>
> >>> –––
> >>>
> >>> I also want to step back and thank Benedict and Kurt for all of their
> >> analysis and information architecture work behind this proposal.
> "Workflow
> >> and bug tracker hygiene” can be a thankless endeavor; I want to make
> sure
> >> this one’s not. Thank you both!
> >>>
> >>> If we’re nearing consensus on “keeping labels, and considering them for
> >> promotion to components periodically,” are there other items we need to
> >> resolve before we generally feel good about the changes?
> >>>
> >>> – Scott
> >>>
> >>>
> >>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith (
> >> bened...@apache.org<mailto:bened...@apache.org>) wrote:
> >>>
> >>> Hmm. On re-reading your earlier email, I realise I may have anyway
> >> gotten confused about your suggestion.
> >>>
> >>> Are you suggesting we periodically clear any new labels, once we have
> >> replacements, and only leave the old ones that exist today and haven’t
> been
> >> categorised?
> >>>
> >>>
> >>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith  >
> >> wrote:
> >>>>
> >>>> Do we maintain a list of prior rejects? Revisit any that have
> increased
> >> in usage since last?
> >>>>
> >>>> Probably we’re bike shedding this one thing too closely. I would be
> >> happy with removing it, periodically cleaning it, or leaving it intact.
> >> Mining it for schema changes, or telling people to ask.
> >>>>
> >>>> But I fear it will all begin to go to pot again after this effort
> >> wanes, and my life has only one JIRA cleanup effort to call upon.
> >>>>
> >>>>
> >>>>> On 26 Nov 2018, at 18:24, Joshua McKenzie 
> >> wrote:
> >>>>>
> >>>>> I'm thinking something like "Every 6 months, we query on labels with
> >> count
> >>>>>> = 4 and consider promoting those. Anything < that only shows if
> >> people are
> >>>>> specifically looking for it."
> >>>>>
> >>&g

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

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


> 
> 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. folksonomy -> taxonomy<
>> https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I
>> hadn’t read the reply as indicating that labels should be zero’d out
>> periodically. In any case, I agree that reviewing active labels and
>> re-evaluating our taxonomy from time to time sounds great; I don’t think
>> I’d zero them, though.
>>> 
>>> Responding to a few comments:
>>> 
>>> –––
>>> 
>>> – To Joey’s question about issues languishing in Triage: I like the idea
>> of an SLO for the “triage” state. I am happy to commit time and resources
>> to triaging newly-reported issues, and to JIRA pruning/gardening in
>> general. I spent part of the weekend before last adding components to a few
>> hundred open issues and preparing the Confluence reports mentioned in the
>> other thread. It was calming. We can also figure out how to rotate / share
>> this responsibility.
>>> 
>>> – Labels discussion: If we adopt a more structured component hierarchy
>> to treat as our primary method of organization, keep labels around for
>> people to use as they’d like (e.g., for custom JQL queries useful to their
>> workflows), and periodically promote those that are widely useful, I think
>> that sounds like a fine outcome.
>>> 
>>> – On Sankalp’s question of issue reporter / new contributor burden: I
>&g

Re: JIRA Workflow Proposals

[Sylvain Lebresne]

>
>
> > 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<
> https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I
> hadn’t read the reply as indicating that labels should be zero’d out
> periodically. In any case, I agree that reviewing active labels and
> re-evaluating our taxonomy from time to time sounds great; I don’t think
> I’d zero them, though.
> >
> > Responding to a few comments:
> >
> > –––
> >
> > – To Joey’s question about issues languishing in Triage: I like the idea
> of an SLO for the “triage” state. I am happy to commit time and resources
> to triaging newly-reported issues, and to JIRA pruning/gardening in
> general. I spent part of the weekend before last adding components to a few
> hundred open issues and preparing the Confluence reports mentioned in the
> other thread. It was calming. We can also figure out how to rotate / share
> this responsibility.
> >
> > – Labels discussion: If we adopt a more structured component hierarchy
> to treat as our primary method of organization, keep labels around for
> people to use as they’d like (e.g., for custom JQL queries useful to their
> workflows), and periodically promote those that are widely useful, I think
> that sounds like a fine outcome.
> >
> > – On Sankalp’s question of issue reporter / new contributor burden: I
> actually think the pruning of fields on the “new issue form” makes
> reporting issues easier and ensures that information we need is captured.
> Having the triage step will also provide a nice task queue for screening
> bugs, and ensures a contributor’s taken a look + screened appropriately
> (rather than support requests immediately being marked “Critical/Blocker”
> and assigned a fix version by the reporter).
> >
> > – On Sankalp’s question of the non-committer’s workflow during first
> pass of review, I think that’s covered here:
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
> >
> > –––
> >
> > I also want to step back and thank Benedict and Kurt for all of their
> analysis and information architecture work behind this proposal. "Workflow
> and bug tracker hygiene” can be a thankless endeavor; I want to make sure
> this one’s not. Thank you both!
> >
> > If we’re nearing consensus on “keeping labels, and considering them for
> promotion to components periodically,” are there other items we need to
> resolve before we generally feel good about the changes?
> >
> > – Scott
> >
> >
> > On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith (
> bened...@apache.org<mailto:bened...@apache.org>) wrote:
> >
> > Hmm. On re-reading your earlier email, I realise I may have anyway
> gotten confused about your suggestion.
> >
> > Are you suggesting we periodically clear any new labels, once we have
> replacements, and only leave the old ones that exist today and haven’t been
> categorised?
> >
> >
> >> On 26 Nov 2018, at 23:02, Benedict Elliott Smith 
> wrote:
> >>
> >> Do we maintain a list of prior rejects? Revisit any that have increased
> in usage since last?
> >>
> >> Probably we’re bike shedding this one thing too closely. I would be
> happy with removing it, periodically cleaning it, or leaving it intact.
> Mining it for schema changes, or telling people to ask.
> >>
> >> But I fear it will all begin to go to pot again after this effort
> wanes, and my life has only one JIRA cleanup effort to call upon.
> >>
> >>
> >>> On 26 Nov 2018, at 18:24, Joshua McKenzie 
> wrote:
> >>>
> >>> I'm thinking something like "Every 6 months, we query on labels with
> count
> >>>> = 4 and consider promoting those. Anything < that only shows if
> people are
> >>> specifically looking for it."
> >>>
> >>> Taking count of occurrence of a label as a proxy for the potential
> value in
> >>> promoting it to something hardened isn't without flaws, but it's also
> not
> >>> awful IMO.
> >>>
> >>>
> >>> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith <
> bened...@apache.org>
> >>> wrote:
> >>>
> >>>>> Is there harm in leaving them in, aside from psychologically to all
> of us
> >>>>> knowing they're there? =/
> >>>

Re: JIRA Workflow Proposals

[Blake Eggleston]

 primary method of organization, keep labels around for people 
>>> to use as they’d like (e.g., for custom JQL queries useful to their 
>>> workflows), and periodically promote those that are widely useful, I think 
>>> that sounds like a fine outcome.
>>> 
>>> – On Sankalp’s question of issue reporter / new contributor burden: I 
>>> actually think the pruning of fields on the “new issue form” makes 
>>> reporting issues easier and ensures that information we need is captured. 
>>> Having the triage step will also provide a nice task queue for screening 
>>> bugs, and ensures a contributor’s taken a look + screened appropriately 
>>> (rather than support requests immediately being marked “Critical/Blocker” 
>>> and assigned a fix version by the reporter).
>>> 
>>> – On Sankalp’s question of the non-committer’s workflow during first pass 
>>> of review, I think that’s covered here: 
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
>>>  
>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow>
>>>  
>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
>>>  
>>> <https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow>>
>>> 
>>> –––
>>> 
>>> I also want to step back and thank Benedict and Kurt for all of their 
>>> analysis and information architecture work behind this proposal. "Workflow 
>>> and bug tracker hygiene” can be a thankless endeavor; I want to make sure 
>>> this one’s not. Thank you both!
>>> 
>>> If we’re nearing consensus on “keeping labels, and considering them for 
>>> promotion to components periodically,” are there other items we need to 
>>> resolve before we generally feel good about the changes?
>>> 
>>> – Scott
>>> 
>>> 
>>> On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith 
>>> (bened...@apache.org <mailto:bened...@apache.org> 
>>> <mailto:bened...@apache.org 
>>> <mailto:bened...@apache.org>><mailto:bened...@apache.org 
>>> <mailto:bened...@apache.org> <mailto:bened...@apache.org 
>>> <mailto:bened...@apache.org>>>) wrote:
>>> 
>>> Hmm. On re-reading your earlier email, I realise I may have anyway gotten 
>>> confused about your suggestion.
>>> 
>>> Are you suggesting we periodically clear any new labels, once we have 
>>> replacements, and only leave the old ones that exist today and haven’t been 
>>> categorised?
>>> 
>>> 
>>>> On 26 Nov 2018, at 23:02, Benedict Elliott Smith >>> <mailto:bened...@apache.org>> wrote:
>>>> 
>>>> Do we maintain a list of prior rejects? Revisit any that have increased in 
>>>> usage since last?
>>>> 
>>>> Probably we’re bike shedding this one thing too closely. I would be happy 
>>>> with removing it, periodically cleaning it, or leaving it intact. Mining 
>>>> it for schema changes, or telling people to ask.
>>>> 
>>>> But I fear it will all begin to go to pot again after this effort wanes, 
>>>> and my life has only one JIRA cleanup effort to call upon.
>>>> 
>>>> 
>>>>> On 26 Nov 2018, at 18:24, Joshua McKenzie >>>> <mailto:jmcken...@apache.org>> wrote:
>>>>> 
>>>>> I'm thinking something like "Every 6 months, we query on labels with count
>>>>>> = 4 and consider promoting those. Anything < that only shows if people 
>>>>>> are
>>>>> specifically looking for it."
>>>>> 
>>>>> Taking count of occurrence of a label as a proxy for the potential value 
>>>>> in
>>>>> promoting it to something hardened isn't without flaws, but it's also not
>>>>> awful IMO.
>>>>> 
>>>>> 
>>>>> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith 
>>>>> mailto:bened...@apache.org>>
>>>>> wrote:
>>>>> 
>>>>>>> Is there harm in leaving them in, aside from psychologically to all of 
>>>>>>> us
>>>>>>> knowing they're there? =/
>>>>>> 
>>>>>>

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

Sorry, 4. Is inconsistent.  First instance should be.

> - 4. Priorities: Keep ‘High' priority


> On 4 Dec 2018, at 19: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: Keep ‘High' priority
> - 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 > <mailto:sc...@paradoxica.net>> 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<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy 
>> <https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>>). I 
>> hadn’t read the reply as indicating that labels should be zero’d out 
>> periodically. In any case, I agree that reviewing active labels and 
>> re-evaluating our taxonomy from time to time sounds great; I don’t think I’d 
>> zero them, though.
>> 
>> Responding to a few comments:
>> 
>> –––
>> 
>> – To Joey’s question about issues languishing in Triage: I like the idea of 
>> an SLO for the “triage” state. I am happy to commit time and resources to 
>> triaging newly-reported issues, and to JIRA pruning/gardening in general. I 
>> spent part of the weekend before last adding components to a few hundred 
>> open issues and preparing the Confluence reports mentioned in the other 
>> thread. It was calming. We can also figure out how to rotate / share this 
>> responsibility.
>> 
>> – Labels discussion: If we adopt a more structured component hierarchy to 
>> treat as our primary method of organization, keep labels around for people 
>> to use as they’d like (e.g., for custom JQL queries useful to their 
>> workflows), and periodically promote those that are widely useful, I think 
>> that sounds like a fine outcome.
>> 
>> – On Sankalp’s question of issue reporter / new contributor burden: I 
>> actually think the pruning of fields on the “new issue form” makes reporting 
>> issues easier and ensures that information we need is captured. Having the 
>> triage step will also provide a nice task queue for screening bugs, and 
>> ensures a contributor’s taken a look + screened appropriately (rather than 
>> support requests immediately being marked “Critical/Blocker” and as

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

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<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). 
> I hadn’t read the reply as indicating that labels should be zero’d out 
> periodically. In any case, I agree that reviewing active labels and 
> re-evaluating our taxonomy from time to time sounds great; I don’t think I’d 
> zero them, though.
> 
> Responding to a few comments:
> 
> –––
> 
> – To Joey’s question about issues languishing in Triage: I like the idea of 
> an SLO for the “triage” state. I am happy to commit time and resources to 
> triaging newly-reported issues, and to JIRA pruning/gardening in general. I 
> spent part of the weekend before last adding components to a few hundred open 
> issues and preparing the Confluence reports mentioned in the other thread. It 
> was calming. We can also figure out how to rotate / share this responsibility.
> 
> – Labels discussion: If we adopt a more structured component hierarchy to 
> treat as our primary method of organization, keep labels around for people to 
> use as they’d like (e.g., for custom JQL queries useful to their workflows), 
> and periodically promote those that are widely useful, I think that sounds 
> like a fine outcome.
> 
> – On Sankalp’s question of issue reporter / new contributor burden: I 
> actually think the pruning of fields on the “new issue form” makes reporting 
> issues easier and ensures that information we need is captured. Having the 
> triage step will also provide a nice task queue for screening bugs, and 
> ensures a contributor’s taken a look + screened appropriately (rather than 
> support requests immediately being marked “Critical/Blocker” and assigned a 
> fix version by the reporter).
> 
> – On Sankalp’s question of the non-committer’s workflow during first pass of 
> review, I think that’s covered here: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow
> 
> –––
> 
> I also want to step back and thank Benedict and Kurt for all of their 
> analysis and information architecture work behind this proposal. "Workflow 
> and bug tracker hygiene” can be a thankless endeavor; I want to make sure 
> this one’s not. Thank you both!
> 
> If we’re nearing consensus on “keeping la

Re: JIRA Workflow Proposals

[Scott Andreas]

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<https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy>). I 
hadn’t read the reply as indicating that labels should be zero’d out 
periodically. In any case, I agree that reviewing active labels and 
re-evaluating our taxonomy from time to time sounds great; I don’t think I’d 
zero them, though.

Responding to a few comments:

–––

– To Joey’s question about issues languishing in Triage: I like the idea of an 
SLO for the “triage” state. I am happy to commit time and resources to triaging 
newly-reported issues, and to JIRA pruning/gardening in general. I spent part 
of the weekend before last adding components to a few hundred open issues and 
preparing the Confluence reports mentioned in the other thread. It was calming. 
We can also figure out how to rotate / share this responsibility.

– Labels discussion: If we adopt a more structured component hierarchy to treat 
as our primary method of organization, keep labels around for people to use as 
they’d like (e.g., for custom JQL queries useful to their workflows), and 
periodically promote those that are widely useful, I think that sounds like a 
fine outcome.

– On Sankalp’s question of issue reporter / new contributor burden: I actually 
think the pruning of fields on the “new issue form” makes reporting issues 
easier and ensures that information we need is captured. Having the triage step 
will also provide a nice task queue for screening bugs, and ensures a 
contributor’s taken a look + screened appropriately (rather than support 
requests immediately being marked “Critical/Blocker” and assigned a fix version 
by the reporter).

– On Sankalp’s question of the non-committer’s workflow during first pass of 
review, I think that’s covered here: 
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals#JIRAWorkflowProposals-Workflow

–––

I also want to step back and thank Benedict and Kurt for all of their analysis 
and information architecture work behind this proposal. "Workflow and bug 
tracker hygiene” can be a thankless endeavor; I want to make sure this one’s 
not. Thank you both!

If we’re nearing consensus on “keeping labels, and considering them for 
promotion to components periodically,” are there other items we need to resolve 
before we generally feel good about the changes?

– Scott


On November 26, 2018 at 3:14:05 PM, Benedict Elliott Smith 
(bened...@apache.org<mailto:bened...@apache.org>) wrote:

Hmm. On re-reading your earlier email, I realise I may have anyway gotten 
confused about your suggestion.

Are you suggesting we periodically clear any new labels, once we have 
replacements, and only leave the old ones that exist today and haven’t been 
categorised?


> On 26 Nov 2018, at 23:02, Benedict Elliott Smith  wrote:
>
> Do we maintain a list of prior rejects? Revisit any that have increased in 
> usage since last?
>
> Probably we’re bike shedding this one thing too closely. I would be happy 
> with removing it, periodically cleaning it, or leaving it intact. Mining it 
> for schema changes, or telling people to ask.
>
> But I fear it will all begin to go to pot again after this effort wanes, and 
> my life has only one JIRA cleanup effort to call upon.
>
>
>> On 26 Nov 2018, at 18:24, Joshua McKenzie  wrote:
>>
>> I'm thinking something like "Every 6 months, we query on labels with count
>>> = 4 and consider promoting those. Anything < that only shows if people are
>> specifically looking for it."
>>
>> Taking count of occurrence of a label as a proxy for the potential value in
>> promoting it to something hardened isn't without flaws, but it's also not
>> awful IMO.
>>
>>
>> On Mon, Nov 26, 2018 at 12:37 PM Benedict Elliott Smith 
>> wrote:
>>
>>>> Is there harm in leaving them in, aside from psychologically to all of us
>>>> knowing they're there? =/
>>>
>>> It would at least make it easier to triage the ‘new' ones and promote
>>> them. The pain of actually categorising the labels was high, and doing
>>> that every time would mean it never happens (though maybe there are ways to
>>> work around this). I also think there’s value in shedding noisy data, in
>>> an active process to promote good hygiene.
>>>
>>> But who said our state of mind isn’t also important :)
>>>
>>> This isn’t something I’ll fight hard for, though, I can see it’s at least
>>> partially a preference for cleanliness. Interested to see what others
>>> think.
>>>
>>>> On 26 Nov 2018, at 17:28, Joshua McKenzie  wrote:
>>>>
>

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

>>>>>>> On Nov 26, 2018, at 7:46 PM, Joshua McKenzie 
>>>>> wrote:
>>>>>>> 
>>>>>>> 1) Removal of labels: one of the strengths of the current model is
>>>>>>> flexibility for groupings of concepts to arise from a user-perspective
>>>>>>> (lhf, etc). Calcifying the label concepts into components, categories,
>>>>> etc.
>>>>>>> is a strict loss of functionality for users to express and categorize
>>>>> their
>>>>>>> concerns with the project. This feels like an over-correction to our
>>>>>>> current lack of discipline cleaning up one-off labels.
>>> Counter-proposal:
>>>>>>> 
>>>>>>> 1. We beef up the categories and components as proposed and migrate
>>>>>>> labels to those
>>>>>>> 2. We remove the one-off labels that aren't adding value, considering
>>>>>>> aggregating similar labels
>>>>>>> 3. We leave the "labels" field intact, perhaps with a bit of guidance
>>>>> on
>>>>>>> how to effectively use it
>>>>>>> 
>>>>>>> 2) Required fields on transition: assuming these are required upon
>>>>> *issue
>>>>>>> creation*, that's placing a significant burden on a user that's seen
>>>>>>> something and wants to open a ticket about it, but isn't sure if it's
>>> a
>>>>>>> "Semantic Failure" or a "Consistency Failure", for instance. If this
>>> is,
>>>>>>> instead, a field required for transition to other ticket states by the
>>>>>>> developer working on it, I think that makes sense.
>>>>>>> 
>>>>>>> 3) Priority Changes: to be blunt, this looks like shuffling chairs on
>>>>> the
>>>>>>> deck of the titanic on this one - in my experience, most users aren't
>>>>> going
>>>>>>> to set the priority on tickets when they open them (hence default ==
>>>>> major
>>>>>>> and most tickets are opened as major), so this is something that will
>>> be
>>>>>>> either a) left alone so as not to offend those for whom the priority
>>> is
>>>>>>> *actually* major or consistent with the default, or b) changed by the
>>>>> dev
>>>>>>> anyway and the added signal from a new "High vs. Urgent" distinction
>>> and
>>>>>>> communication of developer intent to engage with a ticket is something
>>>>>>> that'll be lost on most users that are just reporting something. I
>>> don't
>>>>>>> have a meaningful counter-proposal at this point as the current
>>> problem
>>>>> is
>>>>>>> more about UX on this field than the signal / noise on the field
>>> itself
>>>>> IMO.
>>>>>>> 
>>>>>>> A meta question about the "What and Why" of what we're trying to
>>>>> accomplish
>>>>>>> here: it sounds like what you're looking at is:
>>>>>>> 
>>>>>>> 1. to capture more information
>>>>>>> 2. simplify the data entry
>>>>>>> 3. nudge people towards more complete and accurate data entry
>>>>>>> 4. our ability as a project to measure release quality over time and
>>>>>>> identify when Cassandra is ready for (or due a) release.
>>>>>>> 
>>>>>>> The proposal in its current form makes certain strong inroads in all
>>> of
>>>>>>> those 4 metrics, but I think the major thing missing is the UX of what
>>>>>>> we're thinking about changing:
>>>>>>> 
>>>>>>> 1. Making it easy for / reduce friction for users to report bugs and
>>>>>>> requests into the project JIRA (easy to do things right, hard to do
>>>>> things
>>>>>>> wrong) (current proposal is a +1 on "do things right", though I'd
>>> argue
>>>>>>> against it being *easy*)
>>>>>>> 2. Asking from the users what they can provide about their experience
>>>>>>> and issues and no more
>>>>>>> 
>>>&

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

gt;> Counter-proposal:
>>>>>> 
>>>>>> 1. We beef up the categories and components as proposed and migrate
>>>>>> labels to those
>>>>>> 2. We remove the one-off labels that aren't adding value, considering
>>>>>> aggregating similar labels
>>>>>> 3. We leave the "labels" field intact, perhaps with a bit of guidance
>>>> on
>>>>>> how to effectively use it
>>>>>> 
>>>>>> 2) Required fields on transition: assuming these are required upon
>>>> *issue
>>>>>> creation*, that's placing a significant burden on a user that's seen
>>>>>> something and wants to open a ticket about it, but isn't sure if it's
>> a
>>>>>> "Semantic Failure" or a "Consistency Failure", for instance. If this
>> is,
>>>>>> instead, a field required for transition to other ticket states by the
>>>>>> developer working on it, I think that makes sense.
>>>>>> 
>>>>>> 3) Priority Changes: to be blunt, this looks like shuffling chairs on
>>>> the
>>>>>> deck of the titanic on this one - in my experience, most users aren't
>>>> going
>>>>>> to set the priority on tickets when they open them (hence default ==
>>>> major
>>>>>> and most tickets are opened as major), so this is something that will
>> be
>>>>>> either a) left alone so as not to offend those for whom the priority
>> is
>>>>>> *actually* major or consistent with the default, or b) changed by the
>>>> dev
>>>>>> anyway and the added signal from a new "High vs. Urgent" distinction
>> and
>>>>>> communication of developer intent to engage with a ticket is something
>>>>>> that'll be lost on most users that are just reporting something. I
>> don't
>>>>>> have a meaningful counter-proposal at this point as the current
>> problem
>>>> is
>>>>>> more about UX on this field than the signal / noise on the field
>> itself
>>>> IMO.
>>>>>> 
>>>>>> A meta question about the "What and Why" of what we're trying to
>>>> accomplish
>>>>>> here: it sounds like what you're looking at is:
>>>>>> 
>>>>>> 1. to capture more information
>>>>>> 2. simplify the data entry
>>>>>> 3. nudge people towards more complete and accurate data entry
>>>>>> 4. our ability as a project to measure release quality over time and
>>>>>> identify when Cassandra is ready for (or due a) release.
>>>>>> 
>>>>>> The proposal in its current form makes certain strong inroads in all
>> of
>>>>>> those 4 metrics, but I think the major thing missing is the UX of what
>>>>>> we're thinking about changing:
>>>>>> 
>>>>>> 1. Making it easy for / reduce friction for users to report bugs and
>>>>>> requests into the project JIRA (easy to do things right, hard to do
>>>> things
>>>>>> wrong) (current proposal is a +1 on "do things right", though I'd
>> argue
>>>>>> against it being *easy*)
>>>>>> 2. Asking from the users what they can provide about their experience
>>>>>> and issues and no more
>>>>>> 
>>>>>> Philosophically, are we trying to make it easier for people that are
>>>> paid
>>>>>> FT to work on C*, are we trying to make things easier for *users* of
>> C*,
>>>>>> both, neither? Who are we targeting here w/these project changes and
>>>> what
>>>>>> of their issues / problems are we trying to improve?
>>>>>> 
>>>>>> And lastly: the TLC and management of the JIRA aspects of this project
>>>> have
>>>>>> *definitely* languished (not pointing any fingers here, I'm *at least*
>>>> as
>>>>>> guilty as anyone on this :) ) - so a big thanks to you and whomever
>>>> you've
>>>>>> collaborate with in getting this conversation started!
>>>>>> 
>>>>>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith <
>>>> bened...@apache.org>
>>>>>> wrote:
>>>>>> 
>>>>>

Re: JIRA Workflow Proposals

[Joshua McKenzie]

lure" or a "Consistency Failure", for instance. If this
> is,
> >>>> instead, a field required for transition to other ticket states by the
> >>>> developer working on it, I think that makes sense.
> >>>>
> >>>> 3) Priority Changes: to be blunt, this looks like shuffling chairs on
> >> the
> >>>> deck of the titanic on this one - in my experience, most users aren't
> >> going
> >>>> to set the priority on tickets when they open them (hence default ==
> >> major
> >>>> and most tickets are opened as major), so this is something that will
> be
> >>>> either a) left alone so as not to offend those for whom the priority
> is
> >>>> *actually* major or consistent with the default, or b) changed by the
> >> dev
> >>>> anyway and the added signal from a new "High vs. Urgent" distinction
> and
> >>>> communication of developer intent to engage with a ticket is something
> >>>> that'll be lost on most users that are just reporting something. I
> don't
> >>>> have a meaningful counter-proposal at this point as the current
> problem
> >> is
> >>>> more about UX on this field than the signal / noise on the field
> itself
> >> IMO.
> >>>>
> >>>> A meta question about the "What and Why" of what we're trying to
> >> accomplish
> >>>> here: it sounds like what you're looking at is:
> >>>>
> >>>> 1. to capture more information
> >>>> 2. simplify the data entry
> >>>> 3. nudge people towards more complete and accurate data entry
> >>>> 4. our ability as a project to measure release quality over time and
> >>>> identify when Cassandra is ready for (or due a) release.
> >>>>
> >>>> The proposal in its current form makes certain strong inroads in all
> of
> >>>> those 4 metrics, but I think the major thing missing is the UX of what
> >>>> we're thinking about changing:
> >>>>
> >>>> 1. Making it easy for / reduce friction for users to report bugs and
> >>>> requests into the project JIRA (easy to do things right, hard to do
> >> things
> >>>> wrong) (current proposal is a +1 on "do things right", though I'd
> argue
> >>>> against it being *easy*)
> >>>> 2. Asking from the users what they can provide about their experience
> >>>> and issues and no more
> >>>>
> >>>> Philosophically, are we trying to make it easier for people that are
> >> paid
> >>>> FT to work on C*, are we trying to make things easier for *users* of
> C*,
> >>>> both, neither? Who are we targeting here w/these project changes and
> >> what
> >>>> of their issues / problems are we trying to improve?
> >>>>
> >>>> And lastly: the TLC and management of the JIRA aspects of this project
> >> have
> >>>> *definitely* languished (not pointing any fingers here, I'm *at least*
> >> as
> >>>> guilty as anyone on this :) ) - so a big thanks to you and whomever
> >> you've
> >>>> collaborate with in getting this conversation started!
> >>>>
> >>>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith <
> >> bened...@apache.org>
> >>>> wrote:
> >>>>
> >>>>> We’ve concluded our efforts to produce a proposal for changes to the
> >> JIRA
> >>>>> workflow, and they can be found here:
> >>>>>
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> >>>>> <
> >>>>>
> >>
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> >>>>>>
> >>>>>
> >>>>> I hope there will be broad consensus, but I’m sure it won’t be plain
> >>>>> sailing.  It would be great to get a discussion going around the
> >> proposal,
> >>>>> so please take some time to read and respond if you think you’ll
> have a
> >>>>> strong opinion on this topic.
> >>>>>
> >>>>> There remains an undecided question in our initial proposal, that is
> >>>>> highlighted in the wiki.  Specifically, there was no seemingly
> >> objective
> >>>>> winner for the suggested changes to Component (though I have a
> >> preference,
> >>>>> that I will express in the ensuing discussion).
> >>>>>
> >>>>> Other contentious issues may be:
> >>>>> - The removal of ‘labels’ - which is very noisy, the vast majority of
> >>>>> which provide no value, and we expect can be superseded by other
> >> suggestions
> >>>>> - The introduction of required fields for certain transitions, some
> of
> >>>>> which are new (complexity, severity, bug/feature category)
> >>>>> - The introduction of some new transitions (Triage, Review in
> Progress,
> >>>>> Change Requested)
> >>>>>
> >>>>> Look forward to hearing your thoughts!
> >>>
> >>> -
> >>> 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
> >>
> >>
>
>
> -
> 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]

 vs. Urgent" distinction and
>>>> communication of developer intent to engage with a ticket is something
>>>> that'll be lost on most users that are just reporting something. I don't
>>>> have a meaningful counter-proposal at this point as the current problem
>> is
>>>> more about UX on this field than the signal / noise on the field itself
>> IMO.
>>>> 
>>>> A meta question about the "What and Why" of what we're trying to
>> accomplish
>>>> here: it sounds like what you're looking at is:
>>>> 
>>>> 1. to capture more information
>>>> 2. simplify the data entry
>>>> 3. nudge people towards more complete and accurate data entry
>>>> 4. our ability as a project to measure release quality over time and
>>>> identify when Cassandra is ready for (or due a) release.
>>>> 
>>>> The proposal in its current form makes certain strong inroads in all of
>>>> those 4 metrics, but I think the major thing missing is the UX of what
>>>> we're thinking about changing:
>>>> 
>>>> 1. Making it easy for / reduce friction for users to report bugs and
>>>> requests into the project JIRA (easy to do things right, hard to do
>> things
>>>> wrong) (current proposal is a +1 on "do things right", though I'd argue
>>>> against it being *easy*)
>>>> 2. Asking from the users what they can provide about their experience
>>>> and issues and no more
>>>> 
>>>> Philosophically, are we trying to make it easier for people that are
>> paid
>>>> FT to work on C*, are we trying to make things easier for *users* of C*,
>>>> both, neither? Who are we targeting here w/these project changes and
>> what
>>>> of their issues / problems are we trying to improve?
>>>> 
>>>> And lastly: the TLC and management of the JIRA aspects of this project
>> have
>>>> *definitely* languished (not pointing any fingers here, I'm *at least*
>> as
>>>> guilty as anyone on this :) ) - so a big thanks to you and whomever
>> you've
>>>> collaborate with in getting this conversation started!
>>>> 
>>>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith <
>> bened...@apache.org>
>>>> wrote:
>>>> 
>>>>> We’ve concluded our efforts to produce a proposal for changes to the
>> JIRA
>>>>> workflow, and they can be found here:
>>>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>>>> <
>>>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>>>>> 
>>>>> 
>>>>> I hope there will be broad consensus, but I’m sure it won’t be plain
>>>>> sailing.  It would be great to get a discussion going around the
>> proposal,
>>>>> so please take some time to read and respond if you think you’ll have a
>>>>> strong opinion on this topic.
>>>>> 
>>>>> There remains an undecided question in our initial proposal, that is
>>>>> highlighted in the wiki.  Specifically, there was no seemingly
>> objective
>>>>> winner for the suggested changes to Component (though I have a
>> preference,
>>>>> that I will express in the ensuing discussion).
>>>>> 
>>>>> Other contentious issues may be:
>>>>> - The removal of ‘labels’ - which is very noisy, the vast majority of
>>>>> which provide no value, and we expect can be superseded by other
>> suggestions
>>>>> - The introduction of required fields for certain transitions, some of
>>>>> which are new (complexity, severity, bug/feature category)
>>>>> - The introduction of some new transitions (Triage, Review in Progress,
>>>>> Change Requested)
>>>>> 
>>>>> Look forward to hearing your thoughts!
>>> 
>>> -
>>> 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
>> 
>> 


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

but I think the major thing missing is the UX of what
> >> we're thinking about changing:
> >>
> >>  1. Making it easy for / reduce friction for users to report bugs and
> >>  requests into the project JIRA (easy to do things right, hard to do
> things
> >>  wrong) (current proposal is a +1 on "do things right", though I'd argue
> >>  against it being *easy*)
> >>  2. Asking from the users what they can provide about their experience
> >>  and issues and no more
> >>
> >> Philosophically, are we trying to make it easier for people that are
> paid
> >> FT to work on C*, are we trying to make things easier for *users* of C*,
> >> both, neither? Who are we targeting here w/these project changes and
> what
> >> of their issues / problems are we trying to improve?
> >>
> >> And lastly: the TLC and management of the JIRA aspects of this project
> have
> >> *definitely* languished (not pointing any fingers here, I'm *at least*
> as
> >> guilty as anyone on this :) ) - so a big thanks to you and whomever
> you've
> >> collaborate with in getting this conversation started!
> >>
> >> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith <
> bened...@apache.org>
> >> wrote:
> >>
> >>> We’ve concluded our efforts to produce a proposal for changes to the
> JIRA
> >>> workflow, and they can be found here:
> >>>
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> >>> <
> >>>
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> >>>>
> >>>
> >>> I hope there will be broad consensus, but I’m sure it won’t be plain
> >>> sailing.  It would be great to get a discussion going around the
> proposal,
> >>> so please take some time to read and respond if you think you’ll have a
> >>> strong opinion on this topic.
> >>>
> >>> There remains an undecided question in our initial proposal, that is
> >>> highlighted in the wiki.  Specifically, there was no seemingly
> objective
> >>> winner for the suggested changes to Component (though I have a
> preference,
> >>> that I will express in the ensuing discussion).
> >>>
> >>> Other contentious issues may be:
> >>> - The removal of ‘labels’ - which is very noisy, the vast majority of
> >>> which provide no value, and we expect can be superseded by other
> suggestions
> >>> - The introduction of required fields for certain transitions, some of
> >>> which are new (complexity, severity, bug/feature category)
> >>> - The introduction of some new transitions (Triage, Review in Progress,
> >>> Change Requested)
> >>>
> >>> Look forward to hearing your thoughts!
> >
> > -
> > 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]

Sorry, I failed to respond to point (2) in the aggregate email.

I’m not sure it’s worth complicating the flow for this scenario, as the ticket 
can simply return to ‘Patch Available’.  But, I’m really unsure of the best 
option here.  Does anyone else have any strong opinions / thoughts?


> On 26 Nov 2018, at 14:33, Sankalp Kohli  wrote:
> 
> I have following initial comments on the proposal. 
> 1. Creating a JIRA should have few fields mandatory like platform, version, 
> etc. We want to put less burden on someone creating a ticket but I feel these 
> are required for opening bugs. 
> 
> 2. What is the flow when a non committer does the first pass of review? 
> 
> 
> 
>> On Nov 26, 2018, at 7:46 PM, Joshua McKenzie  wrote:
>> 
>> 1) Removal of labels: one of the strengths of the current model is
>> flexibility for groupings of concepts to arise from a user-perspective
>> (lhf, etc). Calcifying the label concepts into components, categories, etc.
>> is a strict loss of functionality for users to express and categorize their
>> concerns with the project. This feels like an over-correction to our
>> current lack of discipline cleaning up one-off labels. Counter-proposal:
>> 
>>  1. We beef up the categories and components as proposed and migrate
>>  labels to those
>>  2. We remove the one-off labels that aren't adding value, considering
>>  aggregating similar labels
>>  3. We leave the "labels" field intact, perhaps with a bit of guidance on
>>  how to effectively use it
>> 
>> 2) Required fields on transition: assuming these are required upon *issue
>> creation*, that's placing a significant burden on a user that's seen
>> something and wants to open a ticket about it, but isn't sure if it's a
>> "Semantic Failure" or a "Consistency Failure", for instance. If this is,
>> instead, a field required for transition to other ticket states by the
>> developer working on it, I think that makes sense.
>> 
>> 3) Priority Changes: to be blunt, this looks like shuffling chairs on the
>> deck of the titanic on this one - in my experience, most users aren't going
>> to set the priority on tickets when they open them (hence default == major
>> and most tickets are opened as major), so this is something that will be
>> either a) left alone so as not to offend those for whom the priority is
>> *actually* major or consistent with the default, or b) changed by the dev
>> anyway and the added signal from a new "High vs. Urgent" distinction and
>> communication of developer intent to engage with a ticket is something
>> that'll be lost on most users that are just reporting something. I don't
>> have a meaningful counter-proposal at this point as the current problem is
>> more about UX on this field than the signal / noise on the field itself IMO.
>> 
>> A meta question about the "What and Why" of what we're trying to accomplish
>> here: it sounds like what you're looking at is:
>> 
>>  1. to capture more information
>>  2. simplify the data entry
>>  3. nudge people towards more complete and accurate data entry
>>  4. our ability as a project to measure release quality over time and
>>  identify when Cassandra is ready for (or due a) release.
>> 
>> The proposal in its current form makes certain strong inroads in all of
>> those 4 metrics, but I think the major thing missing is the UX of what
>> we're thinking about changing:
>> 
>>  1. Making it easy for / reduce friction for users to report bugs and
>>  requests into the project JIRA (easy to do things right, hard to do things
>>  wrong) (current proposal is a +1 on "do things right", though I'd argue
>>  against it being *easy*)
>>  2. Asking from the users what they can provide about their experience
>>  and issues and no more
>> 
>> Philosophically, are we trying to make it easier for people that are paid
>> FT to work on C*, are we trying to make things easier for *users* of C*,
>> both, neither? Who are we targeting here w/these project changes and what
>> of their issues / problems are we trying to improve?
>> 
>> And lastly: the TLC and management of the JIRA aspects of this project have
>> *definitely* languished (not pointing any fingers here, I'm *at least* as
>> guilty as anyone on this :) ) - so a big thanks to you and whomever you've
>> collaborate with in getting this conversation started!
>> 
>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith 
>> wrote:
>> 
>>> We’ve concluded our efforts to produce a proposal for changes to the JIRA
>>&g

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

re required upon
>> *issue
>>>> creation*, that's placing a significant burden on a user that's seen
>>>> something and wants to open a ticket about it, but isn't sure if it's a
>>>> "Semantic Failure" or a "Consistency Failure", for instance. If this is,
>>>> instead, a field required for transition to other ticket states by the
>>>> developer working on it, I think that makes sense.
>>>> 
>>>> 3) Priority Changes: to be blunt, this looks like shuffling chairs on
>> the
>>>> deck of the titanic on this one - in my experience, most users aren't
>> going
>>>> to set the priority on tickets when they open them (hence default ==
>> major
>>>> and most tickets are opened as major), so this is something that will be
>>>> either a) left alone so as not to offend those for whom the priority is
>>>> *actually* major or consistent with the default, or b) changed by the
>> dev
>>>> anyway and the added signal from a new "High vs. Urgent" distinction and
>>>> communication of developer intent to engage with a ticket is something
>>>> that'll be lost on most users that are just reporting something. I don't
>>>> have a meaningful counter-proposal at this point as the current problem
>> is
>>>> more about UX on this field than the signal / noise on the field itself
>> IMO.
>>>> 
>>>> A meta question about the "What and Why" of what we're trying to
>> accomplish
>>>> here: it sounds like what you're looking at is:
>>>> 
>>>> 1. to capture more information
>>>> 2. simplify the data entry
>>>> 3. nudge people towards more complete and accurate data entry
>>>> 4. our ability as a project to measure release quality over time and
>>>> identify when Cassandra is ready for (or due a) release.
>>>> 
>>>> The proposal in its current form makes certain strong inroads in all of
>>>> those 4 metrics, but I think the major thing missing is the UX of what
>>>> we're thinking about changing:
>>>> 
>>>> 1. Making it easy for / reduce friction for users to report bugs and
>>>> requests into the project JIRA (easy to do things right, hard to do
>> things
>>>> wrong) (current proposal is a +1 on "do things right", though I'd argue
>>>> against it being *easy*)
>>>> 2. Asking from the users what they can provide about their experience
>>>> and issues and no more
>>>> 
>>>> Philosophically, are we trying to make it easier for people that are
>> paid
>>>> FT to work on C*, are we trying to make things easier for *users* of C*,
>>>> both, neither? Who are we targeting here w/these project changes and
>> what
>>>> of their issues / problems are we trying to improve?
>>>> 
>>>> And lastly: the TLC and management of the JIRA aspects of this project
>> have
>>>> *definitely* languished (not pointing any fingers here, I'm *at least*
>> as
>>>> guilty as anyone on this :) ) - so a big thanks to you and whomever
>> you've
>>>> collaborate with in getting this conversation started!
>>>> 
>>>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith <
>> bened...@apache.org>
>>>> wrote:
>>>> 
>>>>> We’ve concluded our efforts to produce a proposal for changes to the
>> JIRA
>>>>> workflow, and they can be found here:
>>>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>>>> <
>>>>> 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>>>>> 
>>>>> 
>>>>> I hope there will be broad consensus, but I’m sure it won’t be plain
>>>>> sailing.  It would be great to get a discussion going around the
>> proposal,
>>>>> so please take some time to read and respond if you think you’ll have a
>>>>> strong opinion on this topic.
>>>>> 
>>>>> There remains an undecided question in our initial proposal, that is
>>>>> highlighted in the wiki.  Specifically, there was no seemingly
>> objective
>>>>> winner for the suggested changes to Component (though I have a
>> preference,
>>>>> that I will express in the ensuing discussion).
>>>>> 
>>>>> Other contentious issues may be:
>>>>> - The removal of ‘labels’ - which is very noisy, the vast majority of
>>>>> which provide no value, and we expect can be superseded by other
>> suggestions
>>>>> - The introduction of required fields for certain transitions, some of
>>>>> which are new (complexity, severity, bug/feature category)
>>>>> - The introduction of some new transitions (Triage, Review in Progress,
>>>>> Change Requested)
>>>>> 
>>>>> Look forward to hearing your thoughts!
>>> 
>>> -
>>> 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
>> 
>> 


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

a McKenzie  wrote:
>>> 
>>> 1) Removal of labels: one of the strengths of the current model is
>>> flexibility for groupings of concepts to arise from a user-perspective
>>> (lhf, etc). Calcifying the label concepts into components, categories, etc.
>>> is a strict loss of functionality for users to express and categorize their
>>> concerns with the project. This feels like an over-correction to our
>>> current lack of discipline cleaning up one-off labels. Counter-proposal:
>>> 
>>> 1. We beef up the categories and components as proposed and migrate
>>> labels to those
>>> 2. We remove the one-off labels that aren't adding value, considering
>>> aggregating similar labels
>>> 3. We leave the "labels" field intact, perhaps with a bit of guidance on
>>> how to effectively use it
>>> 
>>> 2) Required fields on transition: assuming these are required upon *issue
>>> creation*, that's placing a significant burden on a user that's seen
>>> something and wants to open a ticket about it, but isn't sure if it's a
>>> "Semantic Failure" or a "Consistency Failure", for instance. If this is,
>>> instead, a field required for transition to other ticket states by the
>>> developer working on it, I think that makes sense.
>>> 
>>> 3) Priority Changes: to be blunt, this looks like shuffling chairs on the
>>> deck of the titanic on this one - in my experience, most users aren't going
>>> to set the priority on tickets when they open them (hence default == major
>>> and most tickets are opened as major), so this is something that will be
>>> either a) left alone so as not to offend those for whom the priority is
>>> *actually* major or consistent with the default, or b) changed by the dev
>>> anyway and the added signal from a new "High vs. Urgent" distinction and
>>> communication of developer intent to engage with a ticket is something
>>> that'll be lost on most users that are just reporting something. I don't
>>> have a meaningful counter-proposal at this point as the current problem is
>>> more about UX on this field than the signal / noise on the field itself IMO.
>>> 
>>> A meta question about the "What and Why" of what we're trying to accomplish
>>> here: it sounds like what you're looking at is:
>>> 
>>> 1. to capture more information
>>> 2. simplify the data entry
>>> 3. nudge people towards more complete and accurate data entry
>>> 4. our ability as a project to measure release quality over time and
>>> identify when Cassandra is ready for (or due a) release.
>>> 
>>> The proposal in its current form makes certain strong inroads in all of
>>> those 4 metrics, but I think the major thing missing is the UX of what
>>> we're thinking about changing:
>>> 
>>> 1. Making it easy for / reduce friction for users to report bugs and
>>> requests into the project JIRA (easy to do things right, hard to do things
>>> wrong) (current proposal is a +1 on "do things right", though I'd argue
>>> against it being *easy*)
>>> 2. Asking from the users what they can provide about their experience
>>> and issues and no more
>>> 
>>> Philosophically, are we trying to make it easier for people that are paid
>>> FT to work on C*, are we trying to make things easier for *users* of C*,
>>> both, neither? Who are we targeting here w/these project changes and what
>>> of their issues / problems are we trying to improve?
>>> 
>>> And lastly: the TLC and management of the JIRA aspects of this project have
>>> *definitely* languished (not pointing any fingers here, I'm *at least* as
>>> guilty as anyone on this :) ) - so a big thanks to you and whomever you've
>>> collaborate with in getting this conversation started!
>>> 
>>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith 
>>> wrote:
>>> 
>>>> We’ve concluded our efforts to produce a proposal for changes to the JIRA
>>>> workflow, and they can be found here:
>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>>> <
>>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>>>> 
>>>> 
>>>> I hope there will be broad consensus, but I’m sure it won’t be plain
>>>> sailing.  It would be great to get a discussio

Re: JIRA Workflow Proposals

[Joseph Lynch]

 to see
> how that’s contributed to the project over time or some other similar event.
>
> In summary, I really like the mapping but I also really like the way that
> labels can still be of value.  Also, if we strive to keep the components
> field up to date, there’s really no harm in having the labels.
>
> 
>
> Jeremy
>
> > On Nov 26, 2018, at 8:33 AM, Sankalp Kohli 
> wrote:
> >
> > I have following initial comments on the proposal.
> > 1. Creating a JIRA should have few fields mandatory like platform,
> version, etc. We want to put less burden on someone creating a ticket but I
> feel these are required for opening bugs.
> >
> > 2. What is the flow when a non committer does the first pass of review?
> >
> >
> >
> >> On Nov 26, 2018, at 7:46 PM, Joshua McKenzie 
> wrote:
> >>
> >> 1) Removal of labels: one of the strengths of the current model is
> >> flexibility for groupings of concepts to arise from a user-perspective
> >> (lhf, etc). Calcifying the label concepts into components, categories,
> etc.
> >> is a strict loss of functionality for users to express and categorize
> their
> >> concerns with the project. This feels like an over-correction to our
> >> current lack of discipline cleaning up one-off labels. Counter-proposal:
> >>
> >>  1. We beef up the categories and components as proposed and migrate
> >>  labels to those
> >>  2. We remove the one-off labels that aren't adding value, considering
> >>  aggregating similar labels
> >>  3. We leave the "labels" field intact, perhaps with a bit of guidance
> on
> >>  how to effectively use it
> >>
> >> 2) Required fields on transition: assuming these are required upon
> *issue
> >> creation*, that's placing a significant burden on a user that's seen
> >> something and wants to open a ticket about it, but isn't sure if it's a
> >> "Semantic Failure" or a "Consistency Failure", for instance. If this is,
> >> instead, a field required for transition to other ticket states by the
> >> developer working on it, I think that makes sense.
> >>
> >> 3) Priority Changes: to be blunt, this looks like shuffling chairs on
> the
> >> deck of the titanic on this one - in my experience, most users aren't
> going
> >> to set the priority on tickets when they open them (hence default ==
> major
> >> and most tickets are opened as major), so this is something that will be
> >> either a) left alone so as not to offend those for whom the priority is
> >> *actually* major or consistent with the default, or b) changed by the
> dev
> >> anyway and the added signal from a new "High vs. Urgent" distinction and
> >> communication of developer intent to engage with a ticket is something
> >> that'll be lost on most users that are just reporting something. I don't
> >> have a meaningful counter-proposal at this point as the current problem
> is
> >> more about UX on this field than the signal / noise on the field itself
> IMO.
> >>
> >> A meta question about the "What and Why" of what we're trying to
> accomplish
> >> here: it sounds like what you're looking at is:
> >>
> >>  1. to capture more information
> >>  2. simplify the data entry
> >>  3. nudge people towards more complete and accurate data entry
> >>  4. our ability as a project to measure release quality over time and
> >>  identify when Cassandra is ready for (or due a) release.
> >>
> >> The proposal in its current form makes certain strong inroads in all of
> >> those 4 metrics, but I think the major thing missing is the UX of what
> >> we're thinking about changing:
> >>
> >>  1. Making it easy for / reduce friction for users to report bugs and
> >>  requests into the project JIRA (easy to do things right, hard to do
> things
> >>  wrong) (current proposal is a +1 on "do things right", though I'd argue
> >>  against it being *easy*)
> >>  2. Asking from the users what they can provide about their experience
> >>  and issues and no more
> >>
> >> Philosophically, are we trying to make it easier for people that are
> paid
> >> FT to work on C*, are we trying to make things easier for *users* of C*,
> >> both, neither? Who are we targeting here w/these project changes and
> what
> >> of their issues / problems are we trying to improve?
> >>
> >> And lastly: the TLC and management

Re: JIRA Workflow Proposals

[Jeremy Hanna]

n provide about their experience
>>  and issues and no more
>> 
>> Philosophically, are we trying to make it easier for people that are paid
>> FT to work on C*, are we trying to make things easier for *users* of C*,
>> both, neither? Who are we targeting here w/these project changes and what
>> of their issues / problems are we trying to improve?
>> 
>> And lastly: the TLC and management of the JIRA aspects of this project have
>> *definitely* languished (not pointing any fingers here, I'm *at least* as
>> guilty as anyone on this :) ) - so a big thanks to you and whomever you've
>> collaborate with in getting this conversation started!
>> 
>> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith 
>> wrote:
>> 
>>> We’ve concluded our efforts to produce a proposal for changes to the JIRA
>>> workflow, and they can be found here:
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>> <
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>>> 
>>> 
>>> I hope there will be broad consensus, but I’m sure it won’t be plain
>>> sailing.  It would be great to get a discussion going around the proposal,
>>> so please take some time to read and respond if you think you’ll have a
>>> strong opinion on this topic.
>>> 
>>> There remains an undecided question in our initial proposal, that is
>>> highlighted in the wiki.  Specifically, there was no seemingly objective
>>> winner for the suggested changes to Component (though I have a preference,
>>> that I will express in the ensuing discussion).
>>> 
>>> Other contentious issues may be:
>>> - The removal of ‘labels’ - which is very noisy, the vast majority of
>>> which provide no value, and we expect can be superseded by other suggestions
>>> - The introduction of required fields for certain transitions, some of
>>> which are new (complexity, severity, bug/feature category)
>>> - The introduction of some new transitions (Triage, Review in Progress,
>>> Change Requested)
>>> 
>>> Look forward to hearing your thoughts!
> 
> -
> 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

[Sankalp Kohli]

I have following initial comments on the proposal. 
1. Creating a JIRA should have few fields mandatory like platform, version, 
etc. We want to put less burden on someone creating a ticket but I feel these 
are required for opening bugs. 

2. What is the flow when a non committer does the first pass of review? 



> On Nov 26, 2018, at 7:46 PM, Joshua McKenzie  wrote:
> 
> 1) Removal of labels: one of the strengths of the current model is
> flexibility for groupings of concepts to arise from a user-perspective
> (lhf, etc). Calcifying the label concepts into components, categories, etc.
> is a strict loss of functionality for users to express and categorize their
> concerns with the project. This feels like an over-correction to our
> current lack of discipline cleaning up one-off labels. Counter-proposal:
> 
>   1. We beef up the categories and components as proposed and migrate
>   labels to those
>   2. We remove the one-off labels that aren't adding value, considering
>   aggregating similar labels
>   3. We leave the "labels" field intact, perhaps with a bit of guidance on
>   how to effectively use it
> 
> 2) Required fields on transition: assuming these are required upon *issue
> creation*, that's placing a significant burden on a user that's seen
> something and wants to open a ticket about it, but isn't sure if it's a
> "Semantic Failure" or a "Consistency Failure", for instance. If this is,
> instead, a field required for transition to other ticket states by the
> developer working on it, I think that makes sense.
> 
> 3) Priority Changes: to be blunt, this looks like shuffling chairs on the
> deck of the titanic on this one - in my experience, most users aren't going
> to set the priority on tickets when they open them (hence default == major
> and most tickets are opened as major), so this is something that will be
> either a) left alone so as not to offend those for whom the priority is
> *actually* major or consistent with the default, or b) changed by the dev
> anyway and the added signal from a new "High vs. Urgent" distinction and
> communication of developer intent to engage with a ticket is something
> that'll be lost on most users that are just reporting something. I don't
> have a meaningful counter-proposal at this point as the current problem is
> more about UX on this field than the signal / noise on the field itself IMO.
> 
> A meta question about the "What and Why" of what we're trying to accomplish
> here: it sounds like what you're looking at is:
> 
>   1. to capture more information
>   2. simplify the data entry
>   3. nudge people towards more complete and accurate data entry
>   4. our ability as a project to measure release quality over time and
>   identify when Cassandra is ready for (or due a) release.
> 
> The proposal in its current form makes certain strong inroads in all of
> those 4 metrics, but I think the major thing missing is the UX of what
> we're thinking about changing:
> 
>   1. Making it easy for / reduce friction for users to report bugs and
>   requests into the project JIRA (easy to do things right, hard to do things
>   wrong) (current proposal is a +1 on "do things right", though I'd argue
>   against it being *easy*)
>   2. Asking from the users what they can provide about their experience
>   and issues and no more
> 
> Philosophically, are we trying to make it easier for people that are paid
> FT to work on C*, are we trying to make things easier for *users* of C*,
> both, neither? Who are we targeting here w/these project changes and what
> of their issues / problems are we trying to improve?
> 
> And lastly: the TLC and management of the JIRA aspects of this project have
> *definitely* languished (not pointing any fingers here, I'm *at least* as
> guilty as anyone on this :) ) - so a big thanks to you and whomever you've
> collaborate with in getting this conversation started!
> 
> On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith 
> wrote:
> 
>> We’ve concluded our efforts to produce a proposal for changes to the JIRA
>> workflow, and they can be found here:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>> <
>> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>>> 
>> 
>> I hope there will be broad consensus, but I’m sure it won’t be plain
>> sailing.  It would be great to get a discussion going around the proposal,
>> so please take some time to read and respond if you think you’ll have a
>> strong opinion on this topic.
>> 
>> There remains an undecided question in our initial proposal, that is
>> highlighted in the wiki.  Sp

Re: JIRA Workflow Proposals

[Joshua McKenzie]

1) Removal of labels: one of the strengths of the current model is
flexibility for groupings of concepts to arise from a user-perspective
(lhf, etc). Calcifying the label concepts into components, categories, etc.
is a strict loss of functionality for users to express and categorize their
concerns with the project. This feels like an over-correction to our
current lack of discipline cleaning up one-off labels. Counter-proposal:

   1. We beef up the categories and components as proposed and migrate
   labels to those
   2. We remove the one-off labels that aren't adding value, considering
   aggregating similar labels
   3. We leave the "labels" field intact, perhaps with a bit of guidance on
   how to effectively use it

2) Required fields on transition: assuming these are required upon *issue
creation*, that's placing a significant burden on a user that's seen
something and wants to open a ticket about it, but isn't sure if it's a
"Semantic Failure" or a "Consistency Failure", for instance. If this is,
instead, a field required for transition to other ticket states by the
developer working on it, I think that makes sense.

3) Priority Changes: to be blunt, this looks like shuffling chairs on the
deck of the titanic on this one - in my experience, most users aren't going
to set the priority on tickets when they open them (hence default == major
and most tickets are opened as major), so this is something that will be
either a) left alone so as not to offend those for whom the priority is
*actually* major or consistent with the default, or b) changed by the dev
anyway and the added signal from a new "High vs. Urgent" distinction and
communication of developer intent to engage with a ticket is something
that'll be lost on most users that are just reporting something. I don't
have a meaningful counter-proposal at this point as the current problem is
more about UX on this field than the signal / noise on the field itself IMO.

A meta question about the "What and Why" of what we're trying to accomplish
here: it sounds like what you're looking at is:

   1. to capture more information
   2. simplify the data entry
   3. nudge people towards more complete and accurate data entry
   4. our ability as a project to measure release quality over time and
   identify when Cassandra is ready for (or due a) release.

The proposal in its current form makes certain strong inroads in all of
those 4 metrics, but I think the major thing missing is the UX of what
we're thinking about changing:

   1. Making it easy for / reduce friction for users to report bugs and
   requests into the project JIRA (easy to do things right, hard to do things
   wrong) (current proposal is a +1 on "do things right", though I'd argue
   against it being *easy*)
   2. Asking from the users what they can provide about their experience
   and issues and no more

Philosophically, are we trying to make it easier for people that are paid
FT to work on C*, are we trying to make things easier for *users* of C*,
both, neither? Who are we targeting here w/these project changes and what
of their issues / problems are we trying to improve?

And lastly: the TLC and management of the JIRA aspects of this project have
*definitely* languished (not pointing any fingers here, I'm *at least* as
guilty as anyone on this :) ) - so a big thanks to you and whomever you've
collaborate with in getting this conversation started!

On Mon, Nov 26, 2018 at 8:39 AM Benedict Elliott Smith 
wrote:

> We’ve concluded our efforts to produce a proposal for changes to the JIRA
> workflow, and they can be found here:
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> <
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> >
>
> I hope there will be broad consensus, but I’m sure it won’t be plain
> sailing.  It would be great to get a discussion going around the proposal,
> so please take some time to read and respond if you think you’ll have a
> strong opinion on this topic.
>
> There remains an undecided question in our initial proposal, that is
> highlighted in the wiki.  Specifically, there was no seemingly objective
> winner for the suggested changes to Component (though I have a preference,
> that I will express in the ensuing discussion).
>
> Other contentious issues may be:
>  - The removal of ‘labels’ - which is very noisy, the vast majority of
> which provide no value, and we expect can be superseded by other suggestions
>  - The introduction of required fields for certain transitions, some of
> which are new (complexity, severity, bug/feature category)
>  - The introduction of some new transitions (Triage, Review in Progress,
> Change Requested)
>
> Look forward to hearing your thoughts!

JIRA Workflow Proposals

[Benedict Elliott Smith]

We’ve concluded our efforts to produce a proposal for changes to the JIRA 
workflow, and they can be found here: 
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals 
<https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals>

I hope there will be broad consensus, but I’m sure it won’t be plain sailing.  
It would be great to get a discussion going around the proposal, so please take 
some time to read and respond if you think you’ll have a strong opinion on this 
topic.

There remains an undecided question in our initial proposal, that is 
highlighted in the wiki.  Specifically, there was no seemingly objective winner 
for the suggested changes to Component (though I have a preference, that I will 
express in the ensuing discussion).

Other contentious issues may be:
 - The removal of ‘labels’ - which is very noisy, the vast majority of which 
provide no value, and we expect can be superseded by other suggestions
 - The introduction of required fields for certain transitions, some of which 
are new (complexity, severity, bug/feature category)
 - The introduction of some new transitions (Triage, Review in Progress, Change 
Requested)

Look forward to hearing your thoughts!