Discussion: Move issues to github?

Hi all,

we have been using JIRA for quite a while now and amassed a huge pile of tickets. In general it seems that JIRA is not used much for a variety of reasons. I heard:

  • complicated
  • slow
  • confusing

Additionally it’s another tool to work with.

What I am seeing is, that a lot of tickets get no or very late answers, there is no clear process of triaging and getting rid of tickets again and we rarely use the actual project planning featuers (like boards).

So the suggestion is to switch tools and the primary suggestion is to move to github issues.

I would like to hear opinions and maybe alternatives to github issues if there are any before starting a poll about this.

Cheers!

1 Like

My personal view is that I rarely log in to jira. I don’t like it, it’s too much for casual use. And it is by now a huge heap of tickets that I have fear of touching :wink:

So I would like to move to github issues and bring in clear processes of how to deal with incoming tickets. Additioanlly there are lots of third party tools for github issues now that allow us to create boards and what not.

I posted my opinion about this on slack already, it comes down to:

  • Jira feels like it lives completely out of the workflow of most developers, which results in people not checking the issues
  • Options
  • Create some toolings which automatically notify, lets say 5 random people, a day to review issues (But again, this would result in people just create a spam-filter I guess…)
  • Move to another product, which in fact GH issues would be the most fitting solution IMO, since all developers work with that plattform anyway and I can say for myself, that I check the notifications a couple of times a day.
  • Moving to another product than GH issues would maybe lead to the same problem we have with Jira currently, I guess? (Not connected, complicated etc.)

Also, repeating what I wrote in Slack already:

  • I think that Github Issues is good enough (and if only with 3rd party tooling) in the meantime to replace Jira for our purposes
  • Jira’s strength was the better overview for managers - but that doesn’t compensate for the drawbacks you already mentioned
  • Github Issues is just so much closer to where things are happening

As far as I know, there are no ready-to-use migration solutions from Jira to Github because the issues can’t be just translated for every case. But both have a rather easy-to-use REST API, so we could write a migration script which translates issues as we need them, in some reasonable time.

I also gave my opionion on slack, personally favouring Github Issues, as it fits better with my workflow.

However, I also want to add two things to keep in mind with a possible switch:

  • the barrier for people to create issues will be lower instantly and probably increase number of created issues

  • the barrier to use the other communication tools (slack/discuss) will stay the same, hence Github issues are more likely misused for non-issue topics, even further increasing number of created issues

This needs to be dealt with.
The first should optimally solve itself if the switch to Github Issues has the expected push on issue feedback, but we should act quick if it doesn’t. We already have too many open (unhandled) issues.
The latter could be as easy as “close all non-issues immediately and refer to discuss” (might lose probably valuable feedback) or “tag issue as question and only close when answered” (probably splitting community knowledge exchange), but needs to be decided.

No needs to repeats the point mentionned by others, I :thumbsup:to move everything to github, make things more visible, more coherent in term of workflow, and hopefully help us to have more user reporting, and more team members taking care of issues.

1 Like

Hey guys,

like i already said i’d also prefer a move to Github to get everything in one place. Beside everything else what is also said it might be easier for us to deal with new issues as we see them earlier since we all do use Github a lot.

But we have to come up with some guidelines, labels and stuff to get a good workflow how to handle those issues.

I think this one can help, if we have good template, we can avoid incomplete / partial issues

1 Like

Well, I worked with Gerrit a lot and hardly looked at Redmine, same now: mostly GH, rarely JIRA.

So, fine with moving to GH, I guess the removed “split” would help. Not with the amount of tickets or the available manpower, but with awareness. Might improve things already!

Looking at this thread it seems we all are in favour of going to GH, so… how to conclude this? How do we move issues? Do we move issues?

I guess we can go vote. Please leave your :thumbsup: or :thumbsdown: in regards to “Should we move issue tracking to github?” (without further comments) below this (team members only).
Thanks!

1 Like

:thumbsup:

:thumbsup:

:thumbsup:

:thumbsup: but let’s make sure that we have a proper transition and won’t end up with 3 issue trackers :wink:

:thumbsup:

:thumbsup:

:thumbsup: from my side as well

Back when we chose Jira we did discuss Github as well, but it took another year and a half after switching to Jira before we finalized the move to Github. One of the concerns back then was being able to keep an overview of all the different packages, which is no longer a problem with the development collections.

Having issues on Github will make it easier for most people involved, simply because it’s a tool most of us use already so it’s much more visible. The biggest problem with Jira is that it’s separated from our workflow. Simply put Jira simply doesn’t suit our workflow since the majority of people involved are developers and we don’t have any project managers which tend to be necessary for such tools to work well. Also the amount of “other” projects have been very limited, thus it makes sense to focus on the core and go with whatever fits for those “other” projects that aren’t primarily focussed around a code repository.

I only see one thing that Github issues doesn’t provide which we currently use in Jira, which are the Kanban/Scrum boards. Fortunately there are alternatives that work with Github issues to provide that. Again probably make sense to investigate that when there’s an actual need for it, seeing as we hardly use them as is and they seems to be more work organizing than what we benefit from them.

Back when switching to Jira we collected some thoughts that apply to this transition as well https://docs.google.com/document/d/1wxLVFuk6Limk5YkN7fZdb2AcqMWmY1AkR_MylPAqFzw. I’d suggest not to migrate anything unless it’s actively worked on or planned, but keep Jira alive so we can still search for issues there since there’s definitely a lot of valuable information. By not migrating stuff we get a chance to focus on the important stuff, which even just with the pull requests we have challenges keeping up with.

Dropping Jira also means it might make sense dropping Crowd as user database, not a requirement but something to consider.

Thanks @christianm for pushing in this direction.

1 Like

There is https://www.zenhub.com/ which could be used for the kanban/scrum board/project management inclined

+1 for github

Guess the votes are pretty clear by now - so how to proceed? Moving issues from jira is a must I guess, maybe we can adapt what Doctrine has used for their migration:
http://www.doctrine-project.org/2015/12/08/jira-issues-migration.html

Steps would probably look sth like this:

  • test migration script and adjust to make it work for us
  • put jira into read-only mode
  • migrate issues, announce the switch
  • at some later point, put jira down if we feel safe
1 Like