Nowadays, joining to IRC is a hurdle for new contributors.
There are some alternative, modern web applications:
* Slack -- Most used for tech communities.
* Discord -- Similar to slack. It is focusing game, but support OSS too. 
* Gitter -- Most integrated with Github. typing, mypy, pip use it already.
I know adding communication channel is not good always.
(We couldn't keep https://discuss.python.org/)
But I think IRC is really high hurdle for young people.
How about trying one of them? (maybe, gitter?)
INADA Naoki <songofacandy(a)gmail.com>
For https://bugs.python.org/issue32836, I ended up picking "behaviour"
as the issue type (since we're reporting that we're using a symbol
that we don't actually use), but it did prompt the thought: should we
add a "refactoring" type to the issue tracker?
Right now, we tend to mark refactoring changes as "enhancement", but
I'm thinking there would be value in making it clear that we don't
expect end users to notice a particular change, it's just for the
benefit of current and future maintainers.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
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
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
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 .
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
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
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
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.