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

[Maurice Kalinowski]

Hi,

Just adding in another vote for introducing a “In Review/Integration” state.
As a disclaimer, I am working in the same team as Eddy.

The reason I see it beneficial is to have better visibility on the progress of working on a certain task. Eddy already made it clear that while something is “in review” or in the process of getting integrated or “waiting for other changes to merge”, there is no active work on this task happening. Defining that as “In Progress” is misleading.

Some people indicated that it feels like pressing a process into the workflow. I would like to highlight that this is absolutely not the case. Neither is this a PM decision or anything alike. It’s simply that recently we figured that with running sprints, the time spend on coding itself is only a fraction of time until a task gets resolved. We have had multiple (maybe even the majority) incidents of tasks running/sliding through multiple sprints, as we were not able to merge.
To repeat, the idea is to improve on the visibility of a state of a task.


Some might now say “Well, if integration (or CI) is the problem, then fix this rather than introduce another state”.
That’s a valid point. But only if there are evident indicators. Personally, I prefer to have metrics proving a point, and that might be one mean to achieve this. Heck, we might even get to a point that this is not needed anymore, as everything goes super smooth (ie 5 minutes from issue raised to integration done reference before). But first, I do not see this happening within the foreseeable future. Secondly, are we really that gridlocked to not change anything at all because it might be revisited at some point?


What I also miss in this thread is a suggestion on how this could be handled differently?
One idea which came up in discussions is to declare an issue as “blocked” while it is waiting for integration. But imho that does not make any sense either. First, because blocked is in the “Open” State, which indicates that no one is currently looking at it at all and the task is free to grab by anyone. Furthermore, “blocked” usually means other external factors to justify this state.

I’d also like to share the link to Atlassian’s workflow proposal on how to create an agile workflow in JIRA.
https://www.atlassian.com/agile/project-management/workflow

Note that this also includes two separate “active” states.

BR,
Maurice




> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Edward Welbourne
> Sent: Thursday, February 20, 2020 2:37 PM
> To: Tobias Hunger <Tobias.Hunger at qt.io>
> Cc: development at qt-project.org
> Subject: Re: [Development] Proposal: more Jira states to track stages of the
> work on an issue
> 
> 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.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development