Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

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

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

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

Re: JIRA Workflow Proposals

[Joshua McKenzie]

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

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

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

Re: JIRA Workflow Proposals

[Joshua McKenzie]

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

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

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

Thanks Jo for the feedback too!

I’ll keep my responses brief as there are already a lot of discussions in 
flight.

> On 26 Nov 2018, at 16:24, Joseph Lynch  wrote:
> 
> Benedict,
> 
> Thank you for putting this document together, I think something like this
> will really improve the quality and usefulness of the Jira tickets!
> 
> A few pieces of overall feedback on the proposal:
> * I agree with Jeremy and Joshua on keeping labels. Labels are the only way
> that contributors without access to the Jira project configuration can use
> to try to group related tickets together and while I agree stronger and
> well curated components are valuable, labels are a valuable supplement (and
> they natively work with search so you can link to a group of tickets really
> easily)

Let’s engage on this further in the other discussion to avoid fragmentation.

> * Throughout the text there are various elements only available for bugs or
> features or both (e.g. Bug Category vs Feature Category), which I find hard
> to keep track of in the body of the text. Maybe we can separate the
> document into "Bug Fields" and "Feature Fields" ("Improvement Fields"?)?

Most fields affect everything, but the only new fields that are bug-specific 
are actually adjacent right now: Severity, Bug Category and Discovered By.  I 
will try to make this clearer.  The only feature-specific field is its bug 
counterpart (i.e. Feature Category, or Change Category).

> * I think it's pretty odd that only "jira contributors" can assign tickets
> (even to themselves), and this proposal seems to make that go further in
> that contributors are the only ones who can move tickets out of triage into
> the open state. I'm somewhat concerned that tickets will just languish in
> triage state and unassigned because the person who cut the issue can't move
> it to open and can't assign themselves to fix it... If we had an SLO on
> triage like "an expert in the tagged category will triage new tickets
> within three days" I'd feel different but I'm not sure how/if we can offer
> that. To be clear I like the Triage/Awaiting Feedback state to indicate
> that we need more details from the reporter, but I think if a ticket stays
> in Triage for more than some amount of time it should be because a
> contributor has triaged it and has asked for more information and not
> because nobody is looking (maybe we should even auto-close triage state
> tickets after some period of inactivity).

Yes, one absolute goal of Triage is that we use it to ensure tickets are 
promptly answered (triaged) by a contributor knowledgeable in the area.  These 
are all great suggestions, and I have my own ideas here, but this is probably 
out of scope.  This change hopefully provides a foundation, and we can follow 
up with a separate discussion on how to best utilise it? 

> * Can we clarify how users can receive emails on Jiras awaiting triage
> (perhaps a mailing list they can join that gets emails when Jiras are
> cut).  I know this would really help me with knowing that new Jiras have
> been cut and I can help triage them or something and afaik it isn't
> currently possible/documented.

Right now the commits@ mailing list sends out all JIRA changes, and it would be 
easy to filter to new creations.  You can also have JIRA email you the tickets 
that answer a query (e.g. those in the Triage state).

> I'm still reading through the entire document, but so far I have the
> following specific feedback:
> * Instead of "Since Version" I'd recommend just having "Versions" for all
> issues since bugs can apply in earlier version but not later ones. "Fix
> Versions" then refers to the versions that have any fix or commit related
> to that bug/feature.

My only concern here is that there is no way to create a range.  This would be 
optimal, but ‘Version(s)’ implies listing all affected versions, which would be 
impossible!  And 3.0.x is not practical, since it could affect only versions 
3.0.3 - 3.0.11, say.  I’m open to JIRA-compatible suggestions here?

> * For "Platform" should we include an "Other" field that allows users to
> provide additional free-form context? I know that having a free form text
> has helped me provide additional context like "NVMe SSDs" so that reviewers
> don't start with "have you checked your drives are not slow". Worst case
> this can be included in the description but personally I like separation of
> environment description from bug/improvement description.

If we maintain the ‘Environment’ field as proposed in the other thread we can 
capture this there, but I would prefer we try to capture this in the Platform 
options as quickly as possible.  A quick message to #cassandra-dev on IRC, or 
an email to dev@ should let somebody quickly add this option, and I will add it 
to the list now - which is definitely not complete as yet.

> * Huge +1 to the "Review in Progress" vs "Change Requested", that will
> really help new contributors know when they need to make 

Re: JIRA Workflow Proposals

[Benedict Elliott Smith]

Thanks everyone for the quick initial feedback!  

I’m going to aggregate my responses here, to try and avoid too much 
fragmentation of discussion; we’ll see how sensible this is.

===Labels===
I’m not irreconcilably against keeping labels, I just think on balance it’s 
better to remove them.  I spent a while looking at the existing labels, and 
they entirely paper over inadequacies we have currently.  I think labels have 
been a crutch we’ve used to avoid better hygiene.

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

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.

===Priorities===
You may be right that the High priority is not necessary, but I think it is 
useful for members of the project to flag tickets they plan to prioritise.  The 
intention was for this to simply indicate that some _contributor_ values this 
ticket above others, and probably intends to address it within the next year.  
I would be OK with having only (Wish), Low, Normal and Urgent though.  What do 
other people think?

===Josh (remainder)===
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.  They should be expected to understand the problem and 
systems well enough to provide an initial assessment of the priority, severity, 
complexity, affected components and bug/change category.  These can of course 
be revised, but we benefit from a first assessment for monitoring the 
outstanding work - right now we’re really bad at managing the work outstanding 
unless it was filed by a committer.

FWIW, and in conjunction with the above conversation on priorities, I would 
propose only contributors are permitted to edit the JIRA once it is created, 
and that non-contributors file a ticket without being able to set Priority, 
since this is something for the project to manage, and only causes conflict 
when users feel empowered to stipulate this. 

===Mandatory Platform, Version, etc===
As above with Triage, the plan is for essentially no information to be required 
on creation, but on transition to Open.

The proposal as it stands suggests removing the Environment field, since is was 
poorly maintained.  This was intended to capture the reporter’s platform, if 
any.  Perhaps we could instead make it required only on ticket creation?

For Platform, we haven’t made it required because it was to mark those issues 
that _exclusively_ affect these platforms.  Perhaps it would make sense to 
introduce an ‘All’ flag, which would permit us to make this required on ‘Patch 
Available'?

'Since Version' is already required on transition to ‘Patch Available’ when the 
assignee should have enough context to answer the question.



> On 26 Nov 2018, at 15:05, Jeremy Hanna  wrote:
> 
> Regarding labels, I am personally a fan of both - the mapping of commonly 
> used labels to things like components, features, tools, etc. as well as 
> keeping labels for newer and more arbitrary groupings.  I’ve tried to 
> maintain certain labels like virtual-tables, lcs, lwt, fqltool, etc because 
> there are new things (e.g. fqltool and virtual tables) that we don’t 
> immediately make into components and it's really nice to group them to see 
> where there might be stability or feature specific (thinking virtual tables) 
> items.  I agree that arbitrary and misspelled labels make things a bit noisy 
> but as long as we strive to use the components/features and do some periodic 
> upkeep of labels.  By periodic upkeep I mean, converting new labels into 
> components or what have you.  Beyond new features or arbitrary groupings, it 
> might have been nice to have had ngcc labeled tickets 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 

Re: JIRA Workflow Proposals

[Joseph Lynch]

Benedict,

Thank you for putting this document together, I think something like this
will really improve the quality and usefulness of the Jira tickets!

A few pieces of overall feedback on the proposal:
* I agree with Jeremy and Joshua on keeping labels. Labels are the only way
that contributors without access to the Jira project configuration can use
to try to group related tickets together and while I agree stronger and
well curated components are valuable, labels are a valuable supplement (and
they natively work with search so you can link to a group of tickets really
easily)
* Throughout the text there are various elements only available for bugs or
features or both (e.g. Bug Category vs Feature Category), which I find hard
to keep track of in the body of the text. Maybe we can separate the
document into "Bug Fields" and "Feature Fields" ("Improvement Fields"?)?
* I think it's pretty odd that only "jira contributors" can assign tickets
(even to themselves), and this proposal seems to make that go further in
that contributors are the only ones who can move tickets out of triage into
the open state. I'm somewhat concerned that tickets will just languish in
triage state and unassigned because the person who cut the issue can't move
it to open and can't assign themselves to fix it... If we had an SLO on
triage like "an expert in the tagged category will triage new tickets
within three days" I'd feel different but I'm not sure how/if we can offer
that. To be clear I like the Triage/Awaiting Feedback state to indicate
that we need more details from the reporter, but I think if a ticket stays
in Triage for more than some amount of time it should be because a
contributor has triaged it and has asked for more information and not
because nobody is looking (maybe we should even auto-close triage state
tickets after some period of inactivity).
* Can we clarify how users can receive emails on Jiras awaiting triage
(perhaps a mailing list they can join that gets emails when Jiras are
cut).  I know this would really help me with knowing that new Jiras have
been cut and I can help triage them or something and afaik it isn't
currently possible/documented.

I'm still reading through the entire document, but so far I have the
following specific feedback:
* Instead of "Since Version" I'd recommend just having "Versions" for all
issues since bugs can apply in earlier version but not later ones. "Fix
Versions" then refers to the versions that have any fix or commit related
to that bug/feature.
* For "Platform" should we include an "Other" field that allows users to
provide additional free-form context? I know that having a free form text
has helped me provide additional context like "NVMe SSDs" so that reviewers
don't start with "have you checked your drives are not slow". Worst case
this can be included in the description but personally I like separation of
environment description from bug/improvement description.
* Huge +1 to the "Review in Progress" vs "Change Requested", that will
really help new contributors know when they need to make changes.
* For the workflow how can we provide some guidance for contributors to get
high level feedback before they get to the "Patch Available", maybe we
explicitly indicate that before transitioning to "In Progress" the reviewer
should be found on IRC or the mailing list and they should have signed off
on the high level idea/issue? Maybe this should be part of the new "Triage"
step? I feel one of the more frustrating issues for new contributors is to
do the work and then get the "well what if you did it a completely
different way" feedback.

I'll try to finish internalizing the rest of the document later today and
provide more specific feedback. Thanks again for starting this discussion
and I look forward to the resulting updates!

-Joey

On Mon, Nov 26, 2018 at 7:06 AM Jeremy Hanna 
wrote:

> Regarding labels, I am personally a fan of both - the mapping of commonly
> used labels to things like components, features, tools, etc. as well as
> keeping labels for newer and more arbitrary groupings.  I’ve tried to
> maintain certain labels like virtual-tables, lcs, lwt, fqltool, etc because
> there are new things (e.g. fqltool and virtual tables) that we don’t
> immediately make into components and it's really nice to group them to see
> where there might be stability or feature specific (thinking virtual
> tables) items.  I agree that arbitrary and misspelled labels make things a
> bit noisy but as long as we strive to use the components/features and do
> some periodic upkeep of labels.  By periodic upkeep I mean, converting new
> labels into components or what have you.  Beyond new features or arbitrary
> groupings, it might have been nice to have had ngcc labeled tickets 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 

Re: JIRA Workflow Proposals

[Jeremy Hanna]

Regarding labels, I am personally a fan of both - the mapping of commonly used 
labels to things like components, features, tools, etc. as well as keeping 
labels for newer and more arbitrary groupings.  I’ve tried to maintain certain 
labels like virtual-tables, lcs, lwt, fqltool, etc because there are new things 
(e.g. fqltool and virtual tables) that we don’t immediately make into 
components and it's really nice to group them to see where there might be 
stability or feature specific (thinking virtual tables) items.  I agree that 
arbitrary and misspelled labels make things a bit noisy but as long as we 
strive to use the components/features and do some periodic upkeep of labels.  
By periodic upkeep I mean, converting new labels into components or what have 
you.  Beyond new features or arbitrary groupings, it might have been nice to 
have had ngcc labeled tickets 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 of the JIRA aspects of this 

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

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 


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: Inter-node messaging latency

[sankalp kohli]

Inter-node messaging is rewritten using Netty in 4.0. It will be better to
test it using that as potential changes will mostly land on top of that.

On Mon, Nov 26, 2018 at 7:39 AM Yuji Ito  wrote:

> Hi,
>
> I'm investigating LWT performance with C* 3.11.3.
> It looks that the performance is bounded by messaging latency when many
> requests are issued concurrently.
>
> According to the source code, the number of messaging threads per node is
> only 1 thread for incoming and 1 thread for outbound "small" message to
> another node.
>
> I guess these threads are frequently interrupted because many threads are
> executed when many requests are issued.
> Especially, I think it affects the LWT performance when many LWT requests
> which need lots of inter-node messaging are issued.
>
> I measured that latency. It took 2.5 ms in average to enqueue a message at
> a node and to receive the message at the **same** node with 96 concurrent
> LWT writes.
> Is it normal? I think it is too big latency, though a message was sent to
> the same node.
>
> Decreasing numbers of other threads like `concurrent_counter_writes`,
> `concurrent_materialized_view_writes` reduced a bit the latency.
> Can I change any other parameter to reduce the latency?
> I've tried using message coalescing, but they didn't reduce that.
>
> * Environment
> - 3 node cluster
> - Replication factor: 3
> - Node instance: AWS EC2 i3.xlarge
>
> * C* configuration
> - Apache Cassandra 3.11.3
> - commitlog_sync: batch
> - concurrent_reads: 32 (default)
> - concurrent_writes: 32 (default)
>
> Thanks,
> Yuji
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org