270 captures
18 Feb 2018 - 31 Jan 2026
Feb MAR Apr
02
2020 2021 2022
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/20210302015331/https://devguide.python.org/docquality/
 

Navigation



index

next |

previous |


Python »
  Python Developer's Guide »  
|  







6. Helping with Documentation


Python is known for having well-written documentation. Maintaining the documentations accuracy and keeping a high level of quality takes a lot of effort. Community members, like you, help with writing, editing, and updating content, and these contributions are appreciated and welcomed.

This high-level Helping with Documentation section provides:


an overview of Pythons documentation

how to help with documentation issues

information on proofreading

guidance on contributing to this Developers Guide


The next chapter, Documenting Python, gives extensive, detailed information on how to write documentation and submit changes.

6.1. Python Documentation


The Documenting Python section covers the details of how Pythons documentation works. It includes information about the markup language used, specific formats, and style recommendations. Looking at pre-existing documentation source files can be very helpful when getting started. How to build the documentation walks you through the steps to create a draft build which lets you see how your changes will look and validates that your new markup is correct.

You can view the documentation built from in-development and maintenance branches at https://docs.python.org/dev/. The in-development and most recent 3.x (as well as 2.x) maintenance branches are rebuilt once per day.

If you would like to be more involved with documentation, consider subscribing to the docs@python.org mailing list. The issue tracker sends new documentation issues to this mailing list, and, less frequently, the list receives some directly mailed bug reports. The docs-sig@python.org mailing list discusses the documentation toolchain, projects, and standards.


6.2. Helping with documentation issues


If you look at documentation issues on the issue tracker, you will find various documentation problems that may need work. Issues vary from typos to unclear documentation and items lacking documentation.

If you see a documentation issue that you would like to tackle, you can:


check to see if there is a paperclip or octocat icon at the end of the issues title column. If there is, then someone has already created a pull request for the issue.

leave a comment on the issue saying you are going to try and create a pull request and roughly how long you think you will take to do so (this allows others to take on the issue if you happen to forget or lose interest).

submit a pull request for the issue.


By following the steps in the Quick Guide to Pull Requests, you will learn the workflow for documentation pull requests.


6.3. Proofreading


While an issue filed on the issue tracker means there is a known issue somewhere, that does not mean there are not other issues lurking about in the documentation. Proofreading a part of the documentation, such as a How to or OS specific document, can often uncover problems (e.g., documentation that needs updating for Python 3).

If you decide to proofread, read a section of the documentation from start to finish, filing issues in the issue tracker for each major type of problem you find. Simple typos dont require issues of their own, but, instead, submit a pull request directly. Its best to avoid filing a single issue for an entire section containing multiple problems; instead, file several issues so that it is easier to break the work up for multiple people and more efficient review.


6.4. Helping with the Developers Guide


The Developers Guide (what youre reading now) uses the same process as the main Python documentation, except for some small differences. The source lives in a separate repository and bug reports should be submitted to the devguide GitHub tracker.

Our devguide workflow uses continuous integration and deployment so changes to the devguide are normally published when the pull request is merged. Changes to CPython documentation follows the workflow of a CPython release and is published in the release.


6.5. Developers Guide workflow


To submit a pull request, you can fork the devguide repo to your GitHub account and clone it using:

$ git clone https://github.com/<your_username>/devguide



For your PR to be accepted, you will also need to sign the contributor agreement.

To build the devguide, some additional dependencies are required (most importantly, Sphinx), and the standard way to install dependencies in Python projects is to create a virtualenv, and then install dependencies from a requirements.txt file. For your convenience, this is all automated for you. To build the devguide on a Unix-like system use:

$ make html



in the checkout directory. On Windows use:

> .\make html



You will find the generated files in _build/html. Note that make check runs automatically when you submit a pull request. You may wish to run make check and make linkcheck to make sure that it runs without errors.


 




Table of Contents



6. Helping with Documentation

6.1. Python Documentation

6.2. Helping with documentation issues

6.3. Proofreading

6.4. Helping with the Developers Guide

6.5. Developers Guide workflow



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

6.1. Python Documentation

6.2. Helping with documentation issues

6.3. Proofreading

6.4. Helping with the Developers Guide

6.5. Developers Guide workflow



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

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


5. Increase Test Coverage

Next topic


7. Documenting Python

This Page



Show Source  







Navigation



index

next |

previous |


Python »
  Python Developer's Guide »  
|  



© Copyright 2011-2021, Python Software Foundation.  
This page is licensed under the Python Software Foundation License Version 2.  
Examples, recipes, and other code in the documentation are additionally licensed under the Zero Clause BSD License.  
See History and License for more information.  

The Python Software Foundation is a non-profit corporation. Please donate.
 
Last updated on Feb 22, 2021.  Found a bug?
 Created using Sphinx 1.8.5.