osdir.com

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

Re: JIRA Workflow Proposals


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!