Proof-read the new contributing guide.

Many thanks to Daniele Procida.

AUTHORS

@@ -425,6 +425,7 @@ answer newbie questions, and generally made Django that much better:
     polpak@yahoo.com
     Ross Poulton <ross@rossp.org>
     Mihai Preda <mihai_preda@yahoo.com>
+    Daniele Procida <daniele@vurt.org>
     Matthias Pronk <django@masida.nl>
     Jyrki Pulliainen <jyrki.pulliainen@gmail.com>
     Thejaswi Puthraya <thejaswi.puthraya@gmail.com>

docs/internals/contributing/committing-code.txt

@@ -21,7 +21,7 @@ Partial committers
     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
-    subframework to Django and wants to continue to maintain it.
+    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
@@ -30,26 +30,28 @@ Partial committers
 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 be ignored.
+flame-war starters, and will simply be ignored.
 
 Handling pull requests
 ----------------------
 
 Since Django is now hosted at GitHub, many patches are provided in the form of
-pull requests. When committing a pull request, make sure each individual
+pull requests.
-commit matches the commit guidelines described below. Contributors are
+
-expected to provide the best pull requests possible. However, in practice,
+When committing a pull request, make sure each individual commit matches the
-committers are more familiar with the commit guidelines, and they may have to
+commit guidelines described below. Contributors are expected to provide the
-rewrite the commit history.
+best pull requests possible. In practice however, committers - who will likely
+be more familiar with the commit guidelines - may decide to bring a commit up
+to standard themselves.
 
 Here is one way to commit a pull request::
 
     # Create a new branch tracking upstream/master -- upstream is assumed
     # to be django/django.
-    git checkout -b pull_xxxx upstream/master
+    git checkout -b pull_xxxxx upstream/master
 
     # Download the patches from github and apply them.
-    curl https://github.com/django/django/pull/XXXX.patch | git am
+    curl https://github.com/django/django/pull/xxxxx.patch | git am
 
 At this point, you can work on the code. Use ``git rebase -i`` and ``git
 commit --amend`` to make sure the commits have the expected level of quality.
@@ -59,20 +61,20 @@ Once you're ready::
     git checkout master
     git pull upstream master
     # Merge the work as "fast-forward" to master, to avoid a merge commit.
-    git merge --ff-only pull_xx
+    git merge --ff-only pull_xxxxx
     # Check that only the changes you expect will be pushed to upstream.
     git push --dry-run upstream master
     # Push!
     git push upstream master
 
-    # Get rid of the pull_xxxx branch.
+    # Get rid of the pull_xxxxx branch.
-    git branch -d pull_xxxx
+    git branch -d pull_xxxxx
 
-An alternative is to add the contributor's repository as a new remote, do a
+An alternative is to add the contributor's repository as a new remote,
-checkout of the branch and work from there::
+checkout the branch and work from there::
 
     git remote add <contributor> https://github.com/<contributor>/django.git
-    git checkout pull_xxxx <contributor> <contributor's pull request branch>
+    git checkout pull_xxxxx <contributor> <contributor's pull request branch>
 
 At this point, you can work on the code and continue as above.
 
@@ -151,7 +153,7 @@ Django's Git repository:
   review."
 
 * For commits to a branch, prefix the commit message with the branch name.
-  For example: "[1.4.x] Fixed #NNNNN -- Added support for mind reading."
+  For example: "[1.4.x] Fixed #xxxxx -- Added support for mind reading."
 
 * Limit commits to the most granular change that makes sense. This means,
   use frequent small commits rather than infrequent large commits. For
@@ -165,14 +167,14 @@ Django's Git repository:
   <backwards-compatibility-policy>`.
 
 * If your commit closes a ticket in the Django `ticket tracker`_, begin
-  your commit message with the text "Fixed #NNNNN", where "NNNNN" is the
+  your commit message with the text "Fixed #xxxxx", where "xxxxx" is the
   number of the ticket your commit fixes. Example: "Fixed #123 -- Added
   whizbang feature.". We've rigged Trac so that any commit message in that
   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 #NNNNN." For example:
+  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.
@@ -180,7 +182,7 @@ Django's Git repository:
   .. _Trac plugin: https://github.com/aaugustin/trac-github
 
 * If your commit references a ticket in the Django `ticket tracker`_ but
-  does *not* close the ticket, include the phrase "Refs #NNNNN", where "NNNNN"
+  does *not* close the ticket, include the phrase "Refs #xxxxx", where "xxxxx"
   is the number of the ticket your commit references. This will automatically
   post a comment to the appropriate ticket.
 
@@ -199,13 +201,14 @@ Django's Git repository:
 Reverting commits
 -----------------
 
-Nobody's perfect; mistakes will be committed. When a mistaken commit is
+Nobody's perfect; mistakes will be committed.
-discovered, please follow these guidelines:
 
-* Try very hard to ensure that mistakes don't happen. Just because we
+But try very hard to ensure that mistakes don't happen. Just because we have a
-  have a reversion policy doesn't relax your responsibility to aim for
+reversion policy doesn't relax your responsibility to aim for the highest
-  the highest quality possible. Really: double-check your work, or have
+quality possible. Really: double-check your work, or have it checked by
-  it checked by another committer, before you commit it in the first place!
+another committer, **before** you commit it in the first place!
+
+When a mistaken commit is discovered, please follow these guidelines:
 
 * If possible, have the original author revert his/her own commit.
 

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

@@ -20,9 +20,10 @@ See the :doc:`working-with-git` for more details on how to use pull requests.
 
 In an open-source project with hundreds of contributors around the world, it's
 important to manage communication efficiently so that work doesn't get
-duplicated and contributors can be as effective as possible. Hence, our policy
+duplicated and contributors can be as effective as possible.
-is for contributors to "claim" tickets in order to let other developers know
+
-that a particular bug or feature is being worked on.
+Hence, our policy is for contributors to "claim" tickets in order to let other
+developers know that a particular bug or feature is being worked on.
 
 If you have identified a contribution you want to make and you're capable of
 fixing it (as measured by your coding ability, knowledge of Django internals
@@ -68,18 +69,23 @@ no longer monopolized and somebody else can claim it.
 If you've claimed a ticket and it's taking a long time (days or weeks) to code,
 keep everybody updated by posting comments on the ticket. If you don't provide
 regular updates, and you don't respond to a request for a progress report,
-your claim on the ticket may be revoked. As always, more communication is
+your claim on the ticket may be revoked.
-better than less communication!
+
+As always, more communication is better than less communication!
 
 Which tickets should be claimed?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Of course, going through the steps of claiming tickets is overkill in some
-cases. In the case of small changes, such as typos in the documentation or
+cases.
+
+In the case of small changes, such as typos in the documentation or
 small bugs that will only take a few minutes to fix, you don't need to jump
 through the hoops of claiming tickets. Just submit your patch and be done with
-it. Of course, it is always acceptable, regardless of the ticket's ownership
+it.
-status, to submit patches to a ticket if you happen to have a patch ready.
+
+Of course, it is *always* acceptable, regardless whether someone has claimed it
+or not, to submit patches to a ticket if you happen to have a patch ready.
 
 .. _patch-style:
 
@@ -90,12 +96,12 @@ Make sure that any contribution you do fulfills at least the following
 requirements:
 
 * The code required to fix a problem or add a feature is an essential part
-  of a patch, but it is not the only part. A good patch should also
+  of a patch, but it is not the only part. A good patch should also include a
-  include a regression test to validate the behavior that has been fixed
+  :doc:`regression test <unit-tests>` to validate the behavior that has been
-  and to prevent the problem from arising again. Also, if some tickets are
+  fixed and to prevent the problem from arising again. Also, if some tickets
-  relevant to the code that you've written, mention the ticket numbers in
+  are relevant to the code that you've written, mention the ticket numbers in
   some comments in the test so that one can easily trace back the relevant
-  discussions after your patch gets committed and the tickets get closed.
+  discussions after your patch gets committed, and the tickets get closed.
 
 * If the code associated with a patch adds a new feature, or modifies
   behavior of an existing feature, the patch should also contain
@@ -105,6 +111,7 @@ You can use either GitHub branches and pull requests or direct patches
 to publish your work. If you use the Git workflow, then you should
 announce your branch in the ticket by including a link to your branch.
 When you think your work is ready to be merged in create a pull request.
+
 See the :doc:`working-with-git` documentation for mode details.
 
 You can also use patches in Trac. When using this style, follow these
@@ -139,8 +146,10 @@ A "non-trivial" patch is one that is more than a simple bug fix. It's a patch
 that introduces Django functionality and makes some sort of design decision.
 
 If you provide a non-trivial patch, include evidence that alternatives have
-been discussed on `django-developers`_. If you're not sure whether your patch
+been discussed on `django-developers`_.
-should be considered non-trivial, just ask.
+
+If you're not sure whether your patch should be considered non-trivial, just
+ask.
 
 Javascript patches
 ------------------
@@ -156,6 +165,9 @@ code for future development (e.g. ``foo.js``), and a compressed version for
 production use (e.g. ``foo.min.js``). Any links to the file in the codebase
 should point to the compressed version.
 
+Compressing JavaScript
+~~~~~~~~~~~~~~~~~~~~~~
+
 To simplify the process of providing optimized javascript code, Django
 includes a handy script which should be used to create a "minified" version.
 This script is located at ``django/contrib/admin/static/js/compress.py``.
@@ -167,11 +179,11 @@ complete javascript patches will need to download and install the library
 independently.
 
 The Closure Compiler library requires Java version 6 or higher (Java 1.6 or
-higher on Mac OS X). Note that Mac OS X 10.5 and earlier did not ship with
+higher on Mac OS X. Note that Mac OS X 10.5 and earlier did not ship with
 Java 1.6 by default, so it may be necessary to upgrade your Java installation
 before the tool will be functional. Also note that even after upgrading Java,
 the default ``/usr/bin/java`` command may remain linked to the previous Java
-binary, so relinking that command may be necessary as well.
+binary, so relinking that command may be necessary as well.)
 
 Please don't forget to run ``compress.py`` and include the ``diff`` of the
 minified scripts when submitting patches for Django's javascript.

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

@@ -11,18 +11,20 @@ that you also work using GitHub.
 After installing Git the first thing you should do is setup your name and
 email::
 
-  $ git config --global user.name "Firstname Lastname"
+  $ git config --global user.name "Your Real Name"
-  $ git config --global user.email "your_email@youremail.com"
+  $ git config --global user.email "you@email.com"
 
 Note that ``user.name`` should be your real name, not your GitHub nick. GitHub
 should know the email you use in the ``user.email`` field, as this will be
 used to associate your commits with your GitHub account.
 
 Now 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
+changes for Trac ticket #xxxxx. By creating a fully-ready pull request you
-will make the committers' job easier, and thus your work is more likely to be
+will make the committers' job easier, meaning that your work is more likely to
-merged into Django. You can also upload a traditional patch to Trac, but it's
+be merged into Django.
-less practical for reviews.
+
+You could also upload a traditional patch to Trac, but it's less practical for
+reviews.
 
 .. _Git: http://git-scm.com/
 .. _GitHub: https://github.com/
@@ -31,14 +33,18 @@ less practical for reviews.
 Setting up local repository
 ---------------------------
 
-When you have created a GitHub account, with the nick "github_nick", and
+When you have created your GitHub account, with the nick "github_nick", and
-forked Django's repository, you should create a local copy of your fork::
+forked Django's repository, create a local copy of your fork::
 
     git clone git@github.com:github_nick/django.git
 
-This will create a new directory "django" containing a clone of your GitHub
+This will create a new directory "django", containing a clone of your GitHub
-repository. Your GitHub repository will be called "origin" in Git. You should
+repository.
-also setup django/django as an "upstream" remote::
+
+Your GitHub repository will be called "origin" in Git.
+
+You should also setup django/django as an "upstream" remote (that is, tell git
+that the reference Django repository was the source of your fork of it)::
 
     git remote add upstream git@github.com:django/django.git
     git fetch upstream
@@ -50,12 +56,15 @@ You can add other remotes similarly, for example::
 Working on a ticket
 -------------------
 
-When working on a ticket you will almost always want to create a new branch
+When working on a ticket create a new branch for the work, and base that work
-for the work, and base that work on upstream/master::
+on upstream/master::
 
     git checkout -b ticket_xxxxx upstream/master
 
-If you are working for a fix on the 1.4 branch, you would instead do::
+The -b flag creates a new branch for you locally. Don't hesitate to create new
+branches even for the smallest things - that's what they are there for.
+
+If instead you were working for a fix on the 1.4 branch, you would do::
 
     git checkout -b ticket_xxxxx_1_4 upstream/stable/1.4.x
 
@@ -64,7 +73,7 @@ commit them::
 
     git commit
 
-When writing the commit message, you should follow the :ref:`commit message
+When writing the commit message, follow the :ref:`commit message
 guidelines <committing-guidlines>` to ease the work of the committer. If
 you're uncomfortable with English, try at least to describe precisely what the
 commit does.
@@ -77,69 +86,77 @@ necessary::
 Publishing work
 ~~~~~~~~~~~~~~~
 
-You can publish your work on GitHub by just using::
+You can publish your work on GitHub just by doing::
 
   git push origin ticket_xxxxx
 
 When you go to your GitHub page you will notice a new branch has been created.
+
 If you are working on a Trac ticket, you should mention in the ticket that
 your work is available from branch ticket_xxxxx of your github repo. Include a
 link to your branch.
 
-Note that the above branch is called a "topic branch" in Git parlance. This
+Note that the above branch is called a "topic branch" in Git parlance. You are
-means that other people should not base their work on your branch. In
+free to rewrite the history of this branch, by using ``git rebase`` for
-particular this means you are free to rewrite the history of this branch (by
+example. Other people shouldn't base their work on such a branch, because
-using ``git rebase`` for example). There are also "public branches". These are
+their clone would become corrupt when you edit commits.
-branches other people are supposed to fork, and thus their history should
+
-never change. Good examples of public branches are the ``master`` and
+There are also "public branches". These are branches other people are supposed
-``stable/A.B.x`` branches in the django/django repository.
+to fork, so the history of these branches should never change. Good examples
+of public branches are the ``master`` and ``stable/A.B.x`` branches in the
+django/django repository.
 
 When you think your work is ready to be pulled into Django, you should create
-a pull request at GitHub. A good pull request contains:
+a pull request at GitHub. A good pull request means:
 
-* Commits with one logical change in each, following the
+* commits with one logical change in each, following the
-  :doc:`coding style <coding-style>`.
+  :doc:`coding style <coding-style>`,
 
-* Well formed messages for each commit: a summary line and then paragraphs
+* well-formed messages for each commit: a summary line and then paragraphs
-  wrapped at 72 characters thereafter. See the :ref:`committing guidelines
+  wrapped at 72 characters thereafter -- see the :ref:`committing guidelines
-  <committing-guidlines>` for more details.
+  <committing-guidlines>` for more details,
 
-* Documentation and tests, if needed. Actually tests are always needed, except
+* documentation and tests, if needed -- actually tests are always needed,
-  for documentation changes.
+  except for documentation changes.
 
-* The test suite passes and the documentation builds without warnings.
+The test suite must pass and the documentation must build without warnings.
 
 Once you have created your pull request, you should add a comment in the
-related Trac ticket explaining what you've done. In particular you should tell
+related Trac ticket explaining what you've done. In particular you should note
-in which environment you've run the tests, for instance: "all tests pass under
+the environment in which you ran the tests, for instance: "all tests pass
-SQLite and MySQL".
+under SQLite and MySQL".
 
-Your pull request should be ready for merging into Django. Pull requests at
+Pull requests at GitHub have only two states: open and closed. The committer
-GitHub have only two states: open and closed. The committers who deals with
+who will deal with your pull request has only two options: merge it or close
-your pull request has only two options: merge it or close it. For this reason,
+it. For this reason, it isn't useful to make a pull request until the code is
-it isn't useful to make a pull request until the code is ready for merging --
+ready for merging -- or sufficiently close that a committer will finish it
-or sufficiently close that a committer will finish it himself.
+himself.
 
 Rebasing branches
 ~~~~~~~~~~~~~~~~~
 
 In the example above you created two commits, the "Fixed ticket_xxxxx" commit
-and "Added two more tests" commit. We do not want to have the "Added two more
+and "Added two more tests" commit.
-tests" commit in the Django's repository as it would just be useless noise.
+
-Instead, we would like to only have one commit. To rework the history of your
+We do not want to have the entire history of your working process in your
-branch you can squash the commits into one by using interactive rebase::
+repository. Your commit "Added two more tests" would be unhelpful noise.
+Instead, we would rather only have one commit containing all your work.
+
+To rework the history of your branch you can squash the commits into one by
+using interactive rebase::
 
     git rebase -i HEAD~2
 
 The HEAD~2 above is shorthand for two latest commits. The above command
 will open an editor showing the two commits, prefixed with the word "pick".
-You should change the second line to "squash" instead. This will keep the
+
-first commit, and squash the second commit to the first one. Save and quit
+Change the second line to "squash" instead. This will keep the
-the editor. A second editor window should open. Here you can reword the
+first commit, and squash the second commit into the first one. Save and quit
-commit message for the commit.
+the editor. A second editor window should open, so you can reword the
+commit message for the commit now that it includes both your steps.
 
 You can also use the "edit" option in rebase. This way you can change a single
-commit. For example::
+commit, for example to fix a typo in a docstring::
 
     git rebase -i HEAD~3
     # Choose edit, pick, pick for the commits
@@ -148,17 +165,18 @@ commit. For example::
     git commit --amend
     # reword the commit message if needed
     git rebase --continue
-    # The second and third commit should be applied.
+    # The second and third commits should be applied.
 
-If you need to change an already published topic branch at GitHub, you will
+If your topic branch is already published at GitHub, for example if you're
-need to force-push the changes::
+making minor changes to take into account a review, you will need to force-
+push the changes::
 
     git push -f origin ticket_xxxxx
 
 Note that this will rewrite history of ticket_xxxxx - if you check the commit
 hashes before and after the operation at GitHub you will notice that the
-commit hashes do not match any more. This is acceptable, as the branch is topic
+commit hashes do not match any more. This is acceptable, as the branch is merely
-branch, and nobody should be basing their work on this branch.
+a topic branch, and nobody should be basing their work on it.
 
 After upstream has changed
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -173,16 +191,18 @@ The work is automatically rebased using the branch you forked on, in the
 example case using upstream/master.
 
 The rebase command removes all your local commits temporarily, applies the
-upstream commits, and then applies your local commits again on the work. If
+upstream commits, and then applies your local commits again on the work.
-there are merge conflicts you will need to resolve them and then use ``git
+
+If there are merge conflicts you will need to resolve them and then use ``git
 rebase --continue``. At any point you can use ``git rebase --abort`` to return
 to the original state.
 
-Note that you want to rebase on upstream, not merge the upstream. The reason
+Note that you want to *rebase* on upstream, not *merge* the upstream.
-for this is that by rebasing, your commits will always be on top of the
+
-upstream's work, not mixed with the changes in the upstream. This way your
+The reason for this is that by rebasing, your commits will always be *on
-branch only contains commits related to its topic, and this makes squashing
+top of* the upstream's work, not *mixed in with* the changes in the upstream.
-easier.
+This way your branch will contain only commits related to its topic, which
+makes squashing easier.
 
 After review
 ------------
@@ -190,31 +210,35 @@ After review
 It is unusual to get any non-trivial amount of code into core without changes
 requested by reviewers. In this case, it is often a good idea to add the
 changes as one incremental commit to your work. This allows the reviewer to
-easily check what changes you have done::
+easily check what changes you have done.
+
+In this case, do the changes required by the reviewer. Commit as often as
+necessary. Before publishing the changes, rebase your work. If you added two
+commits, you would run::
 
-  # Do changes required by the reviewer, commit often.
-  # Before publishing the changes, rebase your work. Assume you added two
-  # commits to the work.
     git rebase -i HEAD~2
-  # squash the second commit into the first, write a commit message something
-  # like this:
-  Made changes asked in review by the_reviewer
 
-    - Fixed whitespace errors in foo/bar
+Squash the second commit into the first. Write a commit message along the lines of::
-    - Reworded the doc string of the_method()
+
+    Made changes asked in review by <reviewer>
+
+    - Fixed whitespace errors in foobar
+    - Reworded the docstring of bar()
+
+Finally push your work back to your GitHub repository. Since you didn't touch
+the public commits during the rebase, you should not need to force-push::
 
-  # Push your work back to your github repo, there should not be any need
-  # for force (-f) push, as you didn't touch the public commits in the rebase.
     git push origin ticket_xxxxx
-  # Check your pull request, it should now contain the new commit, too.
 
-The committer is likely to squash the review commit into the previous commit
+Your pull request should now contain the new commit too.
+
+Note that the committer is likely to squash the review commit into the previous commit
 when committing the code.
 
 Summary
 -------
 
-* Work on GitHub if possible.
+* Work on GitHub if you can.
 * Announce your work on the Trac ticket by linking to your GitHub branch.
 * When you have something ready, make a pull request.
 * Make your pull requests as good as you can.

docs/internals/git.txt

@@ -4,10 +4,13 @@ The Django source code repository
 
 When deploying a Django application into a real production environment, you
 will almost always want to use `an official packaged release of Django`_.
+
 However, if you'd like to try out in-development code from an upcoming release
 or contribute to the development of Django, you'll need to obtain a clone of
-Django's source code repository. This document covers the way the code
+Django's source code repository.
-repository is laid out and how to work with and find things in it.
+
+This document covers the way the code repository is laid out and how to work
+with and find things in it.
 
 .. _an official packaged release of Django: https://www.djangoproject.com/download/
 
@@ -17,12 +20,14 @@ High-level overview
 The Django source code repository uses `Git`_ to track changes to the code
 over time, so you'll need a copy of the Git client (a program called ``git``)
 on your computer, and you'll want to familiarize yourself with the basics of
-how Git works. Git's web site offers downloads for various operating systems.
+how Git works.
-The site contains also vast amounts of `documentation`_.
+
+Git's web site offers downloads for various operating systems. The site also
+contains vast amounts of `documentation`_.
 
 The Django Git repository is located online at `github.com/django/django
-<https://github.com/django/django>`_. It contains the full source
+<https://github.com/django/django>`_. It contains the full source code for all
-code for all Django releases, and you can browse it online.
+Django releases, which you can browse online.
 
 The Git repository includes several `branches`_:
 
@@ -39,11 +44,10 @@ The Git repository includes several `branches`_:
 * ``attic/<project>`` branches were used to develop major or experimental new
   features without affecting the rest of Django's code.
 
-The Git repository also contains `tags`_. They identify snapshots of Django's
+The Git repository also contains `tags`_. These are the exact revisions from
-code at various important points in its history. Mostly these are the exact
+which packaged Django releases were produced, since version 1.0.
-revisions from which packaged Django releases were produced.
 
-The source code for `Djangoproject.com <https://www.djangoproject.com/>`_ Web
+The source code for the `Djangoproject.com <https://www.djangoproject.com/>`_ web
 site can be found at `github.com/django/djangoproject.com
 <https://github.com/django/djangoproject.com>`_.
 
@@ -52,8 +56,8 @@ site can be found at `github.com/django/djangoproject.com
 .. _branches: https://github.com/django/django/branches
 .. _tags: https://github.com/django/django/tags
 
-Working with Django's master branch
+The master branch
-===================================
+=================
 
 If you'd like to try out the in-development code for the next release of
 Django, or if you'd like to contribute to Django by fixing bugs or developing
@@ -76,15 +80,15 @@ over to :doc:`the documentation for contributing to Django
 </internals/contributing/index>`, which covers things like the preferred
 coding style and how to generate and submit a patch.
 
-Branches
+Other branches
-========
+==============
 
 Django uses branches for two main purposes:
 
 1. Development of major or experimental features, to keep them from
    affecting progress on other work in master.
 
-2. Security and bug-fix support for older releases of Django, during
+2. Security and bugfix support for older releases of Django, during
    their support lifetimes.
 
 Feature-development branches
@@ -154,9 +158,10 @@ part of Django itself, and so are no longer separately maintained:
 
 When Django moved from SVN to Git, the information about branch merges wasn't
 preserved in the source code repository. This means that the ``master`` branch
-of Django doesn't contain merge commits for the above branches. However, this
+of Django doesn't contain merge commits for the above branches.
-information is `available as a grafts file`_. You can restore it by putting
+
-the following lines in ``.git/info/grafts`` in your local clone::
+However, this information is `available as a grafts file`_. You can restore it
+by putting the following lines in ``.git/info/grafts`` in your local clone::
 
   ac64e91a0cadc57f4bc5cd5d66955832320ca7a1 553a20075e6991e7a60baee51ea68c8adc520d9a 0cb8e31823b2e9f05c4ae868c19f5f38e78a5f2e
   79e68c225b926302ebb29c808dda8afa49856f5c d0f57e7c7385a112cb9e19d314352fc5ed5b0747 aa239e3e5405933af6a29dac3cf587b59a099927
@@ -202,15 +207,18 @@ Support and bugfix branches
 ---------------------------
 
 In addition to fixing bugs in current master, the Django project provides
-official bug-fix support for the most recent released version of Django, and
+official bugfix support for the most recent released version of Django, and
-security support for the two most recently-released versions of Django. This
+security support for the two most recently-released versions of Django.
-support is provided via branches in which the necessary bug or security fixes
+
-are applied; the branches are then used as the basis for issuing bugfix or
+This support is provided via branches in which the necessary bug or security
-security releases.
+fixes are applied; the branches are then used as the basis for issuing bugfix
+or security releases.
 
 These branches can be found in the repository as ``stable/A.B.x``
 branches, and new branches will be created there after each new Django
-release. For example, shortly after the release of Django 1.0, the branch
+release.
+
+For example, shortly after the release of Django 1.0, the branch
 ``stable/1.0.x`` was created to receive bug fixes, and shortly after the
 release of Django 1.1 the branch ``stable/1.1.x`` was created.
 
@@ -222,7 +230,7 @@ used them to provide unofficial support for old Django releases.
 Tags
 ====
 
-Each Django release is tagged and signed by Django's release manage.
+Each Django release is tagged and signed by Django's release manager.
 
 The tags can be found on GitHub's `tags`_ page.
 

docs/internals/release-process.txt

@@ -198,15 +198,15 @@ and an rc complete with string freeze two weeks before the end of the schedule.
 Bug-fix releases
 ----------------
 
-After a minor release (e.g. 1.1), the previous release will go into bug-fix
+After a minor release (e.g. 1.1), the previous release will go into bugfix
 mode.
 
 A branch will be created of the form ``branches/releases/1.0.X`` to track
-bug-fixes to the previous release. Critical bugs fixed on trunk must
+bugfixes to the previous release. Critical bugs fixed on trunk must
-*also* be fixed on the bug-fix branch; this means that commits need to cleanly
+*also* be fixed on the bugfix branch; this means that commits need to cleanly
 separate bug fixes from feature additions. The developer who commits a fix to
-trunk will be responsible for also applying the fix to the current bug-fix
+trunk will be responsible for also applying the fix to the current bugfix
-branch.  Each bug-fix branch will have a maintainer who will work with the
+branch.  Each bugfix branch will have a maintainer who will work with the
 committers to keep them honest on backporting bug fixes.
 
 How this all fits together

docs/releases/1.0-beta-2.txt

@@ -69,7 +69,7 @@ the remaining features to be implemented for Django 1.0, and on the
 bugs that need to be resolved before the final release. As of this
 beta release, Django is in its final "feature freeze" for 1.0; feature
 requests will be deferred to later releases, and the development
-effort will be focused solely on bug-fixing and stability. Django is
+effort will be focused solely on bugfixing and stability. Django is
 also now in a "string freeze"; translatable strings (labels, error
 messages, etc.) in Django's codebase will not be changed prior to the
 release, in order to allow our translators to produce the final 1.0

docs/releases/1.3.txt

@@ -830,7 +830,7 @@ now pending deprecation.
 ~~~~~~~~~~~~~~~~
 
 Previously, ``django.http`` exposed an undocumented ``CompatCookie`` class,
-which was a bug-fix wrapper around the standard library ``SimpleCookie``. As the
+which was a bugfix wrapper around the standard library ``SimpleCookie``. As the
 fixes are moving upstream, this is now deprecated - you should use ``from
 django.http import SimpleCookie`` instead.