Jira Improvement Plan, Part 2: TRUNK WORKFLOW. Replace confusing RA workflow to use the TRUNK workflow.

Tags: #<Tag:0x00007f23dbaa1620>

Since joining the OMRS community, I have repeatedly heard concerns about the Jira workflow that the RefApp uses. For example:

  • “The states and workflow steps are confusing”
  • “I can merge the GitHub PR but I can’t even figure out how to clearly close this ticket”
  • “It doesn’t seem like I have the permissions to close this”

“Why don’t we just use the same workflow as TRUNK?”

I’ve heard this one the most often: In Jira Issue comments, PM Team calls, Slack messages, and TAC calls. I’ve heard the idea discussed in the PM Team call, the Jira Ninja calls, and other informal forums before, and it’s always been well-received.

So, friends, it’s time.

Proposal: In 1 week, we’ll change all the Jira projects using the RefApp workflow to use the TRUNK workflow.

  • LET’S DO IT!
  • I have concerns - I’ll explain in a reply below

0 voters

What about the tickets still in the funky RefApp stages?

I have reviewed all the tickets that would be impacted. Based on that review, here’s where they would belong appropriately - I can ensure they get moved to the right corresponding status. Ignoring the backlog, this will only impact a grand total of 91 tickets being used in some way. This is way less substantial than the work we had to do to clean up 1,000’s of issues during the Graveyard project. And I believe each of these statuses does have a relevant match in the TRUNK workflow:

But wait - isn’t the TRUNK workflow still pretty complex and confusing?

I agree. We need to fix this, and we started discussing this a few months ago - but first, let’s start simpler, and switch to a workflow most people are already familiar with.

Will this impact projects using their own custom workflow?

No. Only projects using the same workflow as RA. Eventually, I would like to see us be mostly standardized so there is less confusion around the community, but that’s a problem for another day.

CC @cintiadr @permissionerror @burke @dkayiwa @mseaton @mogoodrich @bistenes @ibacher @herbert24 @mozzy @gcliff @k.joseph @irenyak1 @jwnasambu - and please CC others you think might care about this :slight_smile:

Sure i think i vote for this , :100:
I personaly dont like so much the RA workflow :slightly_smiling_face:

1 Like

@grace thanks for this :: :ok_hand:

the RA workflow is not effective in some cases particularly when it comes to testing changes made ie the issue always remains assigned to the tester and not the dev who actually worked on the ticket

1 Like

Good point Cliff, yeah I noticed that too; in order for me to close tickets, I have to assign them to myself as the tester, even if I did zero work on them - which seems wrong!

yeah very true

i raised the same issue last year


When an issue has been closed or marked accepted in RA , that status cant be reverted (re-opened) in case some more work is required on that same ticket ,which is not the case with other Project workflows

Ah thanks for pointing out that former Talk thread from last year, Cliff! Looks like there was consensus even a year ago that the RA workflow was undesireable.

W.r.t. Burke’s points there about Agile / Columns - I’ll have to find a way around that as we use the Agile boards quite often across our projects. But I’m sure we can figure it out.

1 Like

My understanding of JIRA workflows is that you have to choose between an agile workflow (that lets you drag & drop issues in a board, modify columns in a board, etc.) OR a classic workflow. After the agile workflow option was introduced into JIRA, we tried to standardize projects on either the “OpenMRS workflow” (used by TRUNK) or the agile workflow. The RefApp workflow may have been creating during that evolution.

As I was refreshing my knowledge of workflows in JIRA, I happened upon next-gen projects and what sounds like a much better approach now in JIRA. When trying to figure out how to enable these in our JIRA server, I learned it’s not an option. In fact…

Atlassian is moving to a cloud-only service! So, our self-hosted JIRA server will get no more updates and will no longer be supported. So, choose whatever workflow works best for now and perhaps we should start planning for migrating to JIRA cloud (where we can use next-gen projects with much more friendly workflows).


So, at this moment, 10 of the 10 people who voted have said “LET’S DO IT”. So I’ll move forward with making these changes.

Is this the first time we’ve achieved 100% agreement on something? :thinking: Who knew Jira could bring us all together like this :joy:

1 Like

Never heard of this before. You must be a magician. :smile:

1 Like

Hark, it is done! :slight_smile:

Projects updated

Projects updated (changed from using the “OpenMRS Agile Workflow 2” to “OpenMRS Global Workflow Scheme”):

  • Reference Application
  • Reference Application Quality Assurance
  • QA Framework
  • Radiology Module
  • Data Entry Statistics

Ticket View: Before vs After

If your ticket was “In Development” before:

Vs. if your ticket was “In Development” after:

Boards are working as expected

I confirmed that the collaborative Boards we’ve been using (e.g. to manage the RefApp release and to manage QA tickets across projects) are still working as desired.

If anyone runs into issues with tickets not showing up on Boards as expected, go to BoardConfigure BoardColumns and double check that all your statuses have been mapped (aka that nothing shows up here: )

Map of the Changes

I realized too that “Waiting for analysis” should be “Waiting on information”. So here’s how the final map looks: image


let me do some cleaning up of our qa board, other affected boards may need to have columns updated as well

are you planning to delete those unactivated trailing statuses?


@k.joseph you are welcome to do so.

As mentioned in the post above, I did already double-check the QA board and everything was displaying as expected. Did you see something differently?

i needed some layout updates, i have made the needed changes

1 Like

I hope the updated boards statuses are permission sensitive!