Conflicting changes on a single issue

[francis]

We see following behaviour on Jira

Assume that you have an issue about tracking a surgery to be performed on Pete.
John and Sarah are both medical assistants that are describing what exactly should be done.

John is assuming that Pete's arm needs to be operated on, while Sarah believes it is the leg (this is a made up example)

So John changes first the summary to 'Operates Pete's arm', and then the description to 'The left arm' and some other details.

At the same time, Sarah is modifying the same issue, and first changes the description to 'The right leg' and some other details (before John's modification is persisted), and then finds out that the summary also needs to be updated to 'Operate Pete's leg'

The way that Jira (cloud) works today is that you will end up with an issue having as summary 'Operate Pete's leg' and description 'The left arm'

How can you avoid this type of inconsistencies?

PS. We tried it out (not the operation)

[John Funk]

Hi Francis,

I don't know that you can overcome the technical part of it, but you can implement other team rules to help. Like only the Assignee can update the Summary and/or Description. And maybe something like you can't change the Assignee without contacting the current Assignee first. Assuming, of course, that is not the rule where automatic assignments happen based on other factors such as transitions. 

[Bill Sheboy]

Hi @francis 

Yes, and to John's answer:

You seem to be describing is a process problem and not a technical one: with different text fields a tool cannot easily determine that two different people ignored the data in the other fields while making changes.

A couple of possible answers to your question of "How can you avoid this type of inconsistencies" are:

• the team writes stories together, and so has a shared understanding of the work
• when a story is created, the summary accurately summarizes the request; then subsequent changes elaborate on that summary (rather than change it)

Kind regards,
Bill

[francis]

Absolutely true, a tool will never stop to enter mitsakes - fully understood.  

Still - what I'm looking for is for the type of update - illustrated in the question - where 2 updates are crossing each other.

Is there an add-on or a technique that would flag that there might be a problem?
There is this add-on https://marketplace.atlassian.com/apps/1211596/whos-looking-for-jira-cloud?hosting=cloud&tab=overview  which lists the users that are accessing the issue view at that moment.

It might be able to extend it to detect conflicting changes.

[Bill Sheboy]

Hi Francis,

I have not used that addon, so I have no input on it.  I just checked and could not find any obvious suggestions for collision detection in the public backlog, and I found a different addon for Confluence to help with this issue.

Regarding the situation of 2 (or more) people updating the same field in Jira Cloud, the resulting behavior depends on the type of field, and my understanding is the last save wins.  For fields like Description which allow unsaved changes it gets more complicated and brittle.  We had a situation where a person had unsaved changes, and eventually saved them months later, and Jira walked over the prior edits with no warnings.

Thanks,
Bill

[John Funk]

I still think you are better off solving by education and policy and not with the tool itself.