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

Re: JIRA Workflow Proposals

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

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

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

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

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

This is explicitly only for the Bug issue type.

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

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

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

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

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

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

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

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

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

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

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

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

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

> As for workflow changes, I don't have a real opinion on that yet and
> like to give this some more thoughts. But the suggested review status
> changes are something I'd definitely like to see happening.
> On 04.12.18 20:12, Benedict Elliott Smith wrote:
>> Ok, so after an initial flurry everyone has lost interest :)
>> I think we should take a quick poll (not a vote), on people’s positions on the questions raised so far.  If people could try to take the time to stake a +1/-1, or A/B, for each item, that would be really great.  This poll will not be the end of discussions, but will (hopefully) at least draw a 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 <scott@xxxxxxxxxxxxxx> wrote:
>>> If I read Josh’s reply right, I think the suggestion is to periodically review active labels and promote those that are demonstrably useful to components (cf. folksonomy -> taxonomy<>). I hadn’t read the reply as 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:
>>> –––
>>> 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 (benedict@xxxxxxxxxx<mailto:benedict@xxxxxxxxxx>) 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 <benedict@xxxxxxxxxx> 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 <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
>>> ---------------------------------------------------------------------
>>> 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