[Contributing] consistent headlines

Author: xabbuh

contributing/code/bc.rst

@@ -1,4 +1,4 @@
-Our Backwards Compatibility Promise
+Our backwards Compatibility Promise
 ===================================
 
 Ensuring smooth upgrades of your projects is our first priority. That's why
@@ -39,7 +39,7 @@ If you are using Symfony in your projects, the following guidelines will help
 you to ensure smooth upgrades to all future minor releases of your Symfony
 version.
 
-Using Our Interfaces
+Using our Interfaces
 ~~~~~~~~~~~~~~~~~~~~
 
 All interfaces shipped with Symfony can be used in type hints. You can also call
@@ -101,7 +101,7 @@ backwards compatibility promise:
 
 .. include:: _api_tagging.rst.inc
 
-Using Our Classes
+Using our Classes
 ~~~~~~~~~~~~~~~~~
 
 All classes provided by Symfony may be instantiated and accessed through their

contributing/code/patches.rst

@@ -85,7 +85,7 @@ Get the Symfony2 source code:
       $ cd symfony
       $ git remote add upstream git://github.com./symfony/symfony.git
 
-Check that the current Tests pass
+Check that the current Tests Pass
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Now that Symfony2 is installed, check that all unit tests pass for your

contributing/community/releases.rst

@@ -123,8 +123,8 @@ This results in very predictable dates and maintenance periods:
     instance), you can automatically receive an email notification if you
     subscribed on the `roadmap notification`_ page.
 
-Backward Compatibility
-----------------------
+Backwards Compatibility
+-----------------------
 
 Our :doc:`Backwards Compatibility Promise </contributing/code/bc>` is very
 strict and allows developers to upgrade with confidence from one minor version

contributing/documentation/overview.rst

@@ -187,7 +187,7 @@ about in the :doc:`/contributing/community/releases` section.
 To keep up with the release process, the documentation team makes several
 changes to the documentation at various parts of the lifecycle.
 
-When a Release reaches "end of maintenance"
+When a Release Reaches "End of Maintenance"
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Every release will eventually reach its "end of maintenance". For details,
@@ -210,7 +210,7 @@ For this example, suppose version 2.1 has just reached its end of maintenance:
   *after* the end of maintenance of this branch), will have no mentions of
   the old version (e.g. 2.1).
 
-When a new Branch is created for a Release
+When a new Branch is Created for a Release
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 During the :ref:`stabilization phase <contributing-release-development>`, a