The world has moved to Git. Today there are *far* more developers who are familiar with Git than are familiar with Mercurial. Bitbucket started life as a Mercurial-only service, added Git 3 years later, and last year dropped support for Mercurial entirely. As for Chirp, I would hazard a guess that a significant proportion of the small number of contributors learned Mercurial just so they could contribute to Chirp. I know I did. I would hazard a further guess that many more people are likely to contribute to a Git-based project, and simply aren't willing to learn another source control system just to help out with Chirp. So if you want more help with Chirp, you're much more likely to get it if it's a Git project than if it continues with a dying SCM that people don't want to learn.
I'd be interested in hearing your objections to GitHub. In my experience with a significant number of projects, the pull request mechanism has no equal elsewhere, and makes it easy for a lot of people to contribute, even if they only contribute small changes, and for the project maintainers to apply those changes easily and with excellent tracking. The ability for project maintainers to comment on a pull request, and request additional changes, which can then be made to the same updated pull request, really helps track threads of change. Much better than "please make these changes to your patch and submit another one" via e-mail. GitHub also has great built-in support for Continuous Integration, and with minimal effort, users can see the status of the latest builds and tests at a glance on the repo home page. If there are features that you don't like - you mention the issue tracker - then you don't need to use them. Most of them are optional. The Python project itself is a great example of using GitHub to great effect without buying into the issue tracker, wiki, etc.
That said, Git doesn't have to mean GitHub. As someone else has already mentioned, there are alternatives such as Bitbucket, GitLab, or even self-hosted Git. (This last, though, can take significant work to harden, security-wise - just ask the PHP folks, who have now moved to GitHub after their self-hosted repo was hacked).
But this is not what's happening today. The py3 branch is languishing while development continues on trunk. Very little work is happening on the py3 branch, so it is falling further and further behind. You may not want to stop development for two years to rewrite things, but the py3 branch has already been sitting for two years, almost untouched over that period. Even if the py3 branch is progressed to a working state in its current form, the task of merging in all the changes from trunk is going to be massive. And only then will Chirp be at the point that you can have Py2 & Py3 building out of the same tree.
I really do believe that you're going to get many more people willing to contribute to a Git project than a Mercurial project. You're certainly more likely to find more GUI developers that way. I also believe that a pure Py3 version is likely to gain more traction with contributors than one where people have to futz around with all the Py2/Py3 compatibility cruft in full knowledge that it's all in service of supporting an obsolete version of the language. There is so much good stuff in Py3, and so much that could benefit Chirp, that it really hobbles the project - and the experience of contributors - to require the use of a compatibility layer to support (develop, build, test) both. (On a personal note, I was quite interested in working on the py3 branch until I discovered all of the compatibility cruft, at which point I lost interest entirely.)
Martin.
KD6YAM