I don’t think that the JIRA configuration for the https://bahmni.atlassian.net/projects/BAH project reflects the distributed open-source workflow that our community team follows.
The statuses are:
Open
In Analysis
Ready for Development
In Development
Ready for QA
In QA
Closed
Waiting for Customer
Issues:
We do not have a state to reflect that a pull request has been submitted for code review. And this is a very important step! => I propose we introduce a “Code Review Requested” state (typically you’d go from In Development to here, and then from here either back to In Development or forwards to Ready for QA)
“Open” is the wrong name for the initial state. I propose we rename “Open” to "Needs Assessment. (An alternative would be to call this “Requested” or “Proposed”, but I would lean towards “Needs Assessment” to indicate that we should have a standard process for actually assessing these tickets and moving them forwards.)
I think we want two states that can follow after “Needs Assessment”, so I propose we add states for “Backlog” and “Won’t Fix” (Actually I wonder if “Won’t Fix” is supposed to be state=“Closed” with resolution=“Won’t Fix”.) The idea is that tickets would usually go from Needs Assessment => Backlog => In Analysis (or else if they’re rejected they’d go from Needs Assessment => Won’t Fix).
There are no tickets in the “Waiting For Customer” state, and I don’t see how this fits into the core product dev team’s workflow, so I propose we remove “Waiting For Customer”.
As a side-note, we don’t enforce any limits on which transitions can happen between states. I think we should keep it this way for now. If people end up doing lots of incorrect state transitions, then we can change this later, but let’s not spend the extra effort unless it’s needed.
Following this, we should set up a new board (or reconfigure an existing one) called “Bahmni Community Product Development” or “Bahmni Product”. I propose that we do one JIRA sprint for each product release. (In other words we don’t optimize our use of JIRA sprints to drive a Scrum process, but rather we use it to best communicate the overall development status.
Thanks for this, I agree in general.
I definitely agree about 3, no status for ‘Wont’ fix’ but rather a status=‘Closed’, resolution=‘Won’t fix’. We could of course also expand the list of resolutions over time.
We may not enforce the number of transitions, but both entering ‘In analysis’ and ‘In development’ should necessarily set an assignee.
I always felt that the QA statuses don’t fit, perhaps would it be wiser to distinguish between what’s
Done/fixed/resolved, but not merged yet on master, so not yet visible on the QA server. (Is that ‘Ready for QA’?)
Done/fixed/resolved and visible on the QA server. (I guess that’s the current ‘In QA’?)
Done/fixed/resolved and released. This could be status=‘Closed’, resolution=‘Released’, or something equivalent.
Hi @darius@mksd, we’ve been through quite a bit of work in the past year refining how we use Jira at @Jembi, some of which isn’t relevant here, but some thoughts:
Agreed, we’ve found it useful to add code review states ‘Ready for Review’ and ‘In Review’, that are distinct from QA review states.
We use ‘To Do’, which is succint but much the same - ‘Needs Assessment’ sounds clearer.
Agree that ‘Won’t Fix’ would be a resolution for ‘Closed’, rather than a state. Not sure about the ‘Backlog’ state, as I assume tasks that transition to this state would already be in the sprint, and out the backlog? Might just be the name though, would this correspond to something like ‘In Assessment’?
When the first subtask is moved to “In Progress”, transition the story to “In Progress”, and notify the group.
When the final subtask is moved to Done, transition the story to "Ready for QA“, and notify the group.
Auto-assign a task back to the original dev when moving task from “In Review” back to "In Progress”, and notify the group (i.e. when there is more work to be done following code review).
Auto-assign a task back to the original reviewer when moving task from “In Progress” to "In Review”, and notify the group (i.e. for follow-up code reviews).
Auto-assign a subtask to dev when they move the task to “In Progress”, and notify the group.
Send a “Well Done!” message to the group when a story is completed.
To get this right though, we’re quite strict about adding subtasks to stories, and we’ve implemented separate workflows for different Issue Types (stories and bugs go through QA, whereas subtasks go through code review but not QA, and spikes and other improvements don’t go through QA or code review):
So all the incoming issues come into the Needs assessment. This is then further narrowed down to a list “Release/ Sprint Backlog” for the current release/sprint (whatever we decide to call it). (I call this “Release/ sprint backlog” and not only Backlog because there is another bigger Backlog that already exists in Jira, with all those issues migrated from Mingle or all those issue that haven’t been yet assigned a release.)
“In analysis” is the phase of tech and functional analysis of the issue. After this there must be a “Ready for Dev” lane for the cards to move ahead. Some cards may move back to “Release/ Sprint Backlog” or resolved as “wont fix”.
Not sure if we need a " Wont fix lane". We could assign the resolution “Wont fix” and close the card. So that it no longer shows up on the wall.
From the “Ready for Dev” lane, Developers pick up cards to work on. While cards being worked on by the core team move on to Ready for testing from here , the PRs coming in will pass through a " Code review requested" and “In Code review” state.
Cards then move to “Ready for testing”, followed by “In testing” and “Done” finally. Cards should be able to go back to a previous status at any time.
To @mksd 's question on QA statuses : After the “In development” stage, the usual practice has been that there is a quick test of the story/issue on the dev’s local machine before it is pushed to the QA server. This ensures that the first level of check on the functionality is done before the code is pushed. This is usually done with the Dev and the QA (another dev maybe if there is no QA). Thats when we move the card from “In development” to “Ready for QA”. The code is then pushed to the QA server. The person testing the card is then expected to move the card to "In QA " and test it. After satisfactory testing we move it to “Done”.
+1 to not having transition validations and Using “Won’t fix” as a resolution. (I haven’t been able to put resolutions in our current Jira set up. Maybe @mksd can probably help with this one. )
once code has been merged and thus should be available on QA servers, the ticket should go from “Code Review Requested” to “Ready for QA”. (Is this sufficient? Do we ever have code that has passed code review but isn’t yet ready to be merged to master? @mksd@shruthipitta )
“In QA” means that someone has actually claimed this card for testing (during a testing sprint, on their own, etc)
The next step is either “Done” or else back to “Ready For Development” with some comment as to why.
@sruti Is there extra clarity in calling the state “Release/Sprint Backlog” vs just “Backlog” as I proposed? (An alternative could be “Needs Analysis”, but I like this less.)
I don’t see a need for “In Code review”. We have never considered this to be worthwhile in OpenMRS: the github UI is sufficient for communicating between author and reviewer(s).
If we ever do have a situation where code is reviewed but we’re not able to merge it yet for some reason, then we’d also need a status like “Reviewed, Needs Merge”. But I would argue that instead we should work to ignore this scenario. It’s bad for FOSS community development for a dev’s contribution to sit in an unmerged state due to something outside their control.
I have set up the new workflow, and associated it with a new test project. Can someone else please sanity-check this before I switch our real project to use it?
The reason i differentiated both is that, there is a backlog in Jira which basically has all the issues that have no releases tagged. And then there is backlog for a release, which are issues which are tagged for a release but are not part of an active sprint. Finally, all those issues which are marked for the release and for an active sprint then show up on the board. That’s how the current scrum board works. But I agree with the “Backlog” & “In Selected for Development” in the new Kanban workflow set up serve the purpose well enough.
I agree that we can reduce the no.of columns by avoiding this one. If we have to track these PR tickets that need review, we could simply have them tagged with a label as “PR” and they follow the same workflow as any other issue. This is just a suggestion
I tried playing around with the Test Kanban board in Jira. So the workflow set up is :
Backlog => Selected for development => In Progress => Done
A few things I noticed :
For some reason, any new card I create, is automatically assigned a Resolution as “Fixed”
I was unable to transition the cards across the lanes on the board. Also I was unable to assign a Fix version to an issue.
Is there any reason why no column for testing is a part of this workflow?
Does “In progress” mean both analysis and development is in progress? I am asking this because even in our earlier workflow, we had a confusion as to when a card is said to be ready for development - After tech analysis OR before tech Analysis and the developer who picks up the card is responsible for the tech analysis? @shruthipitta@binduak can add to this. Based on what we agree we will have to probably another lane to this new workflow.
Just to confirm, choosing Kanban flow means we no longer will have sprints?
Hmm, I did create this new project with a Kanban board, but that wasn’t really what I was trying to demonstrate/test here. I have only configured the ticket statuses themselves, not the boards yet. I guess that’s confusing.
Our current development workflow has been “continuous flow” rather than using sprints. (And the OpenMRS experience is certainly that scrum-style sprints don’t work so well for a distributed open-source project where most feature development happens in individual projects/implementations, not from the core team.) So my proposal is that we organize our boards around releases (so, not scrum, but also not kanban), with columns for most of the statuses. (I’ll mock this up.) We should still do showcases, independently of whether we use boards for this.
Actually, I think that “Pull Request / Code Review” might be a better name for the status. From a PM’s perspective, maybe that’s still “in development” from an open-source dev’s perspective, it’s better to have a concrete state indicating that it’s up to someone else to get something done.
This must be a mistake on my part. I’ll look into this.
See my above comment, I didn’t actually mean to propose it should look like this. I’ll do some more work and share my actual proposal.
JIRA doesn’t let you drag between multiple statuses in the same column, so you have to open the card and change its state to go between Backlog and Needs Assessment, and between Ready for QA and In QA. (We could split these into columns if need be.)
I plan to activate this next week, so please give comments soon. (Though, we can reorganize the board pretty easily, it’s the statuses themselves that are harder to change after we activate it.)
It feels like that at least during those phases the ticket should be assigned to the developer:
In Development
Needs Code Review
Pull Request / Code Review
Ready for QA
Is it that there is a developer and then someone else finalising the ticket? So ensuring that QA is done and closing the ticket with the appropriate resolution?
If so we could maybe look at adding a second active user to the ticket (a bit like it is done with the ‘Designated Committer’ on some of the OpenMRS JIRA workflows).
