Mailman 3 March 2018 - core-workflow

IRC vs Slack vs Discord vs Gitter
by INADA Naoki 06 Apr '18

06 Apr '18

Hi, 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. [1] * Gitter -- Most integrated with Github. typing, mypy, pip use it already. [1] https://discordapp.com/open-source 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?) Regards, -- INADA Naoki <songofacandy(a)gmail.com>

15 37

Add a "refactoring" type to the issue tracker?
by Nick Coghlan 06 Apr '18

06 Apr '18

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. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

5 6

[Core-mentorship] Re: Python Bug Tracker vs. GitHub Issue Tracker
by Stephen J. Turnbull 28 Mar '18

28 Mar '18

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

2 1

adding a news entry via the web interface
by Ethan Furman 26 Mar '18

26 Mar '18

Howdy! So I have an issue [1] that looks good but is missing the news entry. Is there any way to add that directly via the web interface? -- ~Ethan~ [1] https://github.com/python/cpython/pull/4288

3 3

core-workflow March 2018