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

[Edward Welbourne]

On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote:
>> 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.
>>
>> So the list you have to select from has one more entry to choose from, is
>> that such a big deal?

André Pönitz (18 February 2020 20:39)
> This is not the problem.
>
> More states lead to bikeshedding what would be The Right State for a
> task.

I very much doubt the distinction between In Progress and In Review is
going to involve much bike-shedding.

> Already now there are tasks that get prioritized, and assigned, and
> re-prioritized, re-assigned, "Fix-for-version"-ed, closed, re-opened
> several times. Watchers that e.g. wait for a "Done" there get notified
> each time on such unprogressing transitions, and skipping these sums
> up to quite a bit of unproductive time already now.

True enough; this would introduce one more transition, so one more
e-mail per bug.  None the less, it's a transition that does mean
something useful to those watching - especially those waiting for a fix
- we are a significant step closer to a fix, and there's a patch they
might even be interested in applying locally.  And, as Lorn pointed out,
issues don't have to go through every stage; it'd just be there for the
benefit of those who find it useful.

Yes, we could do that with a tag, although I'm not sure how well Jira's
"scrum board" view would integrate with that.  In any case, adding such
tags would generate mail, just as state transitions would, and
cluttering Jira with a plethora of person-specific and team-specific
tags might not be the clearest way to communicate with folk; in
particular, it'd mean there's no uniform way for teams to communicate
this, making it harder to write tools that can be shared between teams
with similar work-flows.

>> > What's the harm in leaving the task in In Progress state while it's being
>> > reviewed?
>>
>> 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'
>> [...]

> Looks like we are getting to the actual problem here. It's not about
> development after all.

No "getting to" about it - my original mail was quite explicit about the
point of the exercise being clarity of communication with my scrum
master (whose beard is plaited - I would not call his hair pointy).

We've had tasks where the actual coding was done in one sprint but the
review and integration (and waiting for merges up from one branch to
another) have happened in other sprints.  Distinguishing those parts of
the work would make sprint organisation easier.

The co-ordination of development, and communication to stake-holders of
what's going on, are important parts of our process.  To dismiss them
out of hand as "not about development" strikes me as painfully limiting.
Jira is a tool as much for our customers (reporting bugs and getting
feed-back on whether and when we're going to do anything about them) and
our managers as for us.  The addition of an "In Review" state would make
it easier for me to communicate, to everyone with an interest in my
work, something that at least two of them have made clear they want to
know (and that I have commonly wanted to communicate).
I naively imagine other teams have similar needs.

I'm proposing a uniform way to do that, for those teams that want it.

	Eddy.