Merge branch 'team-organization'.

https://groups.google.com/d/msg/django-developers/8b-wxEzWO3c/Hx3Uqg9XrksJ

docs/faq/general.txt

@@ -66,9 +66,8 @@ Who's behind this?
 ------------------
 
 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
+newspaper in Lawrence, Kansas, USA. Django's now run by an international
-volunteers; you can read all about them over at the :doc:`list of committers
+:doc:`team of volunteers </internals/team>`.
-</internals/committers>`.
 
 Which sites use Django?
 -----------------------

docs/index.txt

@@ -310,7 +310,9 @@ you can contribute:
 * **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>`

docs/internals/contributing/bugs-and-features.txt

@@ -150,29 +150,24 @@ follow the votes.
 
 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
+Internally, the technical board will use the same voting mechanism. A
-using the same voting mechanism above. A proposition will be considered carried
+proposition will be considered carried if:
-by the core team 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 should be submitted within a week.
-votes must be received. One week is generally suggested as the minimum
-amount of time.
 
-Since this process allows any core committer to veto a proposal, any "-1"
+Since this process allows any technical board member to veto a proposal, a
-votes should be accompanied by an explanation that explains what it would
+"-1" vote should be accompanied by an explanation of what it would take to
-take to convert that "-1" into at least a "+0".
+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.
 
+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

docs/internals/contributing/committing-code.txt

@@ -2,38 +2,11 @@
 Committing code
 ===============
 
-This section is addressed to the :doc:`/internals/committers` and to anyone
+This section is addressed to the :ref:`committers` and to anyone interested in
-interested in knowing how code gets committed into Django core. If you're a
+knowing how code gets committed into Django core. If you're a community member
-community member who wants to contribute code to Django, have a look at
+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
@@ -136,7 +109,7 @@ Django's Git repository:
 
   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.
@@ -169,7 +142,7 @@ Django's Git repository:
   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
@@ -196,7 +169,6 @@ Django's Git repository:
     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

docs/internals/contributing/new-contributors.txt

@@ -102,8 +102,8 @@ some advice to make your work on Django more useful and rewarding.
   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
+  ultimately have a much greater impact than that of the core team. We can't
-  can't do it without YOU!
+  do it without **you**!
 
 * **Err on the side of caution when marking things Ready For Check-in**
 
@@ -138,10 +138,10 @@ FAQ
    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
+   (even the core team), and sometimes folks just don't have time. The best
-   best thing to do is to send a gentle reminder to the |django-developers|
+   thing to do is to send a gentle reminder to the |django-developers| mailing
-   mailing list asking for review on the ticket, or to bring it up in the
+   list asking for review on the ticket, or to bring it up in the #django-dev
-   #django-dev IRC channel.
+   IRC channel.
 
 2. **I'm sure my ticket is absolutely 100% perfect, can I mark it as RFC
    myself?**

docs/internals/contributing/triaging-tickets.txt

@@ -29,7 +29,7 @@ possible, and raise issues for discussion on our mailing lists when there is
 confusion or disagreement.
 
 Django is a community project, and every contribution helps. We can't do this
-without YOU!
+without **you**!
 
 Triage workflow
 ---------------
@@ -57,10 +57,9 @@ Since a picture is worth a thousand words, let's start there:
 
 We've got two roles in this diagram:
 
-* :doc:`Committers</internals/committers>` (also called core developers):
+* Committers (also called core developers): people with commit access who are
-  people with commit access who are responsible for making the big
+  responsible for making decisions and integrating the contributions of the
-  decisions, writing large portions of the code and integrating the
+  community.
-  contributions of the community.
 
 * Ticket triagers: anyone in the Django community who chooses to
   become involved in Django's development process. Our Trac installation
@@ -147,7 +146,7 @@ Ready For Checkin
 
 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?"
@@ -314,7 +313,7 @@ A ticket can be resolved in a number of ways:
       discussion in the |django-developers| mailing list. Feel free to
       start or join in discussions of "wontfix" tickets on the
       |django-developers| mailing list, but please do not reopen tickets
-      closed as "wontfix" by a :doc:`core developer</internals/committers>`.
+      closed as "wontfix" by a :doc:`core developer</internals/team>`.
 
 * duplicate
       Used when another ticket covers the same issue. By closing duplicate
@@ -407,7 +406,7 @@ the ticket database:
   review a patch that you submit.
 
 * Please **don't** reverse a decision that has been made by a :doc:`core
-  developer</internals/committers>`. If you disagree with a decision that
+  developer</internals/team>`. If you disagree with a decision that
   has been made, please post a message to |django-developers|.
 
 * If you're unsure if you should be making a change, don't make the

docs/internals/contributing/writing-code/working-with-git.txt

@@ -7,7 +7,7 @@ requests. If you're interested in how core developers handle them, see
 
 Below, we are going to show how to create a GitHub pull request containing the
 changes for Trac ticket #xxxxx. By creating a fully-ready pull request you
-will make the committers' job easier, meaning that your work is more likely to
+will make the reviewer's job easier, meaning that your work is more likely to
 be merged into Django.
 
 You could also upload a traditional patch to Trac, but it's less practical for

docs/internals/git.txt

@@ -243,7 +243,8 @@ branches, used for Google Summer of Code projects.
 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.
 

docs/internals/index.txt

@@ -2,23 +2,16 @@ Django internals
 ================
 
 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
+you'd like to help improve Django or learn about how Django is managed.
-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.
 
 .. toctree::
    :maxdepth: 2
 
    contributing/index
    mailing-lists
-   committers
+   organization
+   team
+   roles
    security
    release-process
    deprecation

docs/internals/mailing-lists.txt

@@ -40,9 +40,9 @@ installation, usage, or debugging of Django.
 ``django-core-mentorship``
 --------------------------
 
-The Django Core Development Mentorship list is intended to provide a welcoming
+The Django Core Mentorship list is intended to provide a welcoming
-introductory environment for developers interested in contributing to core
+introductory environment for community members interested in contributing to
-Django development.
+the Django Project.
 
 * `django-core-mentorship mailing archive`_
 * `django-core-mentorship subscription email address`_

docs/internals/organization.txt

@@ -0,0 +1,190 @@
+==================================
+Organization of the Django Project
+==================================
+
+Principles
+==========
+
+The Django Project is managed by a team of volunteers pursuing three goals:
+
+- Driving the development of the Django Web Framework,
+- Fostering the ecosystem of Django-related software,
+- Leading the Django community in accordance with the values described in the
+  `Django Code of Conduct`_.
+
+The Django Project isn't a legal entity. The `Django Software Foundation`_, a
+non-profit organization, handles financial and legal matters related to the
+Django Project. Other than that, the Django Software Foundation lets the
+Django Project manage the development of the Django framework, its ecosystem
+and its community.
+
+.. _Django Code of Conduct: https://www.djangoproject.com/conduct/
+.. _Django Software Foundation: https://www.djangoproject.com/foundation/
+
+The Django core team makes the decisions, nominates its new members, and
+elects its technical board. While it holds decision power in theory, it aims
+at using it as rarely as possible in practice. Rough consensus should be the
+norm and formal voting an exception.
+
+.. _core-team:
+
+Core team
+=========
+
+Role
+----
+
+The core team is the group of trusted volunteers who manage the Django
+Project. They assume many roles required to achieve the project's goals,
+especially those that require a high level of trust. They make the decisions
+that shape the future of the project.
+
+Core team members are expected to act as role models for the community and
+custodians of the project, on behalf of the community and all those who rely
+on Django.
+
+They will intervene, where necessary, in online discussions or at official
+Django events on the rare occasions that a situation arises that requires
+intervention.
+
+They have authority over the Django Project infrastructure, including the
+Django Project website itself, the Django GitHub organization and
+repositories, the Trac bug tracker, the mailing lists, IRC channels, etc.
+
+Prerogatives
+------------
+
+Core team members may participate in formal votes, typically to nominate new
+team members and to elect the technical board.
+
+Some contributions don't require commit access. Depending on the reasons why a
+contributor joins the team, they may or may not have commit permissions to the
+Django code repository.
+
+However, should the need arise, any team member may ask for commit access by
+writing to the core team's mailing list. Access will be granted unless the
+person withdraws their request or the technical board vetoes the proposal.
+
+Core team members who have commit access are referred to as "committers" or
+"core developers".
+
+Other permissions, such as access to the servers, are granted to those who
+need them through the same process.
+
+Membership
+----------
+
+The core team finds its origins with the :ref:`four people
+<original-team-list>` who created Django. It has grown to :ref:`a few dozen
+people <core-team-list>` by co-opting volunteers who demonstrate:
+
+- a good grasp of the philosophy of the Django Project
+- a solid track record of being constructive and helpful
+- significant contributions to the project's goals, in any form
+- willingness to dedicate some time to improving Django
+
+As the project matures, contributions go way beyond code. Here's an incomplete
+list of areas where contributions may be considered for joining the core team,
+in no particular order:
+
+- Working on community management and outreach
+- Providing support on the mailing-lists and on IRC
+- Triaging tickets
+- Writing patches (code, docs, or tests)
+- Reviewing patches (code, docs, or tests)
+- Participating in design decisions
+- Providing expertise in a particular domain (security, i18n, etc.)
+- Managing the continuous integration infrastructure
+- Managing the servers (website, tracker, documentation, etc.)
+- Maintaining related projects (djangoproject.com site, ex-contrib apps, etc.)
+- Creating visual designs
+
+Very few areas are reserved to core team members:
+
+- Reviewing security reports
+- Merging patches (code, docs, or tests)
+- Packaging releases
+
+Core team membership acknowledges sustained and valuable efforts that align
+well with the philosophy and the goals of the Django Project.
+
+It is granted by a four fifths majority of votes cast in a core team vote and
+no veto by the technical board.
+
+Core team members are always looking for promising contributors, teaching them
+how the project is managed, and submitting their names to the core team's vote
+when they're ready. If you would like to join the core team, you can contact a
+core team member privately or ask for guidance on the :ref:`Django Core
+Mentorship mailing-list <django-core-mentorship-mailing-list>`.
+
+There's no time limit on core team membership. However, in order to provide
+the general public with a reasonable idea of how many people maintain Django,
+core team members who have stopped contributing are encouraged to declare
+themselves as "past team members". Those who haven't made any non-trivial
+contribution in two years may be asked to move themselves to this category,
+and moved there if they don't respond. Past team members lose their privileges
+such as voting rights and commit access.
+
+.. _technical-board:
+
+Technical board
+===============
+
+Role
+----
+
+The technical board is a group of experienced and active committers who steer
+technical choices. Their main concern is to maintain the quality and stability
+of the Django Web Framework.
+
+Prerogatives
+------------
+
+The technical board holds two prerogatives:
+
+- Making major technical decisions when no consensus is found otherwise. This
+  happens on the |django-developers| mailing-list.
+- Veto a grant of commit access or remove commit access. This happens on the
+  django-core mailing-list.
+
+In both cases, the technical board is a last resort. In these matters, it
+fulfills a similar function to the former Benevolent Dictators For Life.
+
+When the board wants to exercise one of these prerogatives, it must hold a
+private, simple majority vote on the resolution. The quorum is the full
+committee — each member must cast a vote or abstain explicitly. Then the board
+communicates the result, and if possible the reasons, on the appropriate
+mailing-list. There's no appeal for such decisions.
+
+In addition, at its discretion, the technical board may act in an advisory
+capacity on non-technical decisions.
+
+Membership
+----------
+
+The technical board is an elected group of five committers. They're expected
+to be experienced but there's no formal seniority requirement. Its current
+composition is published :ref:`here <technical-board-list>`.
+
+A new board is elected after each major release of Django. The election
+process is managed by the outgoing technical board. The first election is
+bootstrapped by the retiring BDFLs. The election process works as follows:
+
+1. Candidates advertise their application for the technical board to the team.
+
+   They must be committers already. There's no term limit for technical board
+   members.
+
+2. Each team member can vote for zero to five people among the candidates.
+   Candidates are ranked by the total number of votes they received.
+
+   In case of a tie, the person who joined the core team earlier wins.
+
+Both the application and the voting period last between one and two weeks, at
+the outgoing board's discretion.
+
+Changing the organization
+=========================
+
+Changes to this document require a four fifths majority of votes cast in a
+core team vote and no veto by the technical board.

docs/internals/release-process.txt

@@ -144,11 +144,11 @@ Release process
 Django uses a time-based release schedule, with major (i.e. 1.6, 1.7, etc.)
 releases every nine months, or more, depending on features.
 
-After each release, and after a suitable cooling-off period of a few weeks, the
+After each release, and after a suitable cooling-off period of a few weeks,
-core development team will examine the landscape and announce a timeline for the
+core developers will examine the landscape and announce a timeline for the
-next release. Most releases will be scheduled in the 6-9 month range, but if we
+next release. Most releases will be scheduled in the 6-9 month range, but if
-have bigger features to development we might schedule a longer period to allow
+we have bigger features to development we might schedule a longer period to
-for more ambitious work.
+allow for more ambitious work.
 
 Release cycle
 -------------

docs/internals/roles.txt

@@ -0,0 +1,53 @@
+=====
+Roles
+=====
+
+.. _technical-board-list:
+
+Technical board
+===============
+
+The first technical board hasn't been elected yet.
+
+.. _committers:
+
+Committers
+==========
+
+Most :ref:`core team <core-team>` members have commit access. They're called
+"committers" or "core developers".
+
+Being part of the core team is a pre-requisite for having commit access.
+
+.. _security-team-list:
+
+Security team
+=============
+
+The security team is responsible for :doc:`Django's security policies
+</internals/security>`. It handles private reports of security issues.
+
+The current security team members are:
+
+- Florian Apolloner
+- James Bennett
+- Jeremy Dunck
+- Adrian Holovaty
+- Jacob Kaplan-Moss
+- Russell Keith-Magee
+- Paul McMillan
+- Carl Meyer
+- Donald Stufft
+
+.. _releasers-list:
+
+Releasers
+=========
+
+Releasers take care of :doc:`building Django releases
+</internals/howto-release-django>`.
+
+The current releasers are:
+
+- James Bennett
+- Jacob Kaplan-Moss

docs/internals/security.txt

@@ -19,21 +19,20 @@ Reporting security issues
 **Short version: please report security issues by emailing
 security@djangoproject.com**.
 
-Most normal bugs in Django are reported to `our public Trac
+Most normal bugs in Django are reported to `our public Trac instance`_, but
-instance`_, but due to the sensitive nature of security issues, we ask
+due to the sensitive nature of security issues, we ask that they **not** be
-that they **not** be publicly reported in this fashion.
+publicly reported in this fashion.
 
-Instead, if you believe you've found something in Django which has
+Instead, if you believe you've found something in Django which has security
-security implications, please send a description of the issue via
+implications, please send a description of the issue via email to
-email to ``security@djangoproject.com``. Mail sent to that address
+``security@djangoproject.com``. Mail sent to that address reaches a
-reaches a subset of the core development team, who can forward
+:ref:`subset of the core team <security-team-list>`, who can forward security
-security issues into the private committers' mailing list for broader
+issues into the private committers' mailing list for broader discussion if
-discussion if needed.
+needed.
 
-Once you've submitted an issue via email, you should receive an
+Once you've submitted an issue via email, you should receive an acknowledgment
-acknowledgment from a member of the Django development team within 48
+from a member of the security team within 48 hours, and depending on the
-hours, and depending on the action to be taken, you may receive
+action to be taken, you may receive further followup emails.
-further followup emails.
 
 .. note::
 

docs/internals/team.txt

@@ -1,6 +1,8 @@
-=================
+===========
-Django committers
+Django team
-=================
+===========
+
+.. _original-team-list:
 
 The original team
 =================
@@ -55,18 +57,15 @@ Journal-World`_ of Lawrence, Kansas, USA.
 .. _heroku: http://heroku.com/
 .. _Rdio: http://rdio.com
 
-Current developers
+.. _core-team-list:
-==================
 
-Currently, Django is led by a team of volunteers from around the globe.
+The current team
-
+================
-Core developers
----------------
 
 These are the folks who have a long history of contributions, a solid track
 record of being helpful on the mailing lists, and a proven desire to dedicate
-serious time to Django. In return, they've been granted the coveted commit bit,
+serious time to Django. In return, they've been invited to join the :ref:`core
-and have free rein to hack on all parts of Django.
+team <core-team>`.
 
 Malcolm Tredinnick
     Malcolm originally wanted to be a mathematician, somehow ended up a software
@@ -554,8 +553,8 @@ Baptiste Mispelon
     .. _Solid Links: http://solidlinks.nl/
     .. _Erik's Pony Checkup: http://ponycheckup.com/
 
-Developers Emeritus
+Past team members
-===================
+=================
 
 Georg "Hugo" Bauer
     Georg created Django's internationalization system, managed i18n