Hello John,
This was discussed before, when we moved from self-hosted svn to GitHub-hosted git, but I'm not sure there are public archives of all discussions.
As far as I remember, the main points to tackle are:
1. Does GitHub allow "anonymous triage" i.e. labelling, closing, and reopening issues by non-committers? I think there was a recent announcement in this area. I didn't check the details. Previously, bot-powered workarounds were suggested, but they wouldn't provide a good user experience. You want discoverable buttons, not a cheat sheet of magic comments.
2. Does the GitHub UI scale to thousands of issues? In theory, any classification system can be reproduced with namespaced labels e.g. "component:ORM", "status:ready-for-checkin", etc. In practice, it's unlikely to be as convenient as what currently exists on Trac.
Perhaps it's just me, but I always found GitHub issues hard to use when I had more than on page of issues. Indeed, at that point, I need a labelling system to filter issues. Then I need to keep all the rules of that system in my head instead of having the UI guide me — and prevent me from infringing the system...
3. How do we migrate issues history from Trac to GitHub? Preserving comment authorship doesn't seem obvious, especially for authors who don't have the same username on Trac and GitHub or authors who don't have a GitHub account.
Initially an effort was made to sync usernames of core devs between Trac and GitHub to prevent security problems but that's a small subset of contributors.
4. Are we still able to export everything from GitHub and move on to the next thing? Perhaps there's an obvious answer. I didn't look. Usually Django takes a pragmatic position: we won't reject GitHub outright because it isn't open source. However, we wouldn't want to lock ourselves into a platform we don't control.
Who would have bet, three years ago, that GitHub would be the property of Microsoft today? What if Microsoft sells it to Oracle in three years? It's nice to keep our options open :-)
We put the code there because we were confident that we could pull the git history. Then everyone started using pull requests, which was likely a good thing, but wasn't really planned or thought through, and I don't think we can export PR comments meaningfully. GitHub did some good vendor lock in there.
and then redirected again by this application:
It would be nice to preserve these links in issues copied from Trac to GitHub, which probably means pre-processing comments to rewrite links.
There may be more, but that's what comes to mind!
Best regards,