osdir.com

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

Re: JIRA Workflow Proposals


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