68 captures
25 Jun 2018 - 08 Jan 2026
Oct NOV Dec
25
2019 2020 2021
success
fail

About this capture

COLLECTED BY

Collection: Common Crawl

Web crawl data from Common Crawl.
TIMESTAMPS

The Wayback Machine - http://web.archive.org/web/20201125082258/https://devguide.python.org/communication/
 

Navigation



index

next |

previous |


Python »
  Python Developer's Guide »  
|  







12. Following Pythons Development


Pythons development is communicated through a myriad of ways, mostly through mailing lists, but also other forms.

12.1. Mailing Lists


python-dev is the primary mailing list for discussions about Pythons development. The list is open to the public and is subscribed to by all core developers plus many people simply interested in following Pythons development. Discussion is focused on issues related to Pythons development, such as how to handle a specific issue, a PEP, etc.


Ideas about new functionality should not start here and instead should be sent to python-ideas.

Technical support questions should also not be asked here and instead should go to python-listorpython-help.


Python-ideas is a mailing list open to the public to discuss ideas on changing Python. If a new idea does not start here (orpython-list, discussed below), it will get redirected here.

Sometimes people post new ideas to python-list to gather community opinion before heading to python-ideas. The list is also sometimes known as comp.lang.python, the name of the newsgroup it mirrors (it is also known by the abbreviation c.l.py).

The python-committers mailing list is a private mailing list for core developers (the archives are publicly available). If something only affects core developers (e.g., the tree is frozen for commits, etc.), it is discussed here instead of python-dev to keep traffic down on the latter.

Python-checkins sends out an email for every commit to Pythons various repositories from https://github.com/python/cpython. All core developers subscribe to this list and are known to reply to these emails to make comments about various issues they catch in the commit. Replies get redirected to python-dev.

There are two mailing lists related to issues on the issue tracker. If you only want an email for when a new issue is open, subscribe to new-bugs-announce. If you would rather receive an email for all changes made to any issue, subscribe to python-bugs-list.

General Python questions should go to python-listortutor or similar resources, such as StackOverflow or the #python IRC channel on Freenode.

Core-Workflow mailing list is the place to discuss and work on improvements to the CPython core development workflow.

A complete list of Python mailing lists can be found at https://mail.python.org. Most lists are also mirrored at GMANE and can be read and posted to in various ways, including via web browsers, NNTP newsreaders, and RSS feed readers.


12.2. Zulip


We have our own zulipchat instance. This should be used to discuss the development of Python only.


12.3. IRC


Some core developers enjoy spending time on IRC discussing various issues regarding Pythons development in the #python-dev channel on irc.freenode.net. This is not a place to ask for help with Python, but to discuss issues related to Pythons own development. You can use Freenodes Web interface if you dont have an IRC client.


12.4. Blogs


Several core developers are active bloggers and discuss Pythons development that way. You can find their blogs (and various other developers who use Python) at http://planetpython.org/.


12.5. Standards of behaviour in these communication channels


We try to foster environments of mutual respect, tolerance and encouragement, as described in the PSFs Diversity Statement. Abiding by the guidelines in this document and asking questions or posting suggestions in the appropriate channels are an excellent way to get started on the mutual respect part, greatly increasing the chances of receiving tolerance and encouragement in return.


12.6. Setting Expectations for Open Source Participation


Burn-out is common in open source due to a misunderstanding of what users, contributors, and maintainers should expect from each other. Brett Cannon gave a talk about this topic that sets out to help everyone set reasonable expectations of each other in order to make open source pleasant for everyone involved.


12.7. Additional Repositories


Python Core Workflow hosts the codebase for tools such as cherry_picker and blurb.

Python Performance Benchmark project is intended to be an authoritative source of benchmarks for all Python implementations.


 




Table of Contents



12. Following Pythons Development

12.1. Mailing Lists

12.2. Zulip

12.3. IRC

12.4. Blogs

12.5. Standards of behaviour in these communication channels

12.6. Setting Expectations for Open Source Participation

12.7. Additional Repositories



Sections



1. Getting Started

2. Where to Get Help

3. Lifecycle of a Pull Request

4. Running & Writing Tests

5. Increase Test Coverage

6. Helping with Documentation

7. Documenting Python

8. Silence Warnings From the Test Suite

9. Fixing easy Issues (and Beyond)

10. Issue Tracking

11. Triaging an Issue

12. Following Pythons Development

12.1. Mailing Lists

12.2. Zulip

12.3. IRC

12.4. Blogs

12.5. Standards of behaviour in these communication channels

12.6. Setting Expectations for Open Source Participation

12.7. Additional Repositories



13. Porting Python to a new platform

14. How to Become a Core Developer

15. Developer Log

16. Accepting Pull Requests

17. Development Cycle

18. Continuous Integration

19. Adding to the Stdlib

20. Changing the Python Language

21. Experts Index

22. gdb Support

23. Exploring CPythons Internals

24. Changing CPythons Grammar

25. Design of CPythons Compiler

26. Design of CPythons Garbage Collector

27. Updating standard library extension modules

28. Coverity Scan

29. Dynamic Analysis with Clang

30. Running a buildbot worker

31. Core Developer Motivations and Affiliations

32. Git Bootcamp and Cheat Sheet

33. Appendix: Topics

Previous topic


11. Triaging an Issue

Next topic


13. Porting Python to a new platform

This Page



Show Source  







Navigation



index

next |

previous |


Python »
  Python Developer's Guide »  
|  



© Copyright 2011-2020, Python Software Foundation.  
The Python Software Foundation is a non-profit corporation. Please donate.
 
Last updated on Nov 10, 2020.  Found a bug?
 Created using Sphinx 1.8.5.