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
0voters
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.
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
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!
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.
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).
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 Board → Configure Board → Columns 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:
Who knew Jira could bring us all together like this 
