[Development] Proposal: more Jira states to track stages of the work on an issue

Edward Welbourne edward.welbourne at qt.io
Tue Feb 18 11:18:43 CET 2020


On 18/2/20 6:03 AM, Thiago Macieira wrote:
>> I'm with Alexandru here:

I confess I'd understood Alexandru as saying he'd wanted similar in the
past but not been allowed it.  Perhaps I misunderstood ...

>> all ideas to have more states in JIRA start with a good intentions,
>> but eventually people stop using them and just transition through all
>> stages in one go when they've finished the work. For example, people
>> realise they've never changed from Reported to Confirmed before they
>> actually submitted the fix and autotest to Gerrit. I often do that
>> and the task goes from Reported to Confirmed to In Progress in 5
>> seconds. With your proposal, it would go through yet another state in
>> that period.

Lorn Potter (18 February 2020 04:11) replied:
> Stepping through the interim steps is not a requirement, so it is not
> that much difference to go from Reported->In Progress to Reported->In
> Review, really.

... and, likewise, to close a bug straight from In Progress, when that
arises.  I'm not suggesting this should be a state you *have to* pass
through, only that it be available.

> So the list you have to select from has one more entry to choose from,
> is that such a big deal?

Well, yes, it's one more thing; and a slow accretion of "one more thing"
additions will always add up to hassle.  So each addition must deliver
more value than its incremental contribution to that hassle.

>> In all projects I know, the fewer state transitions, the better.

That's clearly not True - there's surely such a thing as taking it too
far (eliminating all transitions, after all, would cripple a bug
tracker) - but I agree that "fewer = better" subject to the constraint
of Getting The Job Done.  I recognise that what I'm asking for isn't
utterly indispensable (like the transitions between Reported, Accepted
and Resolved), but I believe it would improve some work-flows and thus
deliver more value than its cost, much like the In Progress state itself.

>> What's the harm in leaving the task in In Progress state while it's
>> being reviewed?

There is a significant transition in what I'm actually doing, that isn't
reflected in the Jira state.  This matters a lot to me, to my scrum
master and, to a lesser degree, to other members of our team.  I admit
it's mostly irrelevant to everyone else, including the reporter.

> There is no harm, but being able to better distinguish the main
> development phase of a large task from the review stage would benefit
> the 'pointy hairs' (I imagine) because the review process timeline is
> often out of the control of the developer, and as we all know, often
> takes very many iterations. At least that could see that a particular
> bug is being held up not by the developer, but by the review
> process/CI.

Right - and we can split up a task into several stages (reflecting the
practical reality of how we actually do work towards resolving issues in
Jira) when planning our work and communicating to other stake-holders
about how we're moving towards giving them what they want.

> It also helps developers as we could search through 'In-Review' bugs
> to find interesting bugs that need review.

I hadn't thought of that ;^)
Of course, folk can search Gerrit for reviews waiting for attention, but
this would let them actually tie their search into Jira's knowledge of
which things are high priority, or affect the code they're most familiar
with.  So searching for interesting reviews one could contribute to
would be easier.

	Eddy.


More information about the Development mailing list