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

André Pönitz apoenitz at t-online.de
Wed Feb 19 22:34:11 CET 2020


On Wed, Feb 19, 2020 at 09:45:48AM +0000, Edward Welbourne wrote:
> 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?
> 
> > 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.

*shrug*

Assuming that JIRA states are meant to be disjoint and that the names
actually bear some meaning, "In Review" would mean "Not in Progress".

Which already would be an interesting message to the reviewer. Like,
"whatever you do here, that's not considered 'Progress'".

Of course, nobody intents to bui^H^H^Hsend such message, and that's
easily solvable, by either dropping the connection between state names
and meaning, or by dopping the disjointness of states.

What do you prefer? 


> > 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,

Is is?

First, being on review might still not mean getting closer to 'Done'.
Patches get rejected or delayed for real or imagined reasons, nobody
might actually review, a successful review might not be convincing
enough for CI to let it pass etc, etc.

Second, water-level reports on how close something is to being done
is practically never the reason why I watch tasks, I watch them 
because I may need to act once it is resolved. And only then.

> 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.

And to the distraction to those that don't. That's why the 'Verified'
state was removed not that long ago.
 
> 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

We have "Reported_by_X", "Y_thinks_this_is_a_P1", "up", "Earmarked_by_Z",
and a lot more. And it's completely fine to have them. The rule to
handle them is easy: "If you are not fully convinced it is meant for you
it /is/ not meant for you".

> 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.

Can't comment here, as I don't know what kind of tools this refers to.

> > 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).

I am positive an "Eddy-calls-this-Done" label will be explicit enough
to communicate the fact that Eddy calls this "Done" within this
particular relation.

> 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.

Ok, more seriously: I think you want to communicate "I did what I can
do here, for this period of time". This is a valid, and noteworthy
state, but at the same time orthogonal to the existing JIRA states. It
would also apply to an "Won't do", or "Invalid", or whatever else state
you chose after working on the issue. This calls for some markup that 
is orthogonal to existing JIRA states, and a label provides that.

> 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. 

[ . o O ( BINGO! ) ...  ]

> The addition of an "In Review" state would make it easier for me to
> communicate, to everyone with an interest in my work

It doesn't communicate that to me, and I *am* actually interested
in your work. A counter-example. The statement is wronmg.

> something that at least two of them have made clear they want to know
> (and that I have commonly wanted to communicate).

I am not convinced. But I am fairly sure that any rule that implies
that any pair of two out of the One Million Verified Qt Accounts can
introduce a new JIRA state will sooner or later necessitate some
communication with Atlassian.

> I naively imagine other teams have similar needs.

I am naively envying you.

Andre'



More information about the Development mailing list