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 or in regards to “Should we move issue tracking to github?” (without further comments) below this (team members only).
Thanks!
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.
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
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!
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