Updated contributing docs for some latest practices.

docs/internals/contributing/committing-code.txt

@@ -59,13 +59,9 @@ Once you're ready:
     $ # Delete the pull request branch.
     $ git branch -d pr/xxxx
 
-For changes on your own branches, force push to your fork after rebasing on
-master but before merging and pushing to upstream. This allows the commit
-hashes on master and your branch to match which automatically closes the pull
-request. Since you can't push to other contributors' branches, comment on the
-pull request "Merged in XXXXXXX" (replacing with the commit hash) after you
-merge it. Trac checks for this message format to indicate on the ticket page
-whether or not a pull request is merged.
+Force push to the branch after rebasing on master but before merging and
+pushing to upstream. This allows the commit hashes on master and the branch to
+match which automatically closes the pull request.
 
 If a pull request doesn't need to be merged as multiple commits, you can use
 GitHub's "Squash and merge" button on the website. Edit the commit message as
@@ -162,10 +158,6 @@ Django's Git repository:
   format will automatically close the referenced ticket and post a comment
   to it with the full commit message.
 
-  If your commit closes a ticket and is in a branch, use the branch name
-  first, then the "Fixed #xxxxx." For example:
-  "[1.4.x] Fixed #123 -- Added whizbang feature."
-
   For the curious, we're using a `Trac plugin`_ for this.
 
 .. note::
@@ -202,6 +194,14 @@ Django's Git repository:
   <https://code.djangoproject.com/wiki/CommitterTips#AutomatingBackports>`_
   to automate this.
 
+  If the commit fixes a regression, include this in the commit message:
+
+  .. code-block:: none
+
+    Regression in 6ecccad711b52f9273b1acb07a57d3f806e93928.
+
+  (use the commit hash where the regression was introduced).
+
 Reverting commits
 =================
 

docs/internals/contributing/writing-code/submitting-patches.txt

@@ -273,6 +273,10 @@ Bugs
 
 * Is there a proper regression test (the test should fail before the fix
   is applied)?
+* If it's a bug that :ref:`qualifies for a backport <supported-versions-policy>`
+  to the stable version of Django, is there a release note in
+  ``docs/releases/A.B.C.txt``? Bug fixes that will be applied only to the
+  master branch don't need a release note.
 
 New Features
 ------------

docs/internals/howto-release-django.txt

@@ -78,8 +78,8 @@ You'll need a few things before getting started:
 * If this is a security release, access to the pre-notification distribution
   list.
 
-If this is your first release, you'll need to coordinate with James and/or
-Jacob to get all these things lined up.
+If this is your first release, you'll need to coordinate with another releaser
+to get all these things lined up.
 
 Pre-release tasks
 =================
@@ -164,14 +164,14 @@ OK, this is the fun part, where we actually push out a release!
         $ git pull
 
 #. If this is a security release, merge the appropriate patches from
-   ``django-private``. Rebase these patches as necessary to make each one a
+   ``django-security``. Rebase these patches as necessary to make each one a
    simple commit on the release branch rather than a merge commit. To ensure
    this, merge them with the ``--ff-only`` flag; for example::
 
         $ git checkout stable/1.5.x
         $ git merge --ff-only security/1.5.x
 
-   (This assumes ``security/1.5.x`` is a branch in the ``django-private`` repo
+   (This assumes ``security/1.5.x`` is a branch in the ``django-security`` repo
    containing the necessary security patches for the next release in the 1.5
    series.)