Discussion: Move issues to github?

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:


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

important thing:

How do we deal with security issues? As the issues are always public. Maybe get hidden repo forks for security only?

3 Likes

Isn’t this something we could do on the sprint next year?

Good point… Github doesn’t seem to prioritize this feature request

That’s what symfony does apparently. Another option might be a (free) gitlab repository for those…

Hey guys!

Just a heads up regarding the move to Github. We worked on this during the sprint in Nuremberg and we are almost ready to switch.

We will use a more or less ready to use script to migrate all issues: https://github.com/doctrine/jira-github-issues

All issues will be transfered to Github in the correct repository. Therefore we will use a small mapping array based on components. So the Neos component belongs to the neos-development-collection, Setup to the setup repository and so on.
There will also be an author/user mapping. So usernames will be replaced and correctly linked in github.

###What will be migrated?

  • Title and description
  • Comments
  • Author
  • Correct dates for create date, comment etc.
  • A labe if it is a bug
  • Attachements
  • A URL to the orginal jira issue

Handling

Labels
We will use the labels just the same way we do it right now with PR

Milestones
We will use them and tag the lowest maintained branch. Milestones will stay open until we no longer maintain the branch.

Current state

[X] Check all issues in Jira for both Neos and Flow
[X] Add label readyForGithubMove to all issues that should be migrated
[X] Set components in all issues (we will use components for a mapping)
[X] Build a user mapping array
[X] Prepare migrate script ( https://github.com/johannessteu/neos-jira-github-move )
[X] Enable issues in all our git repositories
[X] Create Milestones
[ ] Validate demo issues
[ ] Create an issue template
[ ] Create an PR template
[ ] Actually move issues to neos organization
[ ] Update readme.md and remove jira badge (Point out how to handle security images!)
[ ] Set jira to read-only
[ ] Announce the change

Demo repositories:

For testing i created all issues on my forks. There are still some user missing as they are not set up in the mapping array the point we created the issues.

The issues are created right now with my user, we will do this later with the neos-bot or neos-project user.

Actual process to migrate

Checkout https://github.com/johannessteu/neos-jira-github-move and run composer install. and create a file .env regarding to the documentation.
Afterwards there are two scripts t use. php export_jira_tickets.php will download all issues from jira and save them in seperate .json files. php import_tickets.php will iterate through all json files and create the issues on github.
Note: make sure to edit the github endpoint in the scripts!

4 Likes

I think a few markup transformations need to be put in place still, see for example: https://github.com/johannessteu/flow-development-collection/issues/1

Fixed the problem using 

instead of

where it was

Fixed the problem using 
<f:if condition="
{issues.first} 
"> 
instead of 
<f:if condition="
{issues}
">

on jira.

Also https://github.com/johannessteu/flow-development-collection/issues/96#issuecomment-243461171
vs
https://jira.neos.io/browse/FLOW-462?focusedCommentId=15664&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15664

EDIT: Guess the first case a special case of bad formatting - I fixed that one in jira directly.

1 Like

Hey guys!

Just pushed all issues! Jira itself is readonly. Team member can still edit issues for now.
So please let’s work on some templates for PR and issues. I created a PR therefore and just copied our existing texts

3 Likes

Has been done, it’s finished, closing.

1 Like