My thoughts are to iust enable the bridge on repos that already voluntarily signaled a nip34 repo annoucement. There should be an easy clear way for them to opt out of the bridge (weird decision, if they already enabled nip34 but ok, won't blame them). After that, we can think of how to do better spam prevention (only mirror "qualityx npubs, etc).
I originally thought projects should have to opt-in to being bridged to github. I'm not keen for gitworkshop.dev or ngit to be bridged to github. perhaps maybe it could be opt-out for projects which list github first in the the 'clone' attribute of their repo event?
Another concern I had was around feature parity. There are some features that aren't built like Reviews, code comments on specific lines, etc and some that aren't possible. What if someone pushes to an existing patch on nostr. The account wont have permission to do the same to the github branch.
You're right, PRs are much more complex to mirror, although I still think it should be possible. If someobe creates a PR on nostr, it could be mirror by a PR created by the bot (which would have permissions to push to its fork). It's hard, but doable. Let's start with Issues only...
@b10c runs a backup script for bitcoin-core and libsec256k1. These are pretty useful to understand the structure of the data and what to expect. core developer Fabian also created a one way bridge to a self-hosted gitlab. se https://delvingbitcoin.org/t/gitlab-backups-for-bitcoin-core-repository/624 I remember finding a python tool that seemed to be quite active - can't seem to find that now. I'm not sure why Fabian didn't use it. Maybe it didn't meet his needs.