Thanks a lot for doing this!

* The current bug tracker has low contributions and moving to a place like GitHub would open up to a lot of opportunities like integrations, webhooks where people can build custom workflow etc. along with reducing the maintenance burden on the team.

* GitHub also allows markdown and syntax highlighting on code snippets would be much easier to read compared to current tracker. In some cases GitHub can even inline the code for a permalink to a single line which adds more context. Also support for editing comments to fix minor typos links are great. Emoji support :)

* The current bpo search is surprisingly very effective though it just does substring search across comments and patches I believe. If not I can google keywords with site:bugs.python.org to get relevant results. I expect search to be better on GitHub but worth experimenting since searching to get related issues/discussion helps a lot in triaging.

Some points worth considering and some of them are addressed in the PEP already.

* Moving to GitHub also comes at a cost of accessibility where there might be people posting questions that are more suitable for stackoverflow, python-list etc. Thus there might be more incoming issues that would require more effort on triaging.

* There could be explicit guidelines on when a triager should close an issue and current bpo supports custom fields for resolution, state of the issue (open/close/pending/needs-test/patch-review)  that are updated. Besides closing the issue there could be labels or a comment format to describe the rationale and resolution.

* There could also be guidelines on when to lock the thread since there could be cases where security issues or issues that can trigger heated arguments are posted. It could get even more attention when it's posted on Reddit or hackernews attracting unwanted attention e.g. security issues in npm posted to reddit. Someone can chime in to lock it but guidelines on when to do this would be helpful so that decision is not based on personal opinion to lock it.

* Extended discussions in some cases along with no proper support for threading could result in lot of duplicated messages that would be hard to scroll through. It's a problem with current tracker too but something that can come up where people will use +1 comments instead of using thumbs up emoji. Rust community had some similar concerns since they do RFC discussions on GitHub that result in 200+ comments. Though we don't do PEP discussions some bugs can result in this.

* I wish python-bug-list, weekly summary continues to be integrated with GitHub too since some of us don't want to watch the repo to get all the activity along with pull requests and just want to track activity on issues.

* Currently there is some link rot on bpo for svn related links, broken patch file links etc. Moving to GitHub I guess they are handled like magic links for PEPs, bpo-NNNN, etc. that are mentioned in the PEP 581.

Personally, I think more people will love it once they get to use it so if something like 100 issues can be migrated to a sample repo with labels, content etc. As a shameless plug I tried migrating around 150 issues in current bpo to GitLab sometime back with components as labels. Though an apple to oranges comparison (GitLab UI vs GitHub UI) I personally find the UI (also GitHub UI) very easy to navigate in terms of clicking on labels, search, sort, filter etc. in https://gitlab.com/tirkarthi/python-bugs/issues and the issue is more easy to read with markdown support for code where I added highlight to snippet https://gitlab.com/tirkarthi/python-bugs/issues/140