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

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