<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Contributing to Django — Django v1.3.1 documentation</title>
<link rel="stylesheet" href="../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '1.3.1',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="top" title="Django v1.3.1 documentation" href="../index.html" />
<link rel="up" title="Django internals" href="index.html" />
<link rel="next" title="How the Django documentation works" href="documentation.html" />
<link rel="prev" title="Django internals" href="index.html" />
<script type="text/javascript" src="../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
if (!django_template_builtins) {
// templatebuiltins.js missing, do nothing.
return;
}
$(document).ready(function() {
// Hyperlink Django template tags and filters
var base = "../ref/templates/builtins.html";
if (base == "#") {
// Special case for builtins.html itself
base = "";
}
// Tags are keywords, class '.k'
$("div.highlight\\-html\\+django span.k").each(function(i, elem) {
var tagname = $(elem).text();
if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
var fragment = tagname.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
}
});
// Filters are functions, class '.nf'
$("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
var filtername = $(elem).text();
if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
var fragment = filtername.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
}
});
});
})(jQuery);
</script>
</head>
<body>
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../index.html">Django v1.3.1 documentation</a></h1>
<div id="global-nav">
<a title="Home page" href="../index.html">Home</a> |
<a title="Table of contents" href="../contents.html">Table of contents</a> |
<a title="Global index" href="../genindex.html">Index</a> |
<a title="Module index" href="../py-modindex.html">Modules</a>
</div>
<div class="nav">
« <a href="index.html" title="Django internals">previous</a>
|
<a href="index.html" title="Django internals" accesskey="U">up</a>
|
<a href="documentation.html" title="How the Django documentation works">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="internals-contributing">
<div class="section" id="s-contributing-to-django">
<span id="contributing-to-django"></span><h1>Contributing to Django<a class="headerlink" href="#contributing-to-django" title="Permalink to this headline">¶</a></h1>
<p>If you think working <em>with</em> Django is fun, wait until you start working <em>on</em>
it. We’re passionate about helping Django users make the jump to contributing
members of the community, so there are many ways you can help Django’s
development:</p>
<ul class="simple">
<li>Blog about Django. We syndicate all the Django blogs we know about on
the <a class="reference external" href="http://www.djangoproject.com/community/">community page</a>; contact <a class="reference external" href="mailto:jacob%40jacobian.org">jacob<span>@</span>jacobian<span>.</span>org</a> if you’ve got a blog
you’d like to see on that page.</li>
<li>Report bugs and request features in our <a class="reference external" href="http://code.djangoproject.com/newticket">ticket tracker</a>. Please read
<a class="reference internal" href="#id1">Reporting bugs</a>, below, for the details on how we like our bug reports
served up.</li>
<li>Submit patches for new and/or fixed behavior. Please read <a class="reference internal" href="#submitting-patches">Submitting
patches</a>, below, for details on how to submit a patch. If you’re looking
for an easy way to start contributing to Django have a look at the
<a class="reference external" href="http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&keywords=~easy-pickings&order=priority">easy-pickings</a> tickets.</li>
<li>Join the <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a> mailing list and share your ideas for how
to improve Django. We’re always open to suggestions, although we’re
likely to be skeptical of large-scale suggestions without some code to
back it up.</li>
<li>Triage patches that have been submitted by other users. Please read
<a class="reference internal" href="#ticket-triage">Ticket triage</a> below, for details on the triage process.</li>
</ul>
<p>That’s all you need to know if you’d like to join the Django development
community. The rest of this document describes the details of how our community
works and how it handles bugs, mailing lists, and all the other minutiae of
Django development.</p>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last">This document contains specific details for contributing to
Django. However, many new contributors find this guide confusing
or intimidating at first. For a simpler introduction
to becoming a contributor please see the <a class="reference internal" href="../howto/contribute.html"><em>How to contribute to Django</em></a> guide.</p>
</div>
<div class="section" id="s-reporting-bugs">
<span id="s-id1"></span><span id="reporting-bugs"></span><span id="id1"></span><h2>Reporting bugs<a class="headerlink" href="#reporting-bugs" title="Permalink to this headline">¶</a></h2>
<p>Well-written bug reports are <em>incredibly</em> helpful. However, there’s a certain
amount of overhead involved in working with any bug tracking system so your
help in keeping our ticket tracker as useful as possible is appreciated. In
particular:</p>
<ul class="simple">
<li><strong>Do</strong> read the <a class="reference internal" href="../faq/index.html"><em>FAQ</em></a> to see if your issue might
be a well-known question.</li>
<li><strong>Do</strong> <a class="reference external" href="http://code.djangoproject.com/search">search the tracker</a> to see if your issue has already been filed.</li>
<li><strong>Do</strong> ask on <a class="reference external" href="http://groups.google.com/group/django-users">django-users</a> <em>first</em> if you’re not sure if what you’re
seeing is a bug.</li>
<li><strong>Do</strong> write complete, reproducible, specific bug reports. Include as
much information as you possibly can, complete with code snippets, test
cases, etc. This means including a clear, concise description of the
problem, and a clear set of instructions for replicating the problem.
A minimal example that illustrates the bug in a nice small test case
is the best possible bug report.</li>
<li><strong>Don’t</strong> use the ticket system to ask support questions. Use the
<a class="reference external" href="http://groups.google.com/group/django-users">django-users</a> list, or the <a class="reference external" href="irc://irc.freenode.net/django">#django</a> IRC channel for that.</li>
<li><strong>Don’t</strong> use the ticket system to make large-scale feature requests.
We like to discuss any big changes to Django’s core on the
<a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a> list before actually working on them.</li>
<li><strong>Don’t</strong> reopen issues that have been marked “wontfix”. This mark
means that the decision has been made that we can’t or won’t fix
this particular issue. If you’re not sure why, please ask
on <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a>.</li>
<li><strong>Don’t</strong> use the ticket tracker for lengthy discussions, because they’re
likely to get lost. If a particular ticket is controversial, please move
discussion to <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a>.</li>
<li><strong>Don’t</strong> post to django-developers just to announce that you have filed
a bug report. All the tickets are mailed to another list
(<a class="reference external" href="http://groups.google.com/group/django-updates">django-updates</a>), which is tracked by developers and interested
community members; we see them as they are filed.</li>
</ul>
</div>
<div class="section" id="s-reporting-security-issues">
<span id="s-id2"></span><span id="reporting-security-issues"></span><span id="id2"></span><h2>Reporting security issues<a class="headerlink" href="#reporting-security-issues" title="Permalink to this headline">¶</a></h2>
<p>Report security issues to <a class="reference external" href="mailto:security%40djangoproject.com">security<span>@</span>djangoproject<span>.</span>com</a>. This is a private list
only open to long-time, highly trusted Django developers, and its archives are
not publicly readable.</p>
<p>In the event of a confirmed vulnerability in Django itself, we will take the
following actions:</p>
<ul class="simple">
<li>Acknowledge to the reporter that we’ve received the report and that a
fix is forthcoming. We’ll give a rough timeline and ask the reporter
to keep the issue confidential until we announce it.</li>
<li>Focus on developing a fix as quickly as possible and produce patches
against the current and two previous releases.</li>
<li>Determine a go-public date for announcing the vulnerability and the fix.
To try to mitigate a possible “arms race” between those applying the
patch and those trying to exploit the hole, we will not announce
security problems immediately.</li>
<li>Pre-notify third-party distributors of Django (“vendors”). We will send
these vendor notifications through private email which will include
documentation of the vulnerability, links to the relevant patch(es), and a
request to keep the vulnerability confidential until the official
go-public date.</li>
<li>Publicly announce the vulnerability and the fix on the pre-determined
go-public date. This will probably mean a new release of Django, but
in some cases it may simply be patches against current releases.</li>
</ul>
</div>
<div class="section" id="s-submitting-patches">
<span id="submitting-patches"></span><h2>Submitting patches<a class="headerlink" href="#submitting-patches" title="Permalink to this headline">¶</a></h2>
<p>We’re always grateful for patches to Django’s code. Indeed, bug reports
with associated patches will get fixed <em>far</em> more quickly than those
without patches.</p>
<div class="section" id="s-claiming-tickets">
<span id="claiming-tickets"></span><h3>“Claiming” tickets<a class="headerlink" href="#claiming-tickets" title="Permalink to this headline">¶</a></h3>
<p>In an open-source project with hundreds of contributors around the world, it’s
important to manage communication efficiently so that work doesn’t get
duplicated and contributors can be as effective as possible. Hence, our policy
is for contributors to “claim” tickets in order to let other developers know
that a particular bug or feature is being worked on.</p>
<p>If you have identified a contribution you want to make and you’re capable of
fixing it (as measured by your coding ability, knowledge of Django internals
and time availability), claim it by following these steps:</p>
<ul class="simple">
<li><a class="reference external" href="http://www.djangoproject.com/accounts/register/">Create an account</a> to use in our ticket system.</li>
<li>If a ticket for this issue doesn’t exist yet, create one in our
<a class="reference external" href="http://code.djangoproject.com/newticket">ticket tracker</a>.</li>
<li>If a ticket for this issue already exists, make sure nobody else has
claimed it. To do this, look at the “Assigned to” section of the ticket.
If it’s assigned to “nobody,” then it’s available to be claimed.
Otherwise, somebody else is working on this ticket, and you either find
another bug/feature to work on, or contact the developer working on the
ticket to offer your help.</li>
<li>Log into your account, if you haven’t already, by clicking “Login” in the
upper right of the ticket page.</li>
<li>Claim the ticket by clicking the radio button next to “Accept ticket”
near the bottom of the page, then clicking “Submit changes.”</li>
</ul>
<p>If you have an account but have forgotten your password, you can reset it
using the <a class="reference external" href="http://www.djangoproject.com/accounts/password/reset/">password reset page</a>.</p>
<div class="section" id="s-ticket-claimers-responsibility">
<span id="ticket-claimers-responsibility"></span><h4>Ticket claimers’ responsibility<a class="headerlink" href="#ticket-claimers-responsibility" title="Permalink to this headline">¶</a></h4>
<p>Once you’ve claimed a ticket, you have a responsibility to work on that ticket
in a reasonably timely fashion. If you don’t have time to work on it, either
unclaim it or don’t claim it in the first place!</p>
<p>If there’s no sign of progress on a particular claimed ticket for a week or
two, another developer may ask you to relinquish the ticket claim so that it’s
no longer monopolized and somebody else can claim it.</p>
<p>If you’ve claimed a ticket and it’s taking a long time (days or weeks) to code,
keep everybody updated by posting comments on the ticket. If you don’t provide
regular updates, and you don’t respond to a request for a progress report,
your claim on the ticket may be revoked. As always, more communication is
better than less communication!</p>
</div>
<div class="section" id="s-which-tickets-should-be-claimed">
<span id="which-tickets-should-be-claimed"></span><h4>Which tickets should be claimed?<a class="headerlink" href="#which-tickets-should-be-claimed" title="Permalink to this headline">¶</a></h4>
<p>Of course, going through the steps of claiming tickets is overkill in some
cases. In the case of small changes, such as typos in the documentation or
small bugs that will only take a few minutes to fix, you don’t need to jump
through the hoops of claiming tickets. Just submit your patch and be done with
it.</p>
</div>
</div>
<div class="section" id="s-patch-style">
<span id="patch-style"></span><h3>Patch style<a class="headerlink" href="#patch-style" title="Permalink to this headline">¶</a></h3>
<ul>
<li><p class="first">Make sure your code matches our <a class="reference internal" href="#coding-style">coding style</a>.</p>
</li>
<li><p class="first">Submit patches in the format returned by the <tt class="docutils literal"><span class="pre">svn</span> <span class="pre">diff</span></tt> command.
An exception is for code changes that are described more clearly in
plain English than in code. Indentation is the most common example; it’s
hard to read patches when the only difference in code is that it’s
indented.</p>
<p>Patches in <tt class="docutils literal"><span class="pre">git</span> <span class="pre">diff</span></tt> format are also acceptable.</p>
</li>
<li><p class="first">When creating patches, always run <tt class="docutils literal"><span class="pre">svn</span> <span class="pre">diff</span></tt> from the top-level
<tt class="docutils literal"><span class="pre">trunk</span></tt> directory – i.e., the one that contains <tt class="docutils literal"><span class="pre">django</span></tt>, <tt class="docutils literal"><span class="pre">docs</span></tt>,
<tt class="docutils literal"><span class="pre">tests</span></tt>, <tt class="docutils literal"><span class="pre">AUTHORS</span></tt>, etc. This makes it easy for other people to
apply your patches.</p>
</li>
<li><p class="first">Attach patches to a ticket in the <a class="reference external" href="http://code.djangoproject.com/newticket">ticket tracker</a>, using the “attach
file” button. Please <em>don’t</em> put the patch in the ticket description
or comment unless it’s a single line patch.</p>
</li>
<li><p class="first">Name the patch file with a <tt class="docutils literal"><span class="pre">.diff</span></tt> extension; this will let the ticket
tracker apply correct syntax highlighting, which is quite helpful.</p>
</li>
<li><p class="first">Check the “Has patch” box on the ticket details. This will make it
obvious that the ticket includes a patch, and it will add the ticket to
the <a class="reference external" href="http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&has_patch=1&order=priority">list of tickets with patches</a>.</p>
</li>
<li><p class="first">The code required to fix a problem or add a feature is an essential part
of a patch, but it is not the only part. A good patch should also include
a regression test to validate the behavior that has been fixed
(and prevent the problem from arising again).</p>
</li>
<li><p class="first">If the code associated with a patch adds a new feature, or modifies
behavior of an existing feature, the patch should also contain
documentation.</p>
</li>
</ul>
</div>
<div class="section" id="s-non-trivial-patches">
<span id="non-trivial-patches"></span><h3>Non-trivial patches<a class="headerlink" href="#non-trivial-patches" title="Permalink to this headline">¶</a></h3>
<p>A “non-trivial” patch is one that is more than a simple bug fix. It’s a patch
that introduces Django functionality and makes some sort of design decision.</p>
<p>If you provide a non-trivial patch, include evidence that alternatives have
been discussed on <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a>. If you’re not sure whether your patch
should be considered non-trivial, just ask.</p>
</div>
</div>
<div class="section" id="s-ticket-triage">
<span id="ticket-triage"></span><h2>Ticket triage<a class="headerlink" href="#ticket-triage" title="Permalink to this headline">¶</a></h2>
<p>Unfortunately, not all bug reports in the <a class="reference external" href="http://code.djangoproject.com/newticket">ticket tracker</a> provide all
the <a class="reference internal" href="#id1">required details</a>. A number of tickets have patches, but those patches
don’t meet all the requirements of a <a class="reference internal" href="#patch-style">good patch</a>.</p>
<p>One way to help out is to <em>triage</em> bugs that have been reported by other
users. The core team–as well as many community members–work on this
regularly, but more help is always appreciated.</p>
<p>Most of the workflow is based around the concept of a ticket’s “triage stage”.
This stage describes where in its lifetime a given ticket is at any time.
Along with a handful of flags, this field easily tells us what and who each
ticket is waiting on.</p>
<p>Since a picture is worth a thousand words, let’s start there:</p>
<img alt="Django's ticket workflow" src="../_images/djangotickets.png" style="width: 590px; height: 451px;" />
<p>We’ve got two roles in this diagram:</p>
<ul class="simple">
<li>Core developers: people with commit access who are responsible for
making the big decisions, writing large portions of the code and
integrating the contributions of the community.</li>
<li>Ticket triagers: anyone in the Django community who chooses to
become involved in Django’s development process. Our Trac installation
is <a class="reference internal" href="../howto/contribute.html#the-spirit-of-contributing"><em>intentionally left open to the public</em></a>, and anyone can triage tickets.
Django is a community project, and we encourage <a class="reference internal" href="#triage-by-the-general-community">triage by the
community</a>.</li>
</ul>
<div class="section" id="s-triage-stages">
<span id="triage-stages"></span><h3>Triage stages<a class="headerlink" href="#triage-stages" title="Permalink to this headline">¶</a></h3>
<p>Second, note the five triage stages:</p>
<ol class="arabic simple">
<li>A ticket starts as <strong>Unreviewed</strong>, meaning that nobody has examined
the ticket.</li>
<li><strong>Design decision needed</strong> means “this concept requires a design
decision,” which should be discussed either in the ticket comments or on
<a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a>. The “Design decision needed” step will generally
only be used for feature requests. It can also be used for issues
that <em>might</em> be bugs, depending on opinion or interpretation. Obvious
bugs (such as crashes, incorrect query results, or non-compliance with a
standard) skip this step and move straight to “Accepted”.</li>
<li>Once a ticket is ruled to be approved for fixing, it’s moved into the
<strong>Accepted</strong> stage. This stage is where all the real work gets done.</li>
<li>In some cases, a ticket might get moved to the <strong>Someday/Maybe</strong> state.
This means the ticket is an enhancement request that we might consider
adding to the framework if an excellent patch is submitted. These
tickets are not a high priority.</li>
<li>If a ticket has an associated patch (see below), it will be reviewed
by the community. If the patch is complete, it’ll be marked as <strong>Ready
for checkin</strong> so that a core developer knows to review and commit the
patch.</li>
</ol>
<p>The second part of this workflow involves a set of flags the describe what the
ticket has or needs in order to be “ready for checkin”:</p>
<dl class="docutils">
<dt>“Has patch”</dt>
<dd>This means the ticket has an associated <a class="reference internal" href="#submitting-patches">patch</a>. These will be
reviewed to see if the patch is “good”.</dd>
<dt>“Needs documentation”</dt>
<dd>This flag is used for tickets with patches that need associated
documentation. Complete documentation of features is a prerequisite
before we can check them into the codebase.</dd>
<dt>“Needs tests”</dt>
<dd>This flags the patch as needing associated unit tests. Again, this is a
required part of a valid patch.</dd>
<dt>“Patch needs improvement”</dt>
<dd>This flag means that although the ticket <em>has</em> a patch, it’s not quite
ready for checkin. This could mean the patch no longer applies
cleanly, there is a flaw in the implementation, or that the code
doesn’t meet our standards.</dd>
</dl>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last">The <a class="reference internal" href="../howto/contribute.html#triage-stages-explained"><em>contributing howto guide</em></a> has a detailed
explanation of each of the triage stages and how the triage process works in
Trac.</p>
</div>
</div>
<div class="section" id="s-ticket-resolutions">
<span id="s-id3"></span><span id="ticket-resolutions"></span><span id="id3"></span><h3>Ticket Resolutions<a class="headerlink" href="#ticket-resolutions" title="Permalink to this headline">¶</a></h3>
<p>A ticket can be resolved in a number of ways:</p>
<dl class="docutils">
<dt>“fixed”</dt>
<dd>Used by the core developers once a patch has been rolled into
Django and the issue is fixed.</dd>
<dt>“invalid”</dt>
<dd>Used if the ticket is found to be incorrect. This means that the
issue in the ticket is actually the result of a user error, or
describes a problem with something other than Django, or isn’t
a bug report or feature request at all (for example, some new users
submit support queries as tickets).</dd>
<dt>“wontfix”</dt>
<dd>Used when a core developer decides that this request is not
appropriate for consideration in Django. This is usually chosen after
discussion in the <tt class="docutils literal"><span class="pre">django-developers</span></tt> mailing list. Feel free to
start or join in discussions of “wontfix” tickets on the mailing list,
but please do not reopen tickets closed as “wontfix” by core
developers.</dd>
<dt>“duplicate”</dt>
<dd>Used when another ticket covers the same issue. By closing duplicate
tickets, we keep all the discussion in one place, which helps everyone.</dd>
<dt>“worksforme”</dt>
<dd>Used when the ticket doesn’t contain enough detail to replicate
the original bug.</dd>
<dt>“needsinfo”</dt>
<dd>Used when the ticket does not contain enough information to replicate
the reported issue but is potentially still valid. The ticket
should be reopened when more information is supplied.</dd>
</dl>
<p>If you believe that the ticket was closed in error – because you’re
still having the issue, or it’s popped up somewhere else, or the triagers have
made a mistake – please reopen the ticket and provide further information.
Please do not reopen tickets that have been marked as “wontfix” by core
developers.</p>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last">For more information on what to do when closing a ticket, please see the
<a class="reference internal" href="../howto/contribute.html#closing-tickets"><em>contributing howto guide</em></a>.</p>
</div>
</div>
<div class="section" id="s-triage-by-the-general-community">
<span id="triage-by-the-general-community"></span><h3>Triage by the general community<a class="headerlink" href="#triage-by-the-general-community" title="Permalink to this headline">¶</a></h3>
<p>Although the core developers make the big decisions in the ticket triage
process, there’s a lot that general community members can do to help the
triage process. In particular, you can help out by:</p>
<ul class="simple">
<li>Closing “Unreviewed” tickets as “invalid”, “worksforme” or “duplicate.”</li>
<li>Promoting “Unreviewed” tickets to “Design decision needed” if a design
decision needs to be made, or “Accepted” in case of obvious bugs.</li>
<li>Correcting the “Needs tests”, “Needs documentation”, or “Has patch”
flags for tickets where they are incorrectly set.</li>
<li>Adding the <a class="reference external" href="http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&keywords=~easy-pickings&order=priority">easy-pickings</a> keyword to tickets that are small and
relatively straightforward.</li>
<li>Checking that old tickets are still valid. If a ticket hasn’t seen
any activity in a long time, it’s possible that the problem has been
fixed but the ticket hasn’t yet been closed.</li>
<li>Contacting the owners of tickets that have been claimed but have not
seen any recent activity. If the owner doesn’t respond after a week
or so, remove the owner’s claim on the ticket.</li>
<li>Identifying trends and themes in the tickets. If there a lot of bug
reports about a particular part of Django, it may indicate we should
consider refactoring that part of the code. If a trend is emerging,
you should raise it for discussion (referencing the relevant tickets)
on <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a>.</li>
</ul>
<p>However, we do ask the following of all general community members working in
the ticket database:</p>
<ul class="simple">
<li>Please <strong>don’t</strong> close tickets as “wontfix.” The core developers will
make the final determination of the fate of a ticket, usually after
consultation with the community.</li>
<li>Please <strong>don’t</strong> promote your own tickets to “Ready for checkin”. You
may mark other people’s tickets which you’ve reviewed as “Ready for
checkin”, but you should get at minimum one other community member to
review a patch that you submit.</li>
<li>Please <strong>don’t</strong> reverse a decision that has been made by a core
developer. If you disagree with a decision that has been made,
please post a message to <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a>.</li>
<li>If you’re unsure if you should be making a change, don’t make the change
but instead leave a comment with your concerns on the ticket, or
post a message to <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a>. It’s okay to be unsure, but
your input is still valuable.</li>
</ul>
</div>
</div>
<div class="section" id="s-submitting-and-maintaining-translations">
<span id="s-contributing-translations"></span><span id="submitting-and-maintaining-translations"></span><span id="contributing-translations"></span><h2>Submitting and maintaining translations<a class="headerlink" href="#submitting-and-maintaining-translations" title="Permalink to this headline">¶</a></h2>
<p>Various parts of Django, such as the admin site and validation error messages,
are internationalized. This means they display different text depending on a
user’s language setting. For this, Django uses the same internationalization
infrastructure available to Django applications described in the
<a class="reference internal" href="../topics/i18n/index.html"><em>i18n documentation</em></a>.</p>
<p>These translations are contributed by Django users worldwide. If you find an
incorrect translation or want to discuss specific translations, go to the
<a class="reference external" href="http://www.transifex.net/projects/p/django/teams/">translation team</a> page for that language. If you would like to help out
with translating or add a language that isn’t yet translated, here’s what
to do:</p>
<ul>
<li><p class="first">Join the <a class="reference external" href="http://groups.google.com/group/django-i18n/">Django i18n mailing list</a> and introduce yourself.</p>
</li>
<li><p class="first">Make sure you read the notes about <a class="reference internal" href="../topics/i18n/index.html#specialties-of-django-i18n"><em>Specialties of Django translation</em></a>.</p>
</li>
<li><p class="first">Signup at <a class="reference external" href="http://www.transifex.net/">Transifex</a> and visit the <a class="reference external" href="http://www.transifex.net/projects/p/django/">Django project page</a>.</p>
</li>
<li><p class="first">On the “<a class="reference external" href="http://www.transifex.net/projects/p/django/teams/">Translation Teams</a>” page, choose the language team you want
to work with, <strong>or</strong> – in case the language team doesn’t exist yet –
request a new team by clicking on the “Request a new team” button
and select the appropriate language.</p>
</li>
<li><p class="first">Then, click the “Join this Team” button to become a member of this team.
Every team has at least one coordinator who is responsible to review
your membership request. You can of course also contact the team
coordinator to clarify procedural problems and handle the actual
translation process.</p>
</li>
<li><p class="first">Once you are a member of a team choose the translation resource you
want update on the team page. For example the “core” resource refers
to the translation catalogue that contains all non-app translations.
Each of the contrib apps also have a resource (prefixed with “contrib-”).</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">For more information about how to use Transifex, see the
<a class="reference external" href="http://help.transifex.net/">Transifex Help</a></p>
</div>
</li>
<li><p class="first">Optionally, review and update the <tt class="docutils literal"><span class="pre">conf/locale/<locale>/formats.py</span></tt>
file to describe the date, time and numbers formatting particularities
of your locale. These files aren’t covered by the use of Transifex and
require a patch against the Django source tree, just as a code change
would:</p>
<ul class="simple">
<li>Create a diff against the current Subversion trunk.</li>
<li>Open a ticket in Django’s ticket system, set its <tt class="docutils literal"><span class="pre">Component</span></tt> field
to <tt class="docutils literal"><span class="pre">Translations</span></tt>, and attach the patch to it. See
<a class="reference internal" href="../topics/i18n/localization.html#format-localization"><em>Format localization</em></a> for details.</li>
</ul>
</li>
</ul>
</div>
<div class="section" id="s-submitting-javascript-patches">
<span id="submitting-javascript-patches"></span><h2>Submitting javascript patches<a class="headerlink" href="#submitting-javascript-patches" title="Permalink to this headline">¶</a></h2>
<div class="versionadded">
<span class="title">New in Django 1.2:</span> <a class="reference internal" href="../releases/1.2.html"><em>Please, see the release notes</em></a></div>
<p>Django’s admin system leverages the jQuery framework to increase the
capabilities of the admin interface. In conjunction, there is an emphasis on
admin javascript performance and minimizing overall admin media file size.
Serving compressed or “minified” versions of javascript files is considered
best practice in this regard.</p>
<p>To that end, patches for javascript files should include both the original
code for future development (e.g. “foo.js”), and a compressed version for
production use (e.g. “foo.min.js”). Any links to the file in the codebase
should point to the compressed version.</p>
<p>To simplify the process of providing optimized javascript code, Django
includes a handy script which should be used to create a “minified” version.
This script is located at <tt class="docutils literal"><span class="pre">/contrib/admin/media/js/compress.py</span></tt>.</p>
<p>Behind the scenes, <tt class="docutils literal"><span class="pre">compress.py</span></tt> is a front-end for Google’s
<a class="reference external" href="http://code.google.com/closure/compiler/">Closure Compiler</a> which is written in Java. However, the Closure Compiler
library is not bundled with Django directly, so those wishing to contribute
complete javascript patches will need to download and install the library
independently.</p>
<p>The Closure Compiler library requires Java version 6 or higher (Java 1.6 or
higher on Mac OS X). Note that Mac OS X 10.5 and earlier did not ship with Java
1.6 by default, so it may be necessary to upgrade your Java installation before
the tool will be functional. Also note that even after upgrading Java, the
default <cite>/usr/bin/java</cite> command may remain linked to the previous Java
binary, so relinking that command may be necessary as well.</p>
<p>Please don’t forget to run <tt class="docutils literal"><span class="pre">compress.py</span></tt> and include the <tt class="docutils literal"><span class="pre">diff</span></tt> of the
minified scripts when submitting patches for Django’s javascript.</p>
</div>
<div class="section" id="s-django-conventions">
<span id="django-conventions"></span><h2>Django conventions<a class="headerlink" href="#django-conventions" title="Permalink to this headline">¶</a></h2>
<p>Various Django-specific code issues are detailed in this section.</p>
<div class="section" id="s-use-of-django-conf-settings">
<span id="use-of-django-conf-settings"></span><h3>Use of <tt class="docutils literal"><span class="pre">django.conf.settings</span></tt><a class="headerlink" href="#use-of-django-conf-settings" title="Permalink to this headline">¶</a></h3>
<p>Modules should not in general use settings stored in <tt class="docutils literal"><span class="pre">django.conf.settings</span></tt>
at the top level (i.e. evaluated when the module is imported). The explanation
for this is as follows:</p>
<p>Manual configuration of settings (i.e. not relying on the
<tt class="docutils literal"><span class="pre">DJANGO_SETTINGS_MODULE</span></tt> environment variable) is allowed and possible as
follows:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.conf</span> <span class="kn">import</span> <span class="n">settings</span>
<span class="n">settings</span><span class="o">.</span><span class="n">configure</span><span class="p">({},</span> <span class="n">SOME_SETTING</span><span class="o">=</span><span class="s">'foo'</span><span class="p">)</span>
</pre></div>
</div>
<p>However, if any setting is accessed before the <tt class="docutils literal"><span class="pre">settings.configure</span></tt> line,
this will not work. (Internally, <tt class="docutils literal"><span class="pre">settings</span></tt> is a <tt class="docutils literal"><span class="pre">LazyObject</span></tt> which
configures itself automatically when the settings are accessed if it has not
already been configured).</p>
<p>So, if there is a module containing some code as follows:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">django.conf</span> <span class="kn">import</span> <span class="n">settings</span>
<span class="kn">from</span> <span class="nn">django.core.urlresolvers</span> <span class="kn">import</span> <span class="n">get_callable</span>
<span class="n">default_foo_view</span> <span class="o">=</span> <span class="n">get_callable</span><span class="p">(</span><span class="n">settings</span><span class="o">.</span><span class="n">FOO_VIEW</span><span class="p">)</span>
</pre></div>
</div>
<p>...then importing this module will cause the settings object to be configured.
That means that the ability for third parties to import the module at the top
level is incompatible with the ability to configure the settings object
manually, or makes it very difficult in some circumstances.</p>
<p>Instead of the above code, a level of laziness or indirection must be used,
such as <cite>django.utils.functional.LazyObject`</cite>, <tt class="docutils literal"><span class="pre">django.utils.functional.lazy</span></tt>
or <tt class="docutils literal"><span class="pre">lambda</span></tt>.</p>
</div>
</div>
<div class="section" id="s-coding-style">
<span id="coding-style"></span><h2>Coding style<a class="headerlink" href="#coding-style" title="Permalink to this headline">¶</a></h2>
<p>Please follow these coding standards when writing code for inclusion in Django:</p>
<ul>
<li><p class="first">Unless otherwise specified, follow <span class="target" id="index-0"></span><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0008"><strong>PEP 8</strong></a>.</p>
<p>You could use a tool like <a class="reference external" href="http://pypi.python.org/pypi/pep8/">pep8.py</a> to check for some problems in this
area, but remember that PEP 8 is only a guide, so respect the style of
the surrounding code as a primary goal.</p>
</li>
<li><p class="first">Use four spaces for indentation.</p>
</li>
<li><p class="first">Use underscores, not camelCase, for variable, function and method names
(i.e. <tt class="docutils literal"><span class="pre">poll.get_unique_voters()</span></tt>, not <tt class="docutils literal"><span class="pre">poll.getUniqueVoters</span></tt>).</p>
</li>
<li><p class="first">Use <tt class="docutils literal"><span class="pre">InitialCaps</span></tt> for class names (or for factory functions that
return classes).</p>
</li>
<li><p class="first">Mark all strings for internationalization; see the <a class="reference internal" href="../topics/i18n/index.html"><em>i18n
documentation</em></a> for details.</p>
</li>
<li><p class="first">In docstrings, use "action words" such as:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">def</span> <span class="nf">foo</span><span class="p">():</span>
<span class="sd">"""</span>
<span class="sd"> Calculates something and returns the result.</span>
<span class="sd"> """</span>
<span class="k">pass</span>
</pre></div>
</div>
<p>Here's an example of what not to do:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">def</span> <span class="nf">foo</span><span class="p">():</span>
<span class="sd">"""</span>
<span class="sd"> Calculate something and return the result.</span>
<span class="sd"> """</span>
<span class="k">pass</span>
</pre></div>
</div>
</li>
<li><p class="first">Please don't put your name in the code you contribute. Our policy is to
keep contributors' names in the <tt class="docutils literal"><span class="pre">AUTHORS</span></tt> file distributed with Django
-- not scattered throughout the codebase itself. Feel free to include a
change to the <tt class="docutils literal"><span class="pre">AUTHORS</span></tt> file in your patch if you make more than a
single trivial change.</p>
</li>
</ul>
<div class="section" id="s-template-style">
<span id="template-style"></span><h3>Template style<a class="headerlink" href="#template-style" title="Permalink to this headline">¶</a></h3>
<ul>
<li><p class="first">In Django template code, put one (and only one) space between the curly
brackets and the tag contents.</p>
<p>Do this:</p>
<div class="highlight-html+django"><div class="highlight"><pre><span class="cp">{{</span> <span class="nv">foo</span> <span class="cp">}}</span>
</pre></div>
</div>
<p>Don't do this:</p>
<div class="highlight-html+django"><div class="highlight"><pre><span class="cp">{{</span><span class="nv">foo</span><span class="cp">}}</span>
</pre></div>
</div>
</li>
</ul>
</div>
<div class="section" id="s-view-style">
<span id="view-style"></span><h3>View style<a class="headerlink" href="#view-style" title="Permalink to this headline">¶</a></h3>
<ul>
<li><p class="first">In Django views, the first parameter in a view function should be called
<tt class="docutils literal"><span class="pre">request</span></tt>.</p>
<p>Do this:</p>
<div class="highlight-python"><pre>def my_view(request, foo):
# ...</pre>
</div>
<p>Don't do this:</p>
<div class="highlight-python"><pre>def my_view(req, foo):
# ...</pre>
</div>
</li>
</ul>
</div>
<div class="section" id="s-model-style">
<span id="model-style"></span><h3>Model style<a class="headerlink" href="#model-style" title="Permalink to this headline">¶</a></h3>
<ul>
<li><p class="first">Field names should be all lowercase, using underscores instead of
camelCase.</p>
<p>Do this:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Person</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="n">first_name</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">20</span><span class="p">)</span>
<span class="n">last_name</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">40</span><span class="p">)</span>
</pre></div>
</div>
<p>Don't do this:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Person</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="n">FirstName</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">20</span><span class="p">)</span>
<span class="n">Last_Name</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">40</span><span class="p">)</span>
</pre></div>
</div>
</li>
<li><p class="first">The <tt class="docutils literal"><span class="pre">class</span> <span class="pre">Meta</span></tt> should appear <em>after</em> the fields are defined, with
a single blank line separating the fields and the class definition.</p>
<p>Do this:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Person</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="n">first_name</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">20</span><span class="p">)</span>
<span class="n">last_name</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">40</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="n">verbose_name_plural</span> <span class="o">=</span> <span class="s">'people'</span>
</pre></div>
</div>
<p>Don't do this:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Person</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="n">first_name</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">20</span><span class="p">)</span>
<span class="n">last_name</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">40</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="n">verbose_name_plural</span> <span class="o">=</span> <span class="s">'people'</span>
</pre></div>
</div>
<p>Don't do this, either:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="k">class</span> <span class="nc">Person</span><span class="p">(</span><span class="n">models</span><span class="o">.</span><span class="n">Model</span><span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="n">verbose_name_plural</span> <span class="o">=</span> <span class="s">'people'</span>
<span class="n">first_name</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">20</span><span class="p">)</span>
<span class="n">last_name</span> <span class="o">=</span> <span class="n">models</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">40</span><span class="p">)</span>
</pre></div>
</div>
</li>
<li><p class="first">The order of model inner classes and standard methods should be as
follows (noting that these are not all required):</p>
<ul class="simple">
<li>All database fields</li>
<li>Custom manager attributes</li>
<li><tt class="docutils literal"><span class="pre">class</span> <span class="pre">Meta</span></tt></li>
<li><tt class="docutils literal"><span class="pre">def</span> <span class="pre">__unicode__()</span></tt></li>
<li><tt class="docutils literal"><span class="pre">def</span> <span class="pre">__str__()</span></tt></li>
<li><tt class="docutils literal"><span class="pre">def</span> <span class="pre">save()</span></tt></li>
<li><tt class="docutils literal"><span class="pre">def</span> <span class="pre">get_absolute_url()</span></tt></li>
<li>Any custom methods</li>
</ul>
</li>
<li><p class="first">If <tt class="docutils literal"><span class="pre">choices</span></tt> is defined for a given model field, define the choices as
a tuple of tuples, with an all-uppercase name, either near the top of the
model module or just above the model class. Example:</p>
<div class="highlight-python"><div class="highlight"><pre><span class="n">GENDER_CHOICES</span> <span class="o">=</span> <span class="p">(</span>
<span class="p">(</span><span class="s">'M'</span><span class="p">,</span> <span class="s">'Male'</span><span class="p">),</span>
<span class="p">(</span><span class="s">'F'</span><span class="p">,</span> <span class="s">'Female'</span><span class="p">),</span>
<span class="p">)</span>
</pre></div>
</div>
</li>
</ul>
</div>
</div>
<div class="section" id="s-documentation-style">
<span id="documentation-style"></span><h2>Documentation style<a class="headerlink" href="#documentation-style" title="Permalink to this headline">¶</a></h2>
<p>We place a high importance on consistency and readability of documentation.
(After all, Django was created in a journalism environment!)</p>
<div class="section" id="s-how-to-document-new-features">
<span id="how-to-document-new-features"></span><h3>How to document new features<a class="headerlink" href="#how-to-document-new-features" title="Permalink to this headline">¶</a></h3>
<p>We treat our documentation like we treat our code: we aim to improve it as
often as possible. This section explains how writers can craft their
documentation changes in the most useful and least error-prone ways.</p>
<p>Documentation changes come in two forms:</p>
<ul class="simple">
<li>General improvements -- Typo corrections, error fixes and better
explanations through clearer writing and more examples.</li>
<li>New features -- Documentation of features that have been added to the
framework since the last release.</li>
</ul>
<p>Our policy is:</p>
<blockquote>
<div><strong>All documentation of new features should be written in a way that clearly
designates the features are only available in the Django development
version. Assume documentation readers are using the latest release, not the
development version.</strong></div></blockquote>
<p>Our preferred way for marking new features is by prefacing the features'
documentation with: ".. versionadded:: X.Y", followed by an optional one line
comment and a mandatory blank line.</p>
<p>General improvements, or other changes to the APIs that should be emphasized
should use the ".. versionchanged:: X.Y" directive (with the same format as the
<tt class="docutils literal"><span class="pre">versionadded</span></tt> mentioned above.</p>
<p>There's a full page of information about the <a class="reference internal" href="documentation.html"><em>Django documentation
system</em></a> that you should read prior to working on the
documentation.</p>
</div>
<div class="section" id="s-guidelines-for-rest-files">
<span id="guidelines-for-rest-files"></span><h3>Guidelines for reST files<a class="headerlink" href="#guidelines-for-rest-files" title="Permalink to this headline">¶</a></h3>
<p>These guidelines regulate the format of our reST documentation:</p>
<ul class="simple">
<li>In section titles, capitalize only initial words and proper nouns.</li>
<li>Wrap the documentation at 80 characters wide, unless a code example
is significantly less readable when split over two lines, or for another
good reason.</li>
</ul>
</div>
<div class="section" id="s-commonly-used-terms">
<span id="commonly-used-terms"></span><h3>Commonly used terms<a class="headerlink" href="#commonly-used-terms" title="Permalink to this headline">¶</a></h3>
<p>Here are some style guidelines on commonly used terms throughout the
documentation:</p>
<ul class="simple">
<li><strong>Django</strong> -- when referring to the framework, capitalize Django. It is
lowercase only in Python code and in the djangoproject.com logo.</li>
<li><strong>e-mail</strong> -- it has a hyphen.</li>
<li><strong>MySQL</strong></li>
<li><strong>PostgreSQL</strong></li>
<li><strong>Python</strong> -- when referring to the language, capitalize Python.</li>
<li><strong>realize</strong>, <strong>customize</strong>, <strong>initialize</strong>, etc. -- use the American
"ize" suffix, not "ise."</li>
<li><strong>SQLite</strong></li>
<li><strong>subclass</strong> -- it's a single word without a hyphen, both as a verb
("subclass that model") and as a noun ("create a subclass").</li>
<li><strong>Web</strong>, <strong>World Wide Web</strong>, <strong>the Web</strong> -- note Web is always
capitalized when referring to the World Wide Web.</li>
<li><strong>Web site</strong> -- use two words, with Web capitalized.</li>
</ul>
</div>
<div class="section" id="s-django-specific-terminology">
<span id="django-specific-terminology"></span><h3>Django-specific terminology<a class="headerlink" href="#django-specific-terminology" title="Permalink to this headline">¶</a></h3>
<ul class="simple">
<li><strong>model</strong> -- it's not capitalized.</li>
<li><strong>template</strong> -- it's not capitalized.</li>
<li><strong>URLconf</strong> -- use three capitalized letters, with no space before
"conf."</li>
<li><strong>view</strong> -- it's not capitalized.</li>
</ul>
</div>
</div>
<div class="section" id="s-committing-code">
<span id="committing-code"></span><h2>Committing code<a class="headerlink" href="#committing-code" title="Permalink to this headline">¶</a></h2>
<p>Please follow these guidelines when committing code to Django's Subversion
repository:</p>
<ul>
<li><p class="first">For any medium-to-big changes, where "medium-to-big" is according to your
judgment, please bring things up on the <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a> mailing list
before making the change.</p>
<p>If you bring something up on <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a> and nobody responds,
please don't take that to mean your idea is great and should be
implemented immediately because nobody contested it. Django's lead
developers don't have a lot of time to read mailing-list discussions
immediately, so you may have to wait a couple of days before getting a
response.</p>
</li>
<li><p class="first">Write detailed commit messages in the past tense, not present tense.</p>
<ul class="simple">
<li>Good: "Fixed Unicode bug in RSS API."</li>
<li>Bad: "Fixes Unicode bug in RSS API."</li>
<li>Bad: "Fixing Unicode bug in RSS API."</li>
</ul>
</li>
<li><p class="first">For commits to a branch, prefix the commit message with the branch name.
For example: "magic-removal: Added support for mind reading."</p>
</li>
<li><p class="first">Limit commits to the most granular change that makes sense. This means,
use frequent small commits rather than infrequent large commits. For
example, if implementing feature X requires a small change to library Y,
first commit the change to library Y, then commit feature X in a separate
commit. This goes a <em>long way</em> in helping all core Django developers
follow your changes.</p>
</li>
<li><p class="first">Separate bug fixes from feature changes.</p>
<p>Bug fixes need to be added to the current bugfix branch (e.g. the
<tt class="docutils literal"><span class="pre">1.0.X</span></tt> branch) as well as the current trunk.</p>
</li>
<li><p class="first">If your commit closes a ticket in the Django <a class="reference external" href="http://code.djangoproject.com/newticket">ticket tracker</a>, begin
your commit message with the text "Fixed #abc", where "abc" is the number
of the ticket your commit fixes. Example: "Fixed #123 -- Added support
for foo". We've rigged Subversion and Trac so that any commit message
in that format will automatically close the referenced ticket and post a
comment to it with the full commit message.</p>
<p>If your commit closes a ticket and is in a branch, use the branch name
first, then the "Fixed #abc." For example:
"magic-removal: Fixed #123 -- Added whizbang feature."</p>
<p>For the curious: We're using a <a class="reference external" href="http://trac.edgewall.org/browser/trunk/contrib/trac-post-commit-hook">Trac post-commit hook</a> for this.</p>
</li>
<li><p class="first">If your commit references a ticket in the Django <a class="reference external" href="http://code.djangoproject.com/newticket">ticket tracker</a> but
does <em>not</em> close the ticket, include the phrase "Refs #abc", where "abc"
is the number of the ticket your commit references. We've rigged
Subversion and Trac so that any commit message in that format will
automatically post a comment to the appropriate ticket.</p>
</li>
</ul>
<div class="section" id="s-reverting-commits">
<span id="reverting-commits"></span><h3>Reverting commits<a class="headerlink" href="#reverting-commits" title="Permalink to this headline">¶</a></h3>
<p>Nobody's perfect; mistakes will be committed. When a mistaken commit is
discovered, please follow these guidelines:</p>
<ul class="simple">
<li>Try very hard to ensure that mistakes don't happen. Just because we
have a reversion policy doesn't relax your responsibility to aim for
the highest quality possible. Really: double-check your work before
you commit it in the first place!</li>
<li>If possible, have the original author revert his/her own commit.</li>
<li>Don't revert another author's changes without permission from the
original author.</li>
<li>If the original author can't be reached (within a reasonable amount
of time -- a day or so) and the problem is severe -- crashing bug,
major test failures, etc -- then ask for objections on django-dev
then revert if there are none.</li>
<li>If the problem is small (a feature commit after feature freeze,
say), wait it out.</li>
<li>If there's a disagreement between the committer and the
reverter-to-be then try to work it out on the <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a>
mailing list. If an agreement can't be reached then it should
be put to a vote.</li>
<li>If the commit introduced a confirmed, disclosed security
vulnerability then the commit may be reverted immediately without
permission from anyone.</li>
<li>The release branch maintainer may back out commits to the release
branch without permission if the commit breaks the release branch.</li>
</ul>
</div>
</div>
<div class="section" id="s-unit-tests">
<span id="s-id4"></span><span id="unit-tests"></span><span id="id4"></span><h2>Unit tests<a class="headerlink" href="#unit-tests" title="Permalink to this headline">¶</a></h2>
<p>Django comes with a test suite of its own, in the <tt class="docutils literal"><span class="pre">tests</span></tt> directory of the
Django tarball. It's our policy to make sure all tests pass at all times.</p>
<p>The tests cover:</p>
<ul class="simple">
<li>Models and the database API (<tt class="docutils literal"><span class="pre">tests/modeltests/</span></tt>).</li>
<li>Everything else in core Django code (<tt class="docutils literal"><span class="pre">tests/regressiontests</span></tt>)</li>
<li>Contrib apps (<tt class="docutils literal"><span class="pre">django/contrib/<contribapp>/tests</span></tt>, see below)</li>
</ul>
<p>We appreciate any and all contributions to the test suite!</p>
<p>The Django tests all use the testing infrastructure that ships with Django for
testing applications. See <a class="reference internal" href="../topics/testing.html"><em>Testing Django applications</em></a>
for an explanation of how to write new tests.</p>
<div class="section" id="s-running-the-unit-tests">
<span id="s-running-unit-tests"></span><span id="running-the-unit-tests"></span><span id="running-unit-tests"></span><h3>Running the unit tests<a class="headerlink" href="#running-the-unit-tests" title="Permalink to this headline">¶</a></h3>
<div class="section" id="s-quickstart">
<span id="quickstart"></span><h4>Quickstart<a class="headerlink" href="#quickstart" title="Permalink to this headline">¶</a></h4>
<p>Running the tests requires a Django settings module that defines the
databases to use. To make it easy to get started. Django provides a
sample settings module that uses the SQLite database. To run the tests
with this sample <tt class="docutils literal"><span class="pre">settings</span></tt> module, <tt class="docutils literal"><span class="pre">cd</span></tt> into the Django
<tt class="docutils literal"><span class="pre">tests/</span></tt> directory and run:</p>
<div class="highlight-bash"><div class="highlight"><pre>./runtests.py --settings<span class="o">=</span>test_sqlite
</pre></div>
</div>
<p>If you get an <tt class="docutils literal"><span class="pre">ImportError:</span> <span class="pre">No</span> <span class="pre">module</span> <span class="pre">named</span> <span class="pre">django.contrib</span></tt> error,
you need to add your install of Django to your <tt class="docutils literal"><span class="pre">PYTHONPATH</span></tt>. For
more details on how to do this, read <a class="reference internal" href="#pointing-python-at-the-new-django-version">Pointing Python at the new
Django version</a> below.</p>
</div>
<div class="section" id="s-using-another-settings-module">
<span id="using-another-settings-module"></span><h4>Using another <tt class="docutils literal"><span class="pre">settings</span></tt> module<a class="headerlink" href="#using-another-settings-module" title="Permalink to this headline">¶</a></h4>
<p>The included settings module allows you to run the test suite using
SQLite. If you want to test behavior using a different database (and
if you're proposing patches for Django, it's a good idea to test
across databases), you may need to define your own settings file.</p>
<p>To run the tests with different settings, <tt class="docutils literal"><span class="pre">cd</span></tt> to the <tt class="docutils literal"><span class="pre">tests/</span></tt> directory
and type:</p>
<div class="highlight-bash"><div class="highlight"><pre>./runtests.py --settings<span class="o">=</span>path.to.django.settings
</pre></div>
</div>
<p>The <a class="reference internal" href="../ref/settings.html#std:setting-DATABASES"><tt class="xref std std-setting docutils literal"><span class="pre">DATABASES</span></tt></a> setting in this test settings module needs to define
two databases:</p>
<ul class="simple">
<li>A <tt class="docutils literal"><span class="pre">default</span></tt> database. This database should use the backend that
you want to use for primary testing</li>
<li>A database with the alias <tt class="docutils literal"><span class="pre">other</span></tt>. The <tt class="docutils literal"><span class="pre">other</span></tt> database is
used to establish that queries can be directed to different
databases. As a result, this database can use any backend you
want. It doesn't need to use the same backend as the <tt class="docutils literal"><span class="pre">default</span></tt>
database (although it can use the same backend if you want to).</li>
</ul>
<p>If you're using a backend that isn't SQLite, you will need to provide other
details for each database:</p>
<ul class="simple">
<li>The <a class="reference internal" href="../ref/settings.html#std:setting-USER"><tt class="xref std std-setting docutils literal"><span class="pre">USER</span></tt></a> option for each of your databases needs to
specify an existing user account for the database.</li>
<li>The <a class="reference internal" href="../ref/settings.html#std:setting-PASSWORD"><tt class="xref std std-setting docutils literal"><span class="pre">PASSWORD</span></tt></a> option needs to provide the password for
the <a class="reference internal" href="../ref/settings.html#std:setting-USER"><tt class="xref std std-setting docutils literal"><span class="pre">USER</span></tt></a> that has been specified.</li>
<li>The <a class="reference internal" href="../ref/settings.html#std:setting-NAME"><tt class="xref std std-setting docutils literal"><span class="pre">NAME</span></tt></a> option must be the name of an existing database to
which the given user has permission to connect. The unit tests will not
touch this database; the test runner creates a new database whose name is
<a class="reference internal" href="../ref/settings.html#std:setting-NAME"><tt class="xref std std-setting docutils literal"><span class="pre">NAME</span></tt></a> prefixed with <tt class="docutils literal"><span class="pre">test_</span></tt>, and this test database is
deleted when the tests are finished. This means your user account needs
permission to execute <tt class="docutils literal"><span class="pre">CREATE</span> <span class="pre">DATABASE</span></tt>.</li>
</ul>
<p>You will also need to ensure that your database uses UTF-8 as the default
character set. If your database server doesn't use UTF-8 as a default charset,
you will need to include a value for <tt class="docutils literal"><span class="pre">TEST_CHARSET</span></tt> in the settings
dictionary for the applicable database.</p>
</div>
<div class="section" id="s-running-only-some-of-the-tests">
<span id="running-only-some-of-the-tests"></span><h4>Running only some of the tests<a class="headerlink" href="#running-only-some-of-the-tests" title="Permalink to this headline">¶</a></h4>
<p>Django's entire test suite takes a while to run, and running every single test
could be redundant if, say, you just added a test to Django that you want to
run quickly without running everything else. You can run a subset of the unit
tests by appending the names of the test modules to <tt class="docutils literal"><span class="pre">runtests.py</span></tt> on the
command line.</p>
<p>For example, if you'd like to run tests only for generic relations and
internationalization, type:</p>
<div class="highlight-bash"><div class="highlight"><pre>./runtests.py --settings<span class="o">=</span>path.to.settings generic_relations i18n
</pre></div>
</div>
<p>How do you find out the names of individual tests? Look in <tt class="docutils literal"><span class="pre">tests/modeltests</span></tt>
and <tt class="docutils literal"><span class="pre">tests/regressiontests</span></tt> -- each directory name there is the name of a
test.</p>
<p>If you just want to run a particular class of tests, you can specify a list of
paths to individual test classes. For example, to run the <tt class="docutils literal"><span class="pre">TranslationTests</span></tt>
of the <tt class="docutils literal"><span class="pre">i18n</span></tt> module, type:</p>
<div class="highlight-bash"><div class="highlight"><pre>./runtests.py --settings<span class="o">=</span>path.to.settings i18n.TranslationTests
</pre></div>
</div>
<p>Going beyond that, you can specify an individual test method like this:</p>
<div class="highlight-bash"><div class="highlight"><pre>./runtests.py --settings<span class="o">=</span>path.to.settings i18n.TranslationTests.test_lazy_objects
</pre></div>
</div>
</div>
<div class="section" id="s-running-all-the-tests">
<span id="running-all-the-tests"></span><h4>Running all the tests<a class="headerlink" href="#running-all-the-tests" title="Permalink to this headline">¶</a></h4>
<p>If you want to run the full suite of tests, you'll need to install a number of
dependencies:</p>
<ul class="simple">
<li><a class="reference external" href="http://pyyaml.org/wiki/PyYAML">PyYAML</a></li>
<li><a class="reference external" href="http://pypi.python.org/pypi/Markdown/1.7">Markdown</a></li>
<li><a class="reference external" href="http://pypi.python.org/pypi/textile">Textile</a></li>
<li><a class="reference external" href="http://pypi.python.org/pypi/docutils/0.4">Docutils</a></li>
<li><a class="reference external" href="http://pypi.python.org/pypi/setuptools/">setuptools</a></li>
<li><a class="reference external" href="http://www.danga.com/memcached/">memcached</a>, plus a <a class="reference internal" href="../topics/cache.html#memcached"><em>supported Python binding</em></a></li>
<li><a class="reference external" href="http://www.gnu.org/software/gettext/manual/gettext.html">gettext</a> (<a class="reference internal" href="../topics/i18n/localization.html#gettext-on-windows"><em>gettext on Windows</em></a>)</li>
</ul>
<p>If you want to test the memcached cache backend, you'll also need to define
a <a class="reference internal" href="../ref/settings.html#std:setting-CACHES"><tt class="xref std std-setting docutils literal"><span class="pre">CACHES</span></tt></a> setting that points at your memcached instance.</p>
<p>Each of these dependencies is optional. If you're missing any of them, the
associated tests will be skipped.</p>
</div>
</div>
<div class="section" id="s-contrib-apps">
<span id="contrib-apps"></span><h3>Contrib apps<a class="headerlink" href="#contrib-apps" title="Permalink to this headline">¶</a></h3>
<p>Tests for apps in <tt class="docutils literal"><span class="pre">django/contrib/</span></tt> go in their respective directories under
<tt class="docutils literal"><span class="pre">django/contrib/</span></tt>, in a <tt class="docutils literal"><span class="pre">tests.py</span></tt> file. (You can split the tests over
multiple modules by using a <tt class="docutils literal"><span class="pre">tests</span></tt> directory in the normal Python way.)</p>
<p>For the tests to be found, a <tt class="docutils literal"><span class="pre">models.py</span></tt> file must exist (it doesn't
have to have anything in it). If you have URLs that need to be
mapped, put them in <tt class="docutils literal"><span class="pre">tests/urls.py</span></tt>.</p>
<p>To run tests for just one contrib app (e.g. <tt class="docutils literal"><span class="pre">markup</span></tt>), use the same
method as above:</p>
<div class="highlight-python"><pre>./runtests.py --settings=settings markup</pre>
</div>
</div>
</div>
<div class="section" id="s-requesting-features">
<span id="requesting-features"></span><h2>Requesting features<a class="headerlink" href="#requesting-features" title="Permalink to this headline">¶</a></h2>
<p>We're always trying to make Django better, and your feature requests are a key
part of that. Here are some tips on how to make a request most effectively:</p>
<ul class="simple">
<li>Request the feature on <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a>, not in the ticket tracker.
It'll get read more closely if it's on the mailing list.</li>
<li>Describe clearly and concisely what the missing feature is and how you'd
like to see it implemented. Include example code (non-functional is OK)
if possible.</li>
<li>Explain <em>why</em> you'd like the feature. In some cases this is obvious, but
since Django is designed to help real developers get real work done,
you'll need to explain it, if it isn't obvious why the feature would be
useful.</li>
</ul>
<p>As with most open-source projects, code talks. If you are willing to write the
code for the feature yourself or if (even better) you've already written it,
it's much more likely to be accepted. If it's a large feature that might need
multiple developers, we're always happy to give you an experimental branch in
our repository; see below.</p>
</div>
<div class="section" id="s-branch-policy">
<span id="branch-policy"></span><h2>Branch policy<a class="headerlink" href="#branch-policy" title="Permalink to this headline">¶</a></h2>
<p>In general, the trunk must be kept stable. People should be able to run
production sites against the trunk at any time. Additionally, commits to trunk
ought to be as atomic as possible -- smaller changes are better. Thus, large
feature changes -- that is, changes too large to be encapsulated in a single
patch, or changes that need multiple eyes on them -- must happen on dedicated
branches.</p>
<p>This means that if you want to work on a large feature -- anything that would
take more than a single patch, or requires large-scale refactoring -- you need
to do it on a feature branch. Our development process recognizes two options
for feature branches:</p>
<ol class="arabic">
<li><p class="first">Feature branches using a distributed revision control system like
<a class="reference external" href="http://git-scm.com/">Git</a>, <a class="reference external" href="http://mercurial.selenic.com/">Mercurial</a>, <a class="reference external" href="http://bazaar.canonical.com/">Bazaar</a>, etc.</p>
<p>If you're familiar with one of these tools, this is probably your best
option since it doesn't require any support or buy-in from the Django
core developers.</p>
<p>However, do keep in mind that Django will continue to use Subversion for
the foreseeable future, and this will naturally limit the recognition of
your branch. Further, if your branch becomes eligible for merging to
trunk you'll need to find a core developer familiar with your DVCS of
choice who'll actually perform the merge.</p>
<p>If you do decided to start a distributed branch of Django and choose to
make it public, please add the branch to the <a class="reference external" href="http://code.djangoproject.com/wiki/DjangoBranches">Django branches</a> wiki
page.</p>
</li>
<li><p class="first">Feature branches using SVN have a higher bar. If you want a branch
in SVN itself, you'll need a "mentor" among the <a class="reference internal" href="committers.html"><em>core committers</em></a>. This person is responsible for actually
creating the branch, monitoring your process (see below), and
ultimately merging the branch into trunk.</p>
<p>If you want a feature branch in SVN, you'll need to ask in
<a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a> for a mentor.</p>
</li>
</ol>
<div class="section" id="s-branch-rules">
<span id="branch-rules"></span><h3>Branch rules<a class="headerlink" href="#branch-rules" title="Permalink to this headline">¶</a></h3>
<p>We've got a few rules for branches born out of experience with what makes a
successful Django branch.</p>
<p>DVCS branches are obviously not under central control, so we have no way of
enforcing these rules. However, if you're using a DVCS, following these rules
will give you the best chance of having a successful branch (read: merged back
to trunk).</p>
<p>Developers with branches in SVN, however, <strong>must</strong> follow these rules. The
branch mentor will keep on eye on the branch and <strong>will delete it</strong> if these
rules are broken.</p>
<ul>
<li><p class="first">Only branch entire copies of the Django tree, even if work is only
happening on part of that tree. This makes it painless to switch to a
branch.</p>
</li>
<li><p class="first">Merge changes from trunk no less than once a week, and preferably every
couple-three days.</p>
<p>In our experience, doing regular trunk merges is often the difference
between a successful branch and one that fizzles and dies.</p>
<p>If you're working on an SVN branch, you should be using <a class="reference external" href="http://www.orcaware.com/svn/wiki/Svnmerge.py">svnmerge.py</a>
to track merges from trunk.</p>
</li>
<li><p class="first">Keep tests passing and documentation up-to-date. As with patches,
we'll only merge a branch that comes with tests and documentation.</p>
</li>
</ul>
<p>Once the branch is stable and ready to be merged into the trunk, alert
<a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a>.</p>
<p>After a branch has been merged, it should be considered "dead"; write access to
it will be disabled, and old branches will be periodically "trimmed." To keep
our SVN wrangling to a minimum, we won't be merging from a given branch into
the trunk more than once.</p>
</div>
<div class="section" id="s-using-branches">
<span id="using-branches"></span><h3>Using branches<a class="headerlink" href="#using-branches" title="Permalink to this headline">¶</a></h3>
<p>To use a branch, you'll need to do two things:</p>
<ul class="simple">
<li>Get the branch's code through Subversion.</li>
<li>Point your Python <tt class="docutils literal"><span class="pre">site-packages</span></tt> directory at the branch's version of
the <tt class="docutils literal"><span class="pre">django</span></tt> package rather than the version you already have
installed.</li>
</ul>
<div class="section" id="s-getting-the-code-from-subversion">
<span id="getting-the-code-from-subversion"></span><h4>Getting the code from Subversion<a class="headerlink" href="#getting-the-code-from-subversion" title="Permalink to this headline">¶</a></h4>
<p>To get the latest version of a branch's code, check it out using Subversion:</p>
<div class="highlight-bash"><div class="highlight"><pre>svn co http://code.djangoproject.com/svn/django/branches/<branch>/
</pre></div>
</div>
<p>...where <tt class="docutils literal"><span class="pre"><branch></span></tt> is the branch's name. See the <a class="reference external" href="http://code.djangoproject.com/browser/django/branches">list of branch names</a>.</p>
<p>Alternatively, you can automatically convert an existing directory of the
Django source code as long as you've checked it out via Subversion. To do the
conversion, execute this command from within your <tt class="docutils literal"><span class="pre">django</span></tt> directory:</p>
<div class="highlight-bash"><div class="highlight"><pre>svn switch http://code.djangoproject.com/svn/django/branches/<branch>/
</pre></div>
</div>
<p>The advantage of using <tt class="docutils literal"><span class="pre">svn</span> <span class="pre">switch</span></tt> instead of <tt class="docutils literal"><span class="pre">svn</span> <span class="pre">co</span></tt> is that the
<tt class="docutils literal"><span class="pre">switch</span></tt> command retains any changes you might have made to your local copy
of the code. It attempts to merge those changes into the "switched" code. The
disadvantage is that it may cause conflicts with your local changes if the
"switched" code has altered the same lines of code.</p>
<p>(Note that if you use <tt class="docutils literal"><span class="pre">svn</span> <span class="pre">switch</span></tt>, you don't need to point Python at the new
version, as explained in the next section.)</p>
</div>
<div class="section" id="s-pointing-python-at-the-new-django-version">
<span id="pointing-python-at-the-new-django-version"></span><h4>Pointing Python at the new Django version<a class="headerlink" href="#pointing-python-at-the-new-django-version" title="Permalink to this headline">¶</a></h4>
<p>Once you've retrieved the branch's code, you'll need to change your Python
<tt class="docutils literal"><span class="pre">site-packages</span></tt> directory so that it points to the branch version of the
<tt class="docutils literal"><span class="pre">django</span></tt> directory. (The <tt class="docutils literal"><span class="pre">site-packages</span></tt> directory is somewhere such as
<tt class="docutils literal"><span class="pre">/usr/lib/python2.4/site-packages</span></tt> or
<tt class="docutils literal"><span class="pre">/usr/local/lib/python2.4/site-packages</span></tt> or <tt class="docutils literal"><span class="pre">C:\Python\site-packages</span></tt>.)</p>
<p>The simplest way to do this is by renaming the old <tt class="docutils literal"><span class="pre">django</span></tt> directory to
<tt class="docutils literal"><span class="pre">django.OLD</span></tt> and moving the trunk version of the code into the directory
and calling it <tt class="docutils literal"><span class="pre">django</span></tt>.</p>
<p>Alternatively, you can use a symlink called <tt class="docutils literal"><span class="pre">django</span></tt> that points to the
location of the branch's <tt class="docutils literal"><span class="pre">django</span></tt> package. If you want to switch back, just
change the symlink to point to the old code.</p>
<p>A third option is to use a <a class="reference external" href="http://docs.python.org/library/site.html">path file</a> (<tt class="docutils literal"><span class="pre"><something>.pth</span></tt>) which should
work on all systems (including Windows, which doesn't have symlinks
available). First, make sure there are no files, directories or symlinks named
<tt class="docutils literal"><span class="pre">django</span></tt> in your <tt class="docutils literal"><span class="pre">site-packages</span></tt> directory. Then create a text file named
<tt class="docutils literal"><span class="pre">django.pth</span></tt> and save it to your <tt class="docutils literal"><span class="pre">site-packages</span></tt> directory. That file
should contain a path to your copy of Django on a single line and optional
comments. Here is an example that points to multiple branches. Just uncomment
the line for the branch you want to use ('Trunk' in this example) and make
sure all other lines are commented:</p>
<div class="highlight-python"><pre># Trunk is a svn checkout of:
# http://code.djangoproject.com/svn/django/trunk/
#
/path/to/trunk
# <branch> is a svn checkout of:
# http://code.djangoproject.com/svn/django/branches/<branch>/
#
#/path/to/<branch>
# On windows a path may look like this:
# C:/path/to/<branch></pre>
</div>
<p>If you're using Django 0.95 or earlier and installed it using
<tt class="docutils literal"><span class="pre">python</span> <span class="pre">setup.py</span> <span class="pre">install</span></tt>, you'll have a directory called something like
<tt class="docutils literal"><span class="pre">Django-0.95-py2.4.egg</span></tt> instead of <tt class="docutils literal"><span class="pre">django</span></tt>. In this case, edit the file
<tt class="docutils literal"><span class="pre">setuptools.pth</span></tt> and remove the line that references the Django <tt class="docutils literal"><span class="pre">.egg</span></tt>
file. Then copy the branch's version of the <tt class="docutils literal"><span class="pre">django</span></tt> directory into
<tt class="docutils literal"><span class="pre">site-packages</span></tt>.</p>
</div>
</div>
</div>
<div class="section" id="s-how-we-make-decisions">
<span id="how-we-make-decisions"></span><h2>How we make decisions<a class="headerlink" href="#how-we-make-decisions" title="Permalink to this headline">¶</a></h2>
<p>Whenever possible, we strive for a rough consensus. To that end, we'll often
have informal votes on <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a> about a feature. In these votes we
follow the voting style invented by Apache and used on Python itself, where
votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:</p>
<ul class="simple">
<li>+1: "I love the idea and I'm strongly committed to it."</li>
<li>+0: "Sounds OK to me."</li>
<li>-0: "I'm not thrilled, but I won't stand in the way."</li>
<li>-1: "I strongly disagree and would be very unhappy to see the idea turn
into reality."</li>
</ul>
<p>Although these votes on django-developers are informal, they'll be taken very
seriously. After a suitable voting period, if an obvious consensus arises
we'll follow the votes.</p>
<p>However, consensus is not always possible. If consensus cannot be reached, or
if the discussion towards a consensus fizzles out without a concrete decision,
we use a more formal process.</p>
<p>Any core committer (see below) may call for a formal vote using the same
voting mechanism above. A proposition will be considered carried by the core
team if:</p>
<ul class="simple">
<li>There are three "+1" votes from members of the core team.</li>
<li>There is no "-1" vote from any member of the core team.</li>
<li>The BDFLs haven't stepped in and executed their positive or negative
veto.</li>
</ul>
<p>When calling for a vote, the caller should specify a deadline by which
votes must be received. One week is generally suggested as the minimum
amount of time.</p>
<p>Since this process allows any core committer to veto a proposal, any "-1"
votes (or BDFL vetos) should be accompanied by an explanation that explains
what it would take to convert that "-1" into at least a "+0".</p>
<p>Whenever possible, these formal votes should be announced and held in
public on the <a class="reference external" href="http://groups.google.com/group/django-developers">django-developers</a> mailing list. However, overly sensitive
or contentious issues -- including, most notably, votes on new core
committers -- may be held in private.</p>
</div>
<div class="section" id="s-commit-access">
<span id="commit-access"></span><h2>Commit access<a class="headerlink" href="#commit-access" title="Permalink to this headline">¶</a></h2>
<p>Django has two types of committers:</p>
<dl class="docutils">
<dt>Core committers</dt>
<dd>These are people who have a long history of contributions to Django's
codebase, a solid track record of being polite and helpful on the
mailing lists, and a proven desire to dedicate serious time to Django's
development. The bar is high for full commit access.</dd>
<dt>Partial committers</dt>
<dd><p class="first">These are people who are "domain experts." They have direct check-in access
to the subsystems that fall under their jurisdiction, and they're given a
formal vote in questions that involve their subsystems. This type of access
is likely to be given to someone who contributes a large subframework to
Django and wants to continue to maintain it.</p>
<p class="last">Partial commit access is granted by the same process as full
committers. However, the bar is set lower; proven expertise in the area
in question is likely to be sufficient.</p>
</dd>
</dl>
<p>Decisions on new committers will follow the process explained above in <a class="reference internal" href="#how-we-make-decisions">how
we make decisions</a>.</p>
<p>To request commit access, please contact an existing committer privately.
Public requests for commit access are potential flame-war starters, and
will be ignored.</p>
</div>
</div>
</div>
</div>
</div>
<div class="yui-b" id="sidebar">
<div class="sphinxsidebar">
<div class="sphinxsidebarwrapper">
<h3><a href="../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Contributing to Django</a><ul>
<li><a class="reference internal" href="#reporting-bugs">Reporting bugs</a></li>
<li><a class="reference internal" href="#reporting-security-issues">Reporting security issues</a></li>
<li><a class="reference internal" href="#submitting-patches">Submitting patches</a><ul>
<li><a class="reference internal" href="#claiming-tickets">“Claiming” tickets</a><ul>
<li><a class="reference internal" href="#ticket-claimers-responsibility">Ticket claimers’ responsibility</a></li>
<li><a class="reference internal" href="#which-tickets-should-be-claimed">Which tickets should be claimed?</a></li>
</ul>
</li>
<li><a class="reference internal" href="#patch-style">Patch style</a></li>
<li><a class="reference internal" href="#non-trivial-patches">Non-trivial patches</a></li>
</ul>
</li>
<li><a class="reference internal" href="#ticket-triage">Ticket triage</a><ul>
<li><a class="reference internal" href="#triage-stages">Triage stages</a></li>
<li><a class="reference internal" href="#ticket-resolutions">Ticket Resolutions</a></li>
<li><a class="reference internal" href="#triage-by-the-general-community">Triage by the general community</a></li>
</ul>
</li>
<li><a class="reference internal" href="#submitting-and-maintaining-translations">Submitting and maintaining translations</a></li>
<li><a class="reference internal" href="#submitting-javascript-patches">Submitting javascript patches</a></li>
<li><a class="reference internal" href="#django-conventions">Django conventions</a><ul>
<li><a class="reference internal" href="#use-of-django-conf-settings">Use of <tt class="docutils literal"><span class="pre">django.conf.settings</span></tt></a></li>
</ul>
</li>
<li><a class="reference internal" href="#coding-style">Coding style</a><ul>
<li><a class="reference internal" href="#template-style">Template style</a></li>
<li><a class="reference internal" href="#view-style">View style</a></li>
<li><a class="reference internal" href="#model-style">Model style</a></li>
</ul>
</li>
<li><a class="reference internal" href="#documentation-style">Documentation style</a><ul>
<li><a class="reference internal" href="#how-to-document-new-features">How to document new features</a></li>
<li><a class="reference internal" href="#guidelines-for-rest-files">Guidelines for reST files</a></li>
<li><a class="reference internal" href="#commonly-used-terms">Commonly used terms</a></li>
<li><a class="reference internal" href="#django-specific-terminology">Django-specific terminology</a></li>
</ul>
</li>
<li><a class="reference internal" href="#committing-code">Committing code</a><ul>
<li><a class="reference internal" href="#reverting-commits">Reverting commits</a></li>
</ul>
</li>
<li><a class="reference internal" href="#unit-tests">Unit tests</a><ul>
<li><a class="reference internal" href="#running-the-unit-tests">Running the unit tests</a><ul>
<li><a class="reference internal" href="#quickstart">Quickstart</a></li>
<li><a class="reference internal" href="#using-another-settings-module">Using another <tt class="docutils literal"><span class="pre">settings</span></tt> module</a></li>
<li><a class="reference internal" href="#running-only-some-of-the-tests">Running only some of the tests</a></li>
<li><a class="reference internal" href="#running-all-the-tests">Running all the tests</a></li>
</ul>
</li>
<li><a class="reference internal" href="#contrib-apps">Contrib apps</a></li>
</ul>
</li>
<li><a class="reference internal" href="#requesting-features">Requesting features</a></li>
<li><a class="reference internal" href="#branch-policy">Branch policy</a><ul>
<li><a class="reference internal" href="#branch-rules">Branch rules</a></li>
<li><a class="reference internal" href="#using-branches">Using branches</a><ul>
<li><a class="reference internal" href="#getting-the-code-from-subversion">Getting the code from Subversion</a></li>
<li><a class="reference internal" href="#pointing-python-at-the-new-django-version">Pointing Python at the new Django version</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#how-we-make-decisions">How we make decisions</a></li>
<li><a class="reference internal" href="#commit-access">Commit access</a></li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="index.html">Django internals</a></li>
<li>Next: <a href="documentation.html">How the Django documentation works</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../index.html">Django v1.3.1 documentation</a>
<ul><li><a href="index.html">Django internals</a>
<ul><li>Contributing to Django</li></ul>
</li></ul>
</li>
</ul>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/internals/contributing.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<input type="text" name="q" size="18" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Sep 10, 2011</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="index.html" title="Django internals">previous</a>
|
<a href="index.html" title="Django internals" accesskey="U">up</a>
|
<a href="documentation.html" title="How the Django documentation works">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
