Adjusted 'internals' docs to the new organization.

Committing code

===============

This section is addressed to the :doc:`/internals/team` and to anyone

interested in knowing how code gets committed into Django core. If you're a

community member who wants to contribute code to Django, have a look at

This section is addressed to the :ref:`committers` and to anyone interested in

knowing how code gets committed into Django core. If you're a community member

who wants to contribute code to Django, have a look at

:doc:`writing-code/working-with-git` instead.

.. _handling-pull-requests:

  If you bring something up on |django-developers| 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

  implemented immediately because nobody contested it. Django's core

  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.

  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 *long way* in helping all core Django

  separate commit. This goes a *long way* in helping all Django core

  developers follow your changes.

* Separate bug fixes from feature changes. Bugfixes may need to be backported

    commit message, GitHub will close the pull request, but the Trac plugin

    will also close the same numbered ticket in Trac.

.. _Trac plugin: https://github.com/aaugustin/trac-github

* If your commit references a ticket in the Django `ticket tracker`_ but

  Sometimes it can be scary to put your opinion out to the world and say "this

  ticket is correct" or "this patch needs work", but it's the only way the

  project moves forward. The contributions of the broad Django community

  ultimately have a much greater impact than that of the core developers. We

  can't do it without YOU!

  ultimately have a much greater impact than that of the core team. We can't

  do it without **you**!

* **Err on the side of caution when marking things Ready For Check-in**

   I do to get it committed?**

   First off, it's not personal. Django is entirely developed by volunteers

   (even the core developers), and sometimes folks just don't have time. The

   best thing to do is to send a gentle reminder to the |django-developers|

   mailing list asking for review on the ticket, or to bring it up in the

   #django-dev IRC channel.

   (even the core team), and sometimes folks just don't have time. The best

   thing to do is to send a gentle reminder to the |django-developers| mailing

   list asking for review on the ticket, or to bring it up in the #django-dev

   IRC channel.

2. **I'm sure my ticket is absolutely 100% perfect, can I mark it as RFC

   myself?**

confusion or disagreement.

Django is a community project, and every contribution helps. We can't do this

without YOU!

without **you**!

Triage workflow

---------------

The ticket was reviewed by any member of the community other than the person

who supplied the patch and found to meet all the requirements for a

commit-ready patch. A core committer now needs to give the patch a final

commit-ready patch. A committer now needs to give the patch a final

review prior to being committed. See the

:ref:`New contributors' FAQ<new-contributors-faq>` for "My ticket has been in

RFC forever! What should I do?"

Tags

====

Each Django release is tagged and signed by Django's release manager.

Each Django release is tagged and signed by a :ref:`releaser

<releasers-list>`.

The tags can be found on GitHub's `tags`_ page.

================

Documentation for people hacking on Django itself. This is the place to go if

you'd like to help improve Django, learn or learn about how Django works "under

the hood".

.. warning::

    Elsewhere in the Django documentation, coverage of a feature is a sort of a

    contract: once an API is in the official documentation, we consider it

    "stable" and don't change it without a good reason. APIs covered here,

    however, are considered "internal-only": we reserve the right to change

    these internals if we must.

you'd like to help improve Django or learn about how Django is managed.

.. toctree::

   :maxdepth: 2