Removed docs/internals/roles.txt.

It's moved to https://www.djangoproject.com/foundation/teams/.

docs/index.txt

@@ -339,7 +339,6 @@ you can contribute:
   :doc:`The release process <internals/release-process>` |
   :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/committing-code.txt

@@ -2,10 +2,9 @@
 Committing code
 ===============
 
-This section is addressed to the :ref:`committers` and to anyone interested in
+This section is addressed to the committers and to anyone interested in knowing
-knowing how code gets committed into Django core. If you're a community member
+how code gets committed into Django. If you're a community member who wants to
-who wants to contribute code to Django, have a look at
+contribute code to Django, look at :doc:`writing-code/working-with-git` instead.
-:doc:`writing-code/working-with-git` instead.
 
 .. _handling-pull-requests:
 

docs/internals/git.txt

@@ -242,8 +242,7 @@ branches, used for Google Summer of Code projects.
 Tags
 ====
 
-Each Django release is tagged and signed by a :ref:`releaser
+Each Django release is tagged and signed by the releaser.
-<releasers-list>`.
 
 The tags can be found on GitHub's `tags`_ page.
 

docs/internals/index.txt

@@ -12,7 +12,6 @@ you'd like to help improve Django or learn about how Django is managed.
    mailing-lists
    organization
    team
-   roles
    security
    release-process
    deprecation

docs/internals/organization.txt

@@ -162,9 +162,8 @@ capacity on non-technical decisions.
 Membership
 ----------
 
-The technical board is an elected group of five committers. They're expected
+`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
+to be experienced but there's no formal seniority requirement.
-composition is published :ref:`here <technical-board-list>`.
 
 A new board is elected after each feature release of Django. The election
 process is managed by a returns officer nominated by the outgoing technical
@@ -183,6 +182,8 @@ board. The election process works as follows:
 Both the application and the voting period last between one and two weeks, at
 the outgoing board's discretion.
 
+.. _the technical board: https://www.djangoproject.com/foundation/teams/#technical-board-team
+
 Changing the organization
 =========================
 

docs/internals/roles.txt

@@ -1,70 +0,0 @@
-=====
-Roles
-=====
-
-.. _technical-board-list:
-
-Technical board
-===============
-
-The technical board for the 1.11 release cycle is:
-
-* James Bennett
-* Andrew Godwin
-* Russell Keith-Magee
-* Carl Meyer
-* Marc Tamlyn
-
-.. _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
-- Tim Graham
-- Adrian Holovaty
-- Markus Holtermann
-- Paul McMillan
-- Carl Meyer
-
-.. _releasers-list:
-
-Releasers
-=========
-
-Releasers take care of :doc:`building Django releases
-</internals/howto-release-django>`.
-
-The current releasers are:
-
-- James Bennett
-- Jacob Kaplan-Moss
-- Tim Graham
-
-Ops team
-========
-
-The ops team maintains Django's infrastructure like the Django Project server,
-Trac instance, and continuous integration infrastructure.
-
-- Florian Apolloner
-- Tim Graham
-- Markus Holtermann
-- Jannis Leidel
-- Tobias McNulty

docs/internals/security.txt

@@ -23,9 +23,8 @@ publicly reported in this fashion.
 
 Instead, if you believe you've found something in Django which has security
 implications, please send a description of the issue via email to
-``security@djangoproject.com``. Mail sent to that address reaches a
+``security@djangoproject.com``. Mail sent to that address reaches the `securty
-:ref:`subset of the core team <security-team-list>`, who can forward security
+team <https://www.djangoproject.com/foundation/teams/#security-team>`_.
-issues into the private team's mailing list for broader discussion if needed.
 
 Once you've submitted an issue via email, you should receive an acknowledgment
 from a member of the security team within 48 hours, and depending on the
@@ -106,7 +105,7 @@ triaging our announcement and upgrade Django as needed. Severity levels are:
 Second, we notify a list of :ref:`people and organizations
 <security-notifications>`, primarily composed of operating-system vendors and
 other distributors of Django. This email is signed with the PGP key of someone
-from :ref:`Django's release team <releasers-list>` and consists of:
+from `Django's release team`_ and consists of:
 
 * A full description of the issue and the affected versions of Django.
 
@@ -150,6 +149,8 @@ theirs.
 The Django team also maintains an :doc:`archive of security issues
 disclosed in Django</releases/security>`.
 
+.. _Django's release team: https://www.djangoproject.com/foundation/teams/#releasers-team
+
 .. _security-notifications:
 
 Who receives advance notification