With recent discussions about Jira Issue Curation, one side-topic has come up: should we try using GitHub Issues instead of Jira?
Right now, some of our repos in the OMRS organization have issues enabled (most don’t), but if you create an issue in GitHub, it is auto-created as a Jira ticket. (This is why I’m making this a different thread - because whether we use GitHub Issues or Jira, we still have to sort out our issue review/curation process. Having a new tool is appealing because we leave behind some noise and complexity - but ultimately we need people to like using the tool so we’re comfortable reviewing issues regularly.)
Several people expressed interest in GitHub issues. Both the FHIR and MF Squad expressed interest in piloting it, but wanted to know what this might look like. I’ve taken a first attempt at summarizing the pro’s and con’s and how it might look if we tried using GitHub issues. We went through this quickly in the PM Squad call today but would like to share and discuss further here.
tl;dr: GitHub issues is much simpler than Jira. We would lose a lot of complexity which may not be a bad thing, but will take some getting used to. Being in one place and the simple automation is appealing. There are add-ons we can buy if we want to regain some of the complexity and project management tools that are in Jira.
Curious to hear if people have any thoughts, or experiences from using GitHub Issues to share
I doubt GitHub issues fits yet for enterprise-level use: multiple projects with boards across projects and a fine control of workflows and accesses. But I stand to be proven false as I love the GitHub UX in general and issues are well integrated in it and consistent with it.
Having said that at Mekom we have adopted GitHub issues for Iniz, while we continue to use Jira internally. In short we use Jira mainly and GitHub issues sometimes
One other main drawback i see besides the analysis of what best suites our enterprise environment is integration between the 2, retiring Jira is so costly since we have a lot seating in it.
That I can only second. There’s so much to do otherwise (MF, ETL, FHIR, … etc) that I can’t really imagine that we would want to invest going through that pain, at least now.
So I’ve contributed to software that was primarily using GitHub issues before (hence some of my concerns). There are a couple of things I’ve observed from this:
Status management is a much more manual affair (although maybe GitHub milestones and projects help with this a bit), i.e., tickets are either open or closed and the status beyond that (e.g. issue has been analysed, someone is actually writing code, issue is ready for review) generally depend on community standards.
“Issues” tend to be opened to address questions about use of the package or configuration issues or other things that may not necessarily directly be a request for code changes. This can be fine in and of itself, but we should be aware of it, especially as it might affect Talk’s status as the “mailing list” for OpenMRS.
Labels are controlled at a per-repo level, which could lead to a higher degree of fragmentation between how statuses and other things are tracked between different repositories.
Another observation I’ll make is that I have seen that even organisations that do use GitHub issues often don’t use it as the source of truth for what is being worked on or for internal priorisation, but as a way of capturing user and community requests.
I’m also not quite sold on the idea that “everything in one place” is a practical goal for a modular application like OpenMRS, partially because an issue reported against one component might have a fix against a different component and partially because some coding changes do need to be coordinated across multiple modules. I think this gets especially acute when creating issues is opened up to a broader audience as people reporting issues are not always going to do the work to figure out the source of the error.
That said, the GitHub UX is great, GitHub Actions give us a good deal of scope for automation and, frankly, Jira does have a lot of complexity that we don’t really need. Besides which, most of the issues I’ve raised can be resolved with a strong set of conventions.
Thanks Ian, that was really helpful. I share your concern in particular about the areas of overlap - having to pick a specific repo to assign an issue to is a bit of a pain and easy to do incorrectly (even just talking about myself!).
FWIW - you can actually set label defaults at the Org level, if you are an Org Owner. Of course we could still end up with per-repo customizations - but that seems to be the situation we are already in in Jira, with so many different projects with so many different workflows and labels and components and issue type conventions.
I’m starting to feel like we’re focusing too much on fixing the tooling rather than the processes. We could go through a concerted effort to apply simpler conventions throughout our existing Jira instance.
@ibacher@dkayiwa and others - what if we were to try things in Jira like a simplified workflow process, less issue types? We do need to connect about our process of reviewing the work requests as they come in, maybe when we do that we could also talk about the possibility of simplifying a few things. Perhaps the process conversation is ideal for our TAC meeting this friday.
We definitely need to have a process conversation. And I’m 100% behind simplifying workflows and issue types. I do think a conversation about Jira vs GitHub, though, is likely to always end up as a conversation about tooling. If we can agree on what the process would look like, we can always adapt either Jira or GitHub to reflect that.
That’s actually good to know. I also seem to recall that at least GitHub projects can be set at the org rather than repo level, which could be helpful for some use-cases where there are cross-cutting concerns.
Just as an additional ,
With the Jira Instance , we could constrain users to only persons with a validated OpenMRS id , hence we can have control to who can work /create our tickets.
I s there any thing as such with github issues ?? in other words can we constrain users to only persons of the OpenMRS organisastion / or probably people with a valid OpenMRS id ??
Fair question @mozzy. In a sense, yes, this is possible in GitHub Issues. We can create projects that are private, either to the OpenMRS Org members, or to a specific Squad/Grouping. Then within that project we could set up workflow steps to show which issues we’d like to work on.
No apology necessary! So far my understanding of this topic overall is that people are on the fence or concerned about the project functionality and finer-grained controls we’d lose if we switched to GitHub. We were going to discuss more in the TAC call last week but didn’t get to this; it’s now on the agenda for this week’s TAC meeting, along with the more critical question of how we can improve our JIRA triaging/management workflows so that our backlog is cleaner and work is clearly ready for people who want to pick things up.
My suggestion is that Jira is the tool that the community has and knows how to use, and is no major compelling reason for the huge effort to move to GitHub issues.
Maybe focus on improving workflows - or even better find resources to help clear out the backlog so that it is more manageable and useable
I 100% agree @ssmusoke, well summarized. I’ll admit that the idea of moving to GH Issues was appealing because of the opportunity to leave some backlog work behind us but the truth it we’d have to deal with it anyway!
Here are some simple thoughts I’d like to propose soon:
Simplifying our workflow steps
Simplifying our Issue types
Simplifying the transitions and form fields and when you’re allowed to edit those fields
However likely there are good reasons that things are the way they are, which we’ll work through together. I’ll especially be looking for your expertise and wisdom @dkayiwa as we start working through more issue management together Hoping to present some suggestions at the TAC call on Friday.
