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

[Volker Hilsheimer]

> On 19 Feb 2020, at 10:45, Edward Welbourne <edward.welbourne at qt.io> wrote:
> 
>>>> 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.


Even when doing development (as opposed to the pointy-haired work), I benefit from having tools that help me to maintain a work-in-progress limit, that allow me to see what state the work someone else is doing is in (because I might depend on it or just be curios about it), or allow me to signal to customers waiting for the fix that they might want to have a look at a proposed change, even if they don't have an account on Gerrit.

The Qt Project defines “code review” as an explicit step that contributions have to go through. Given that it takes a substantial amount of time to get things through review, I think it would make the JIRA-model of how work happens a bit more useful if it would reflect the way that work actually happens.

So, I support introducing this as an optional state.

Cheers,
Volker