<ahref="http://en.wikipedia.org/wiki/Bus_factor">"bus factor"</a>, and can continue to remain well supported for the foreseeable future. Suggestions for improvements to our process are welcome.</p>
<p>We have a quarterly maintenance cycle where new members may join the maintenance team. We currently cap the size of the team at 5 members, and may encourage folks to step out of the team for a cycle to allow new members to participate.</p>
<p>Each maintenance cycle is initiated by an issue being opened with the <code>Process</code> label.</p>
<ul>
<li>To be considered for a maintainer role simply comment against the issue.</li>
<li>Existing members must explicitly opt-in to the next cycle by check-marking their name.</li>
<li>The final decision on the incoming team will be made by <code>@tomchristie</code>.</li>
</ul>
<p>Members of the maintenance team will be added as collaborators to the repository.</p>
<p>The following template should be used for the description of the issue, and serves as the formal process for selecting the team.</p>
<pre><code>This issue is for determining the maintenance team for the *** period.
Please see the [Project management](http://www.django-rest-framework.org/topics/project-management/) section of our documentation for more details.
---
#### Renewing existing members.
The following people are the current maintenance team. Please checkmark your name if you wish to continue to have write permission on the repository for the *** period.
- [ ] @***
- [ ] @***
- [ ] @***
- [ ] @***
- [ ] @***
---
#### New members.
If you wish to be considered for this or a future date, please comment against this or subsequent issues.
To modify this process for future maintenance cycles make a pull request to the [project management](http://www.django-rest-framework.org/topics/project-management/) documentation.
<li>Code changes should come in the form of a pull request - do not push directly to master.</li>
<li>Maintainers should typically not merge their own pull requests.</li>
<li>Each issue/pull request should have exactly one label once triaged.</li>
<li>Search for un-triaged issues with <ahref="https://github.com/tomchristie/django-rest-framework/issues?q=is%3Aopen+no%3Alabel">is:open no:label</a>.</li>
</ul>
<p>It should be noted that participating actively in the REST framework project clearly <strong>does not require being part of the maintenance team</strong>. Almost every import part of issue triage and project improvement can be actively worked on regardless of your collaborator status on the repository.</p>
<p>The release manager is selected on every quarterly maintenance cycle.</p>
<ul>
<li>The manager should be selected by <code>@tomchristie</code>.</li>
<li>The manager will then have the maintainer role added to PyPI package.</li>
<li>The previous manager will then have the maintainer role removed from the PyPI package.</li>
</ul>
<p>Our PyPI releases will be handled by either the current release manager, or by <code>@tomchristie</code>. Every release should have an open issue tagged with the <code>Release</code> label and marked against the appropriate milestone.</p>
<p>The following template should be used for the description of the issue, and serves as a release checklist.</p>
- [ ] Create pull request for [release notes](https://github.com/tomchristie/django-rest-framework/blob/master/docs/topics/release-notes.md) based on the [*.*.* milestone](https://github.com/tomchristie/django-rest-framework/milestones/***).
- [ ] Ensure the pull request increments the version to `*.*.*` in [`restframework/__init__.py`](https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/__init__.py).
- [ ] Confirm with @tomchristie that release is finalized and ready to go.
- [ ] Ensure that release date is included in pull request.
- [ ] Merge the release pull request.
- [ ] Push the package to PyPI with `./setup.py publish`.
- [ ] Tag the release, with `git tag -a *.*.* -m 'version *.*.*'; git push --tags`.
- [ ] Deploy the documentation with `mkdocs gh-deploy`.
- [ ] Make a release announcement on the [discussion group](https://groups.google.com/forum/?fromgroups#!forum/django-rest-framework).
To modify this process for future releases make a pull request to the [project management](http://www.django-rest-framework.org/topics/project-management/) documentation.
<p>When pushing the release to PyPI ensure that your environment has been installed from our development <code>requirement.txt</code>, so that documentation and PyPI installs are consistently being built against a pinned set of packages.</p>
<p>The maintenance team are responsible for managing the translation packs include in REST framework. Translating the source strings into multiple languages is managed through the <ahref="https://www.transifex.com/projects/p/django-rest-framework/">transifex service</a>.</p>
<p>The <ahref="https://pypi.python.org/pypi/transifex-client">official Transifex client</a> is used to upload and download translations to Transifex. The client is installed using pip:</p>
<pre><code>pip install transifex-client
</code></pre>
<p>To use it you'll need a login to Transifex which has a password, and you'll need to have administrative access to the Transifex project. You'll need to create a <code>~/.transifexrc</code> file which contains your credentials.</p>
<p>When any user visible strings are changed, they should be uploaded to Transifex so that the translators can start to translate them. To do this, just run:</p>
<pre><code># 1. Update the source django.po file, which is the US English version.
cd rest_framework
django-admin.py makemessages -l en_US
# 2. Push the source django.po file to Transifex.
cd ..
tx push -s
</code></pre>
<p>When pushing source files, Transifex will update the source strings of a resource to match those from the new source file.</p>
<p>Here's how differences between the old and new source files will be handled:</p>
<ul>
<li>New strings will be added.</li>
<li>Modified strings will be added as well.</li>
<li>Strings which do not exist in the new source file will be removed from the database, along with their translations. If that source strings gets re-added later then <ahref="http://docs.transifex.com/guides/tm#let-tm-automatically-populate-translations">Transifex Translation Memory</a> will automatically include the translation string.</li>
<p>When a translator has finished translating their work needs to be downloaded from Transifex into the REST framework repository. To do this, run:</p>
<pre><code># 3. Pull the translated django.po files from Transifex.
<p>All our test requirements are pinned to exact versions, in order to ensure that our test runs are reproducible. We maintain the requirements in the <code>requirements</code> directory. The requirements files are referenced from the <code>tox.ini</code> configuration file, ensuring we have a single source of truth for package versions used in testing.</p>
<p>Package upgrades should generally be treated as isolated pull requests. You can check if there are any packages available at a newer version, by using the <code>pip list --outdated</code>.</p>
<p>The PyPI package is owned by <code>@tomchristie</code>. As a backup <code>@j4mie</code> also has ownership of the package.</p>
<p>If <code>@tomchristie</code> ceases to participate in the project then <code>@j4mie</code> has responsibility for handing over ownership duties.</p>
<h4id="outstanding-management-ownership-issues"><aclass="toclink"href="#outstanding-management-ownership-issues">Outstanding management & ownership issues</a></h4>
