Ciao Hans, unfortunately I don't have any prior experience to share on this topic. However, looking at the options you depicted, I personally prefer the idea of starting from a clean state and then manually re-create the tickets we are really interested to work on discarding the rest as garbage.
It could take longer and requires a bit of effort but I think it could give better results. Cheers Sergio On 2022/10/26 07:42:19 Hans Van Akelyen wrote: > Hi All, > > As discussed in our previous thread we would all like to move to GitHub > Issues. > Now we will have to come up with a plan on how to make this happen… And it > will require a bit of work. > > Unfortunately there is nog magic button that migrates all our issues from > Jira to GH. We will have to create a cut-off point and put our current Jira > project in read-only mode for historical reference. > The good news however is that we are not the first project doing this > migration. If needed and based on our decisions we can ask around with > other projects on how they handled the work. > > I think the 2 major components we have to align on is the WHEN and the WHAT. > > About the when, we *could* migrate at any time depending on what we decide > for the what. Migration during a running release means we will have to > create release notes based on 2 sources, or copy over the already done > tickets to GH to generate a complete release note report. Switching to GH > Issues directly after a release IMHO seems like the best approach. For the > 2.2 release I think our target should be end of November, no one wants to > make a release during the end of year and it would go by unnoticed by the > masses. > > Now the harder part, the what. We can put our Jira in read-only and migrate > nothing! We would start with a clean slate and would have to re-create the > tickets we are working on manually. This means we will not be taking over > our current backlog and all tickets would have to be reported again. The > advantage is we don’t have to do much work. > The second option is using some tools/scripts (will have to ask around with > other projects) to migrate all open issues to GH Issues. I would still > suggest we first do a cleanup of the backlog (we currently have 760 tickets > in backlog). Even after cleaning up we will still have plenty to do… > The final option, we split the work validate each ticket and manually > migrate/update and add more information. > > For the move to GH Issues, you can also take a look at how Apache Beam and > Apache Airflow are handling things, they have templates and bots to help > with initial triage/labeling of the issues. > > As always, feel free to share ideas/experience/comments! > > Cheers, > Hans >
