[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JIRA Workflow Proposals

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 <jmckenzie@xxxxxxxxxx> 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 <benedict@xxxxxxxxxx>
> 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 <jmckenzie@xxxxxxxxxx> 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 <
>> benedict@xxxxxxxxxx>
>>> 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 <kohlisankalp@xxxxxxxxx>
>> 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 <jmckenzie@xxxxxxxxxx>
>>>> 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 <
>>>> benedict@xxxxxxxxxx>
>>>>>> wrote:
>>>>>>> We’ve concluded our efforts to produce a proposal for changes to the
>>>> JIRA
>>>>>>> workflow, and they can be found here:
>>>>>>> <
>>>>>>> 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-unsubscribe@xxxxxxxxxxxxxxxxxxxx
>>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx

To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx