Adjusted 'internals' docs to the new organization.

Most of these changes are about using the correct vocabulary -- "core
team member" vs "core developer/committer" and adding internal links.

docs/internals/contributing/committing-code.txt

@@ -2,9 +2,9 @@
 Committing code
 ===============
 
-This section is addressed to the :doc:`/internals/team` 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.
 
 .. _handling-pull-requests:
@@ -109,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.
@@ -142,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
@@ -169,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
 ---------------
@@ -146,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?"

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,16 +2,7 @@ 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

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

@@ -33,6 +33,8 @@ Until 2014, the Django Project was a benevolent_ dictatorship_.
 .. _benevolent: http://www.holovaty.com/writing/bdfls-retiring/
 .. _dictatorship: http://jacobian.org/writing/retiring-as-bdfls/
 
+.. _core-team:
+
 Core team
 =========
 
@@ -130,6 +132,8 @@ 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
 ===============
 

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

@@ -9,6 +9,8 @@ Technical board
 
 The first technical board hasn't been elected yet.
 
+.. _committers:
+
 Committers
 ==========
 
@@ -17,6 +19,8 @@ Most :ref:`core team <core-team>` members have commit access. They're called
 
 Being part of the core team is a pre-requisite for having commit access.
 
+.. _security-team-list:
+
 Security team
 =============
 
@@ -35,6 +39,8 @@ The current security team members are:
 - Carl Meyer
 - Donald Stufft
 
+.. _releasers-list:
+
 Releasers
 =========
 

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

@@ -62,12 +62,10 @@ Journal-World`_ of Lawrence, Kansas, USA.
 The current team
 ================
 
-Currently, Django is led by a team of volunteers from around the globe.
-
 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