Merge branch 'team-organization'.

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

Django was originally developed at World Online, the Web department of a

newspaper in Lawrence, Kansas, USA. Django's now run by an international team of

volunteers; you can read all about them over at the :doc:`list of committers

</internals/committers>`.

newspaper in Lawrence, Kansas, USA. Django's now run by an international

:doc:`team of volunteers </internals/team>`.

Which sites use Django?

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

* **Community:**

  :doc:`How to get involved <internals/contributing/index>` |

  :doc:`The release process <internals/release-process>` |

  :doc:`Team of committers <internals/committers>` |

  :doc:`Team organization <internals/organization>` |

  :doc:`Meet the team <internals/team>` |

  :doc:`Current roles <internals/roles>` |

  :doc:`The Django source code repository <internals/git>` |

  :doc:`Security policies <internals/security>` |

  :doc:`Mailing lists <internals/mailing-lists>`

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.

any :ref:`core team member <core-team>` may defer the decision to the

:ref:`technical board <technical-board>`.

Any :doc:`core committer</internals/committers>` may call for a formal vote

using the same voting mechanism above. A proposition will be considered carried

by the core team if:

Internally, the technical board will use the same voting mechanism. A

proposition will be considered carried if:

* There are three "+1" votes from members of the core team.

* There are at least three "+1" votes from members of the technical board.

* There is no "-1" vote from any member of the core team.

* There is no "-1" vote from any member of the technical board.

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.

Votes should be submitted within a week.

Since this process allows any core committer to veto a proposal, any "-1"

votes should be accompanied by an explanation that explains what it would

take to convert that "-1" into at least a "+0".

Whenever possible, these formal votes should be announced and held in

public on the |django-developers| mailing list. However, overly sensitive

or contentious issues -- including, most notably, votes on new core

committers -- may be held in private.

Since this process allows any technical board member to veto a proposal, a

"-1" vote should be accompanied by an explanation of what it would take to

convert that "-1" into at least a "+0".

Votes on technical matters should be announced and held in public on the

|django-developers| mailing list.

.. _searching: https://code.djangoproject.com/search

.. _custom queries: https://code.djangoproject.com/query

Committing code

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

This section is addressed to the :doc:`/internals/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

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.

Commit access

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

Django has two types of committers:

Core committers

    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.

Partial committers

    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

    sub-framework to Django and wants to continue to maintain it.

    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.

Decisions on new committers will follow the process explained in

:ref:`how-we-make-decisions`. To request commit access, please contact an

existing committer privately. Public requests for commit access are potential

flame-war starters, and will simply be ignored.

.. _handling-pull-requests:

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?**