osdir.com

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

Re: JIRA Workflow Proposals


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