> more importantly, all the metadata (for example, issues and pull requests) that was posted on the platform by users, developers and maintainers. Such information is invaluable to a project, and a takedown of the entire repository with all this data can hurt a project very badly.

That's why you regularly need to update your issues with `git bug bridge pull`. Then you have all the issues locally, and are not bound to slick but the unfree website UI. You can edit and add issues locally and push it eventually. Only problem is: corabolation on issues with such a temp. took down GH project relies on everybody interacting with it via git bug. But all the bug refs are pushed upstream, wherever that is.

About lost pull requests: Regular remote branches are the standard workflow, and an issue can carry the description, if the commits are not descriptive enough.

Problems: issues are not numbered, only have hashes. They can be merged out of order, there's no central truth. So references in docs or commits need to use the hash, like bug #4e327af, not just GH #403.