I seem to remember this being implemented but overlooked it. Thanks for bringing it up. Ideally, that would be the preferred way to "backup" Github repos. Just replace .wiki with .issues or .pullrequests [insert naming convention here].
It would require remembering the specific repositories for each entity but that's a minor inconvenience if they follow this suggested pattern.
The thought of standardizing the data makes sense when these formats change over time, and I expect they will as features or workflow is added. If I backup my private repo today, I would prefer to have the ability to import it 3 years from now if I so choose and not have to "get lucky" with migrating the data format. It likely wouldn't be hard to figure out if the Github backend APIs are as documented as I believe, but this is a pretty big caveat to using any of these backup approaches.
It would require remembering the specific repositories for each entity but that's a minor inconvenience if they follow this suggested pattern.
The thought of standardizing the data makes sense when these formats change over time, and I expect they will as features or workflow is added. If I backup my private repo today, I would prefer to have the ability to import it 3 years from now if I so choose and not have to "get lucky" with migrating the data format. It likely wouldn't be hard to figure out if the Github backend APIs are as documented as I believe, but this is a pretty big caveat to using any of these backup approaches.