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

[grace (Grace Potma)]

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

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

[mozzy (Moses Mutesasira)]

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

[gcliff (CLIFF GITA)]

@grace thanks for this ::

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

[grace (Grace Potma)]

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!

[gcliff (CLIFF GITA)]

yeah very true

i raised the same issue last year

Reference application issue evaluation process

Hello all; Currently when a dev works on an issue mainly from the reference application and submits it for review and testing in order to be merged ,the issue remains assigned to the person who does the testing and the merging not the dev who raised the pr which i think needs to be rectified as compared to the way its done with reviewing and merging of issues in core. Am proposing that if possible then we should adopt the workflow in core were the issue remains assigned to the dev who did the…

[mozzy (Moses Mutesasira)]

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

[grace (Grace Potma)]

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.

[burke (Burke Mamlin)]

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

[grace (Grace Potma)]

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? Who knew Jira could bring us all together like this

[dkayiwa (Daniel Kayiwa)]

@grace

Is this the first time we’ve achieved 100% agreement on something?

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

[grace (Grace Potma)]

Hark, it is done!

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

[k.joseph (Kaweesi Joseph)]

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

[k.joseph (Kaweesi Joseph)]

are you planning to delete those unactivated trailing statuses?

[grace (Grace Potma)]

@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?

[k.joseph (Kaweesi Joseph)]

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

[k.joseph (Kaweesi Joseph)]

I hope the updated boards statuses are permission sensitive!