I saw Brett's message, but this is less about what to do with Roundup, and more about how to go about this process, thus I'm leaving Core Mentorship in. That said, Reply-To is set to core-workflow (@Brett - that's not published on mail.python.org, so ....) Please clean up your addressees if you use "reply to all". Aaron Ang writes:

Thank you for your detailed response! I quickly scanned through the PEPs but couldn't find what exactly makes Roundup more powerful than GitHub's issue tracker.

Well, for one thing it's written in Python and *we* can modify it for *our* purposes. Also, that was a while ago and GitHub has added a bunch of features, as somebody already mentioned.

Probably, I am too naive and don't have enough experience,

That's often an advantage in this kind of task. You only want enough experience so that you can convince people that you really can deliver a seamless migration. Too much experience, and you won't be able to convince yourself! ;-)

but I do think that migrating the issue tracker to GitHub will make contributing to Python even easier,

I don't think the issue tracker is likely to be a major hurdle for code and documentation contributors. On the contrary, Python has a lot of process (mostly fairly well automated, but still noticable), and the major bottleneck is reviewer time. So two questions that would need to be answered (probably in PEP format) would be 1. To what extent does Python's custom automation involve the tracker, and is that automation available on or portable to GitHub? 2. What do *reviewers* want from the issue tracker, and can they get equivalent service from GitHub? Will the move impose a learning curve on them? On the other hand, maintenance and improvement of the Roundup tracker has consumed a fair amount of effort and continues to do so. If we can hand off that work to GitHub, that would be a win.

Furthermore, GitHub has many tools to empower the issue tracker, like Probot [2].

Sure, but if we don't need what it does, and it can't do what we need, who cares? ;-) More seriously, that brings up another question: 3. What features (eg, Probot) does GitHub have that can support Python's current automation, and how would they be used? Are there features offering new services that serve our needs even better? I think you can see how this would involve getting into the weeds of current practice and potential GitHub services. Also, you should be aware that python-dev tends to be quite conservative about backward compatibility in our tools, as in our language. Mercurial was the winner in the PEP 374 "VCS derby" in large part because it seemed to involve the least change being imposed on Python developers. You might want to look at the VCS PEPs: 347, 374, 385, and 512, for an idea of how migrations of major components have been done in the past.

In the meanwhile, I will try to look for other opportunities to contribute to the Python community.

I think contributing some code and working with the python-dev process would help you a lot in understanding the project's requirements for its tracker. I was the git advocate in PEP 374, and as you see I eventually won ... 9 years later, and *not* because of *my* arguments, nor because GitHub is Bright! Shiny! New!, but mainly because we could reduce maintenance effort on our tools by moving from a self-hosted Mercurial repository to GitHub. So that's another question: 4. How much effort can we save? How much technical debt (that might involve increasing effort in the future) has accumulated in Roundup? Enough for now. Thank you again for bringing this up! A final word: there's probably not a lot of hurry for this: Roundup is satisfactory and stable. Take your time, don't get burned out. Steve