[dualvariable]

This is the way we did it when we used JIRA.

For GH issues you can always navigate back to the PR discussion (which should have linked issues and other pointers in it) from the commit.

Of course when we switched to GH issues, we largely abandoned JIRA and years later the instance got turned off and deleted. Now all those JIRA tags are entirely useless.

IMO that actually argues for tight coupling between your issue tracker and your git repo. And what you really want is portability (which I don't see how you get other than with tight coupling). Ideally there would be open standardized formats, but as it is, github is the 800# gorilla that defines the format and as long as gitlab and other clones can slurp in github project metadata (or at least PRs) then that effectively gets you closer.

But any way... Fixed, immutable pointers to an Atlassian product that you might not be using in 5 years is not a good policy. I'd sooner accept the policy that the git commits needed to stand entirely on their own and all the information about the "why" of the change needed to be baked into the git commit or the comments in the source (I think that fails, though, since everyone is overly terse in git commits and summarizes issues and loses information--and the back-and-forth dialog in a PR discussion is useful because it contains more than just one person's voice summarizing the reason for the change).

[Izkata]

> Of course when we switched to GH issues, we largely abandoned JIRA and years later the instance got turned off and deleted. Now all those JIRA tags are entirely useless.

We did Bugzilla -> FogBugz -> Jira. Almost all the data was lost every time, no one bothered with migration except for the maintenance project. Worse, even on Jira we lose cases as teams end and hand off the code, and the Jira project is closed so no one else can access it.

We've also done cvs -> svn -> git. All the commits have survived migration.

I do keep including cases in the commits messages, if nothing else it'll help link things together in the future, but never rely on them for context a future maintainer might need.

[codethief]

> Of course when we switched to GH issues, we largely abandoned JIRA and years later the instance got turned off and deleted. Now all those JIRA tags are entirely useless.

I agree that this is a problem but at the same time associating commits with a ticket number is useful, especially if I have dozens of commits on a single ticket and am doing trunk-based development (so not all commits are on the same short-lived branch). Maybe the lesson here is that, once completed, tickets should be exported and stored in the Git repository.

[mystifyingpoi]

> we largely abandoned JIRA and years later the instance got turned off and deleted

Sorry to be nitpicky, but why did you abandon a tool that contained a lot of valuable knowledge? That's not the fault of GH nor JIRA, that's your fault. At least you'd back up descriptions + comments from these JIRA sources.

[dualvariable]

I didn't abandon it, it was run by a different team, and we were one consumer of it. When the organization switched from Jira to GH issues the Jira was kept running for years, but nobody got the information into GH issues. Eventually the Jira was shut down, certainly by the time the company got acquired.

[Macha]

The team that makes the decision to change issue management systems and not to back up the data is rarely the team most affected by that decision.

[oskarpearson]

Like many tools defending their moats, tools like Jira don’t make it easy to get one’s data out.

[ralferoo]

That isn't true though. It's very easy to export your data from JIRA. From your board, go to the List tab, filter the items to whatever you want, and then click ... and you can export the data in various different formats. Exporting as XML dumps everything.

[ralferoo]

You can trivially export your data from JIRA. If the parent experienced a situation where valuable information was lost because the instance was deactivated, that's not JIRA's fault.

[bluGill]

I my case it was a different system that got bought out by (I won't say but your guess is likely correct) and the new license terms were unacceptable