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

[Edward Welbourne]

On Mon, 2020-02-17 at 09:13 +0000, 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.

Tobias Hunger (20 February 2020 10:00) replied:
> If the review process does not ever result in a significant amount of
> work (== no patch is ever rejected or significantly changed do to a
> review process), then we should reevaluate the review process. If this
> is indeed the case, then Gerrit has degenerated into a place to
> discuss formatting -- something we could have clang-format take care
> of automatically!
>
> If our review process is more than a formality then it might result in a
> significant amount of work -- the patch can be rejected or you might end up
> redoing significant parts of the code. In that case I do not see how you can
> consider your original task done before the review is complete.
>
> In both cases, IMHO having a separate state in JIRA provides very limited
> benefit.

I'm not suggesting or claiming either of those things, nor are they any
part of the case I'm making for having a separate state in Jira.

I'm better able to estimate how long I'll take to do the work before
review than to estimate the time it'll take for that work to get through
review; but, usually, the amount of *my* time that'll be taken up by the
work during review is small compared to the amount of work I do before
sending it for review.  So, when it comes to planning my work and
communicating what I'm doing and when I expect it to be done, there is a
vast difference between the work I do before review and the work I do in
review.

* Before review: more or less full-time work, taking relatively
  predictable large amounts of my time over a relatively predictable
  calendar duration.

* In review: sporadic work, usually cumulatively smaller than the
  previous, happens reactively, I can only guess roughly how much of my
  time that'll take before reviewers tell me what to fix and I don't
  know how much calendar delay it'll involve.

Distinguishing these two phases of the work is useful to me, it's useful
to management and product management, it's potentially useful to others.
Users affected by what I'm fixing may also benefit from being alerted to
the start of review, if they're in a position to apply my patch and gain
its benefits right away (albeit with some risk that, hopefully, review
serves to reduce).

> The code review process is meant to improve code quality. If this benefits is
> outweighted by reduced productivity due to the review overhead, then we should
> re-examine the topic of code review, not work around the issue in JIRA.
>
> We did introduce the code review process we use today in Nokia when we were a
> much different organization. Maybe we need to adjust our processes to the
> environment we work in nowadays?

That's a whole other question and, if you believe either of the concerns
you described above is in fact a real issue, I encourage you to start a
separate thread, giving your reasons for believing our code review
process costs us more than it gains us.  I don't believe that, but if
you do then we need to discuss it and perhaps change our process,
which might indeed make my proposal redundant,

	Eddy.