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

[Edward Welbourne]

On 17/02/2020 10:13, Edward Welbourne wrote:
>> We currently have an "In Progress" state.  In practice when I work on
>> an issue, I initially do the work, then put that up for review; the
>> review phase takes up fragments of my time for a while, unlike the
>> main work phase, which is closer to full-time.  I have more control
>> over (and a better ability to estimate) how long the actual work
>> takes, while review (and subsequent integration) depends on factors
>> outside my control, that are harder to estimate.
>>
>> (Sometimes, under the present branching model, I also have to put
>> work on hold until other work merges up for me to rebase it onto.
>> However, that complication shall go away soon, so I'll ignore it.)
>>
>> When my team is planning sprints, our scrum master wants to know what
>> tasks I'll be working on, and what counts as "Done" for each of them.
>> Having a separate state for "In Review", distinct from "In Progress",
>> would let us distinguish the relatively plannable, and intense, part
>> of the work from the part that (often happens in a later sprint, and)
>> takes up a smaller proportion of my time but may take longer.

Oliver Wolff (20 February 2020 09:12)
> I have never worked in scrum, but what difference does it make there?
> The task is not done, as long as it is not in the done state. If the
> review takes to long, give people from your scrum team more time for
> review. If the major hassle is CI, we would need an "Integrating"
> state to see how bad our CI is. But in the end your task is not
> done. Isn't that what your scrum master (and other stakeholders) are
> interested in?

It's a fair point: however, a strict adherence to each work item in the
sprint being a whole Jira Task would mean that many of the tasks I aim
to get done for Qt 6 can't be attempted, because they won't fit into a
single sprint.  A major reworking of a complex body of code can
sometimes be fitted into a fortnight, but getting the review (and
integration) done in the same fortnight is unlikely (especially at
present, when I'm doing some parts of the work on 5.15 or earlier and
having to wait for them to merge up to dev before I can continue with
the work that's only for Qt 6).

So the only way to make the Definition of Done be that the Jira task is
closed is to artificially make lots of sub-tasks, that ask for code to
be written and sent for review and are Done when that happens,
regardless of whether it's been reviewed or integrated.  This would mean
creating artificial sub-tasks where really they'd be better represented
by just one task that has an extra transition.

I should note that we're not dogmatically following scrum; we're only
lifting methods and approaches from it, to see what works for our work
and the ways it can progress.

>> So I'd like to modify our Jira work-flows to include a distinct "In
>> Review" state for when I've completed the main work and am either
>> waiting for review or responding to reviewers' comments.  Of course, if
>> those comments prompt me to go back and start over, I'll also want to be
>> able to go back to the "In Progress" state from it.
>>
>> Does anyone have any objection to this, or suggestions for a better way
>> to handle the relevant work-flow transition ?  If not, I'm hoping Alex
>> can work out how to implement what I want ...

> I am afraid that this will just lead to more mails sent by JIRA. I do
> not see a clear benefit, as (as said before) the task is not done. Being
> in review and in integration does not need any new state, because it
> does not give useful additional information.

I believe this *is* useful additional information, though: code has been
written, or reworked, and I've tested it to at least my satisfaction.
The remaining work to be done - and there typically shall be some - is
the work that arises in response to review.

> If I am bored and want to do reviews, I can just go to codereview and
> will find more than enough open patches that are waiting for reviews.
> There is no need to take a detour via JIRA for that.

On the other hand, if you could search Jira for it, you'd be able to
take into account the priority of the issue the reviewed change
resolves; you could prioritise review in response to the significance of
the bugs being fixed.  Equally, you could search by component or any of
the other ways that Jira distinguishes tasks.  So, while you can surely
find things to review in Gerrit, Jira would be able to give you better
ways to refine your search.  Albeit this is only a secondary win, rather
than the initial point of the exercise.

> All in all I am with Andre' here. It looks like this is just for the
> sake of following some process.

To some degree it is indeed for the sake of following a process: on the
other hand, that process has its value and can be made more effective if
the tools we use - notably Jira in this case - help us to make clear
what work is at what stage in the process.  Process is important: good
process can enable a project to progress more confidently and recognise
coming problems sooner.

> If reviews and integrations take too long actions should be taken to
> fix that, but adding another JIRA task as a dumping ground will not
> help anyone.

I presume you meant "state" rather than "task" - as it happens, what I'm
trying to avoid is artificially adding lots of extra Jira tasks, purely
for the sake of supporting a process.  A separate "In Review" state
would avoid creating lots of "Write the code" sub-tasks purely for the
sake of having a ticket to close.

	Eddy.