Docutils Project Policies

Author: David Goodger; open to all Docutils developers
Date: 2015-02-24
Revision: 7800
Copyright: This document has been placed in the public domain.


The Docutils project group is a meritocracy based on code contribution and lots of discussion [1]. A few quotes sum up the policies of the Docutils project. The IETF's classic credo (by MIT professor Dave Clark) is an ideal we can aspire to:

We reject: kings, presidents, and voting. We believe in: rough consensus and running code.

As architect, chief cook and bottle-washer, David Goodger currently functions as BDFN (Benevolent Dictator For Now). (But he would happily abdicate the throne given a suitable candidate. Any takers?)

Eric S. Raymond, anthropologist of the hacker subculture, writes in his essay The Magic Cauldron:

The number of contributors [to] projects is strongly and inversely correlated with the number of hoops each project makes a user go through to contribute.

We will endeavour to keep the barrier to entry as low as possible. The policies below should not be thought of as barriers, but merely as a codification of experience to date. These are "best practices"; guidelines, not absolutes. Exceptions are expected, tolerated, and used as a source of improvement. Feedback and criticism is welcome.

As for control issues, Emmett Plant (CEO of the Foundation, originators of Ogg Vorbis) put it well when he said:

Open source dictates that you lose a certain amount of control over your codebase, and that's okay with us.
[1]Phrase borrowed from Ben Collins-Sussman of the Subversion project.

How to get a new feature into Docutils

I would very much like to have this new feature in the Docutils core. What exactly do I have to do to make this possible?

How to make code contributions that are easily accepted:

Python Coding Conventions

Contributed code will not be refused merely because it does not strictly adhere to these conditions; as long as it's internally consistent, clean, and correct, it probably will be accepted. But don't be surprised if the "offending" code gets fiddled over time to conform to these conventions.

The Docutils project shall follow the generic coding conventions as specified in the Style Guide for Python Code and Docstring Conventions PEPs, summarized, clarified, and extended as follows:

Documentation Conventions

Copyrights and Licensing

The majority of the Docutils project code and documentation has been placed in the public domain. Unless clearly and explicitly indicated otherwise, any patches (modifications to existing files) submitted to the project for inclusion (via Subversion, SourceForge trackers, mailing lists, or private email) are assumed to be in the public domain as well.

Any new files contributed to the project should clearly state their intentions regarding copyright, in one of the following ways:

2-Clause BSD license

(also known as "Simplified" or FreeBSD license)

If you want a simple, permissive non-copyleft free software license, the FreeBSD license is a reasonable choice. However, please don't call it a “BSD” or “BSD-style” license, because that is likely to cause confusion which could lead to use of the flawed original BSD license.

Various Licenses and Comments about Them

  • clear wording, structured text
  • license used by the closely related Sphinx project
  • "2-Clause BSD license" is a non-ambiguous name, used by both, OSI and GNU.


Please see the repository documentation for details on how to access Docutils' Subversion repository. Anyone can access the repository anonymously. Only project developers can make changes. (If you would like to become a project developer, just ask!) Also see Setting Up For Docutils Development below for some useful info.

Unless you really really know what you're doing, please do not use svn import. It's quite easy to mess up the repository with an import.


(These branch policies go into effect with Docutils 0.4.)

The "docutils" directory of the trunk (a.k.a. the Docutils core) is used for active -- but stable, fully tested, and reviewed -- development.

There will be at least one active maintenance branch at a time, based on at least the latest feature release. For example, when Docutils 0.5 is released, its maintenance branch will take over, and the 0.4.x maintenance branch may be retired. Maintenance branches will receive bug fixes only; no new features will be allowed here.

Obvious and uncontroversial bug fixes with tests can be checked in directly to the core and to the maintenance branches. Don't forget to add test cases! Many (but not all) bug fixes will be applicable both to the core and to the maintenance branches; these should be applied to both. No patches or dedicated branches are required for bug fixes, but they may be used. It is up to the discretion of project developers to decide which mechanism to use for each case.

Feature additions and API changes will be done in feature branches. Feature branches will not be managed in any way. Frequent small checkins are encouraged here. Feature branches must be discussed on the docutils-develop mailing list and reviewed before being merged into the core.

Review Criteria

Before a new feature, an API change, or a complex, disruptive, or controversial bug fix can be checked in to the core or into a maintenance branch, it must undergo review. These are the criteria:

  • The branch must be complete, and include full documentation and tests.
  • There should ideally be one branch merge commit per feature or change. In other words, each branch merge should represent a coherent change set.
  • The code must be stable and uncontroversial. Moving targets and features under debate are not ready to be merged.
  • The code must work. The test suite must complete with no failures. See Docutils Testing.

The review process will ensure that at least one other set of eyeballs & brains sees the code before it enters the core. In addition to the above, the general Check-ins policy (below) also applies.


Changes or additions to the Docutils core and maintenance branches carry a commitment to the Docutils user community. Developers must be prepared to fix and maintain any code they have committed.

The Docutils core (trunk/docutils directory) and maintenance branches should always be kept in a stable state (usable and as problem-free as possible). All changes to the Docutils core or maintenance branches must be in good shape, usable, documented, tested, and reasonably complete.

  • Good shape means that the code is clean, readable, and free of junk code (unused legacy code; by analogy to "junk DNA").
  • Usable means that the code does what it claims to do. An "XYZ Writer" should produce reasonable XYZ output.
  • Documented: The more complete the documentation the better. Modules & files must be at least minimally documented internally. Docutils Front-End Tools should have a new section for any front-end tool that is added. Docutils Configuration Files should be modified with any settings/options defined. For any non-trivial change, the HISTORY.txt file should be updated.
  • Tested means that unit and/or functional tests, that catch all bugs fixed and/or cover all new functionality, have been added to the test suite. These tests must be checked by running the test suite under all supported Python versions, and the entire test suite must pass. See Docutils Testing.
  • Reasonably complete means that the code must handle all input. Here "handle" means that no input can cause the code to fail (cause an exception, or silently and incorrectly produce nothing). "Reasonably complete" does not mean "finished" (no work left to be done). For example, a writer must handle every standard element from the Docutils document model; for unimplemented elements, it must at the very least warn that "Output for element X is not yet implemented in writer Y".

If you really want to check code directly into the Docutils core, you can, but you must ensure that it fulfills the above criteria first. People will start to use it and they will expect it to work! If there are any issues with your code, or if you only have time for gradual development, you should put it on a branch or in the sandbox first. It's easy to move code over to the Docutils core once it's complete.

It is the responsibility and obligation of all developers to keep the Docutils core and maintenance branches stable. If a commit is made to the core or maintenance branch which breaks any test, the solution is simply to revert the change. This is not vindictive; it's practical. We revert first, and discuss later.

Docutils will pursue an open and trusting policy for as long as possible, and deal with any aberrations if (and hopefully not when) they happen. We'd rather see a torrent of loose contributions than just a trickle of perfect-as-they-stand changes. The occasional mistake is easy to fix. That's what version control is for!

Version Numbering

Docutils version numbering uses a major.minor.micro scheme (x.y.z; for example, 0.4.1).

Major releases (x.0, e.g. 1.0) will be rare, and will represent major changes in API, functionality, or commitment. For example, as long as the major version of Docutils is 0, it is to be considered experimental code. When Docutils reaches version 1.0, the major APIs will be considered frozen and backward compatibility will become of paramount importance.

Releases that change the minor number (x.y, e.g. 0.5) will be feature releases; new features from the Docutils core will be included.

Releases that change the micro number (x.y.z, e.g. 0.4.1) will be bug-fix releases. No new features will be introduced in these releases; only bug fixes will be included.

This policy was adopted in October 2005, and will take effect with Docutils version 0.4. Prior to version 0.4, Docutils didn't have an official version numbering policy, and micro releases contained both bug fixes and new features.


Snapshot tarballs can be downloaded from the repository (see the "download snapshot" button in the head of the code listing table).

Setting Up For Docutils Development

When making changes to the code, testing is a must. The code should be run to verify that it produces the expected results, and the entire test suite should be run too. The modified Docutils code has to be accessible to Python for the tests to have any meaning. There are two ways to keep the Docutils code accessible during development:

  1. Update your PYTHONPATH environment variable so that Python picks up your local working copy of the code. This is the recommended method.

    We'll assume that the Docutils trunk is checked out under your ~/projects/ directory as follows:

    svn co https://<user> \

    For the bash shell, add this to your ~/.profile:

    export PYTHONPATH

    The first line points to the directory containing the docutils package. The second line adds the directory containing the third-party modules Docutils depends on. The third line exports this environment variable. You may also wish to add the tools directory to your PATH:

    export PATH
  2. Before you run anything, every time you make a change, reinstall Docutils:

    python install


    This method is not recommended for day-to-day development; it's too easy to forget. Confusion inevitably ensues.

    If you install Docutils this way, Python will always pick up the last-installed copy of the code. If you ever forget to reinstall the "docutils" package, Python won't see your latest changes.

A useful addition to the docutils top-level directory in branches and alternate copies of the code is a set-PATHS file containing the following lines:

# source this file
export PYTHONPATH=$PWD:$PWD/extras
export PATH=$PWD/tools:$PATH

Open a shell for this branch, cd to the docutils top-level directory, and "source" this file. For example, using the bash shell:

$ cd some-branch/docutils
$ . set-PATHS

Mailing Lists

Developers are recommended to subscribe to all Docutils mailing lists.

The Wiki

There is a development wiki at as a scratchpad for transient notes. Please use the repository for permament document storage.