Fixed some tiny typos in docs/contributing.txt

git-svn-id: http://code.djangoproject.com/svn/django/trunk@1482 bcc190cf-cafb-0310-a4f2-bffc1f526a37

docs/contributing.txt

@@ -11,11 +11,11 @@ of the community, so there are many ways you can help Django's development:
       you'd like to see on that page.
 
     * Report bugs and request features in our `ticket tracker`_.  Please read
-      `reporting bugs`, below, for the details on how we like our bug reports
+      `Reporting bugs`_, below, for the details on how we like our bug reports
       served up.
 
-    * Submit patches for new and/or fixed behavior.  Please read the `submitting
+    * Submit patches for new and/or fixed behavior.  Please read `Submitting
-      patches`_, below, for the details on how to submit a patch.
+      patches`_, below, for details on how to submit a patch.
 
     * Join the `django-dev`_ mailing list and share your ideas for how to improve
       Django.  We're always open to suggestions, although we're likely to be skeptical
@@ -23,8 +23,8 @@ of the community, so there are many ways you can help Django's development:
 
 That's all you need to know if you'd like to join the Django development
 community. The rest of this document describes the details of how our community
-works and how it handles bugs, mailing lists, and all the other minutiae of how
+works and how it handles bugs, mailing lists, and all the other minutiae of
-Django development works.
+Django development.
 
 Reporting bugs
 ==============
@@ -43,7 +43,7 @@ particular:
 
     * **Do** write complete, reproducible, specific bug reports. Include as
       much information as you possibly can, complete with code snippets, test
-      cases, etc.  A minimal example the illustrates the bug in a nice small
+      cases, etc.  A minimal example that illustrates the bug in a nice small
       test case is the best possible bug report.
 
     * **Don't** use the ticket system to ask support questions.  Use the
@@ -57,7 +57,7 @@ particular:
       that the decision has been made that we can't or won't fix this particular
       issue.  If you're not sure why, please ask on `django-dev`_.
 
-    * **Don't** use the ticket tracker for lengthy discussions because they're
+    * **Don't** use the ticket tracker for lengthy discussions, because they're
       likely to get lost. If a particular ticket is controversial, please move
       discussion to `django-dev`_.
 
@@ -102,7 +102,7 @@ associated patches will get fixed *far* more quickly than those without patches.
 Patch style
 -----------
 
-    * Make sure your code matches our `coding style`.
+    * Make sure your code matches our `coding style`_.
 
     * Submit patches in the format returned by the ``svn diff`` command.
       An exception is for code changes that are described more clearly in plain
@@ -116,6 +116,10 @@ Patch style
     * Name the patch file with a ``.diff`` extension; this will let the ticket
       tracker apply correct syntax highlighting, which is quite helpful.
 
+    * Put the prefix "[patch] " before the title of your ticket. This will make
+      it obvious that the ticket includes a patch, and it will add the ticket
+      to the `list of tickets with patches`_.
+
 Coding style
 ============
 
@@ -134,11 +138,22 @@ Please follow these coding standards when writing code for inclusion in Django:
     * Mark all strings for internationalization; see the `i18n documentation`_
       for details.
 
+    * In Django template code, put one (and only one) space between the curly
+      brackets and the tag contents.
+
+      Do this::
+
+          {{ foo }}
+
+      Don't do this::
+
+          {{foo}}
+
 Requesting features
 ===================
 
-We're always trying to make Django better, and your feature requests make that
+We're always trying to make Django better, and your feature requests are a key
-possible. Here are some tips on how to most effectively make a request:
+part of that. Here are some tips on how to most effectively make a request:
 
     * Request the feature on `django-dev`_, not in the ticket tracker; it'll get
       read more closely if it's on the mailing list.
@@ -149,7 +164,7 @@ possible. Here are some tips on how to most effectively make a request:
 
     * Explain *why* you'd like the feature. In some cases this is obvious, but
       since Django is designed to help real developers get real work done,
-      you'll need to explain it if it isn't obvious why the feature would be
+      you'll need to explain it, if it isn't obvious why the feature would be
       useful.
 
 As with most open-source projects, code talks. If you are willing to write the
@@ -168,7 +183,7 @@ trunk at any time.
 Thus, large architectural changes -- that is, changes too large to be
 encapsulated in a single patch, or changes that need multiple eyes on them --
 will have dedicated branches. See, for example, the `i18n branch`_. If you
-have a change of this nature that you'd like to work on, ask on `django-dev` for
+have a change of this nature that you'd like to work on, ask on `django-dev`_ for
 a branch to be created for you. We'll create a branch for pretty much any kind of
 experimenting you'd like to do.
 
@@ -180,7 +195,7 @@ into the branch. Please merge at least once a week. Every time you merge from
 the trunk, note the merge and revision numbers in the commit message.
 
 Once the branch is stable and ready to be merged into the trunk, alert
-django-dev.
+`django-dev`_.
 
 After a branch has been merged, it should be considered "dead"; write access to
 it will be disabled, and old branches will be periodically "trimmed." To keep
@@ -196,7 +211,7 @@ use::
 
     svn switch http://code.djangoproject.com/svn/django/branches/<branch>/
 
-in the root of your Django sandbox (the directory that contains ``django``, 
+...in the root of your Django sandbox (the directory that contains ``django``,
 ``docs``, and ``tests``).
 
 Official releases
@@ -226,13 +241,17 @@ Django's release numbering works as follows:
       security fixes.  A new micro-release will always be 100%
       backwards-compatible with the previous micro-release.
 
-    * In some cases we'll make release candidate releases. These are of the
+    * In some cases, we'll make release candidate releases. These are of the
       form ``A.BrcN``, which means the ``Nth`` candidate release of version
       ``A.B``.
 
+An exception to this version numbering scheme is the pre-1.0 Django code.
+There's no guarantee of backwards-compatibility until the 1.0 release.
+
 In Subversion, each Django release will be tagged under `tags/releases`_.  If
 it's necessary to release a bug fix release or a security release that doesn't
-come from the trunk, we'll copy that tag to ``branches/releases`` to make the bug fix release.
+come from the trunk, we'll copy that tag to ``branches/releases`` to make the
+bug fix release.
 
 Deciding on features
 ====================
@@ -258,7 +277,7 @@ Although these votes on django-dev are informal, they'll be taken very
 seriously. After a suitable voting period, if an obvious consensus arises
 we'll follow the votes.
 
-However, consensus is not always possible.  Touch decisions will be discussed by
+However, consensus is not always possible.  Tough decisions will be discussed by
 all full committers and finally decided by the Benevolent Dictators for Life,
 Adrian and Jacob.
 
@@ -298,6 +317,7 @@ requests for commit access are potential flame-war starters, and will be ignored
 .. _search the tracker: http://code.djangoproject.com/search
 .. _django-users: http://groups.google.com/group/django-users
 .. _`#django`: irc://irc.freenode.net/django
+.. _list of tickets with patches: http://code.djangoproject.com/report/12
 .. _PEP 8: http://www.python.org/peps/pep-0008.html
 .. _i18n documentation: http://www.djangoproject.com/documentation/i18n/
 .. _i18n branch: http://code.djangoproject.com/browser/django/branches/i18n