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.