Made standard not that strict

Author: wouterj

contributing/code.rst

@@ -4,9 +4,12 @@ Contributing
 The Symfony2 CMF team follows all the rules and guidelines of the core
 Symfony2 `development process`_.
 
-When creating Pull Requests, please follow the Symfony `Submitting a Patch`_ guidlines
-with the added requirement of our :doc:`pr_style_and_commits`.
+When creating Pull Requests, please follow the Symfony `Submitting a Patch`_ guidlines.
 
+.. tip::
+
+    See :doc:`pr_style_and_commits` for the commit conventions used by the
+    Symfony CMF team.
 
 Resources / Links
 -----------------

contributing/pr_style_and_commits.rst

@@ -1,19 +1,15 @@
-Pull request and commit requirements
-====================================
+Commit Conventions
+==================
 
-Pull requests
--------------
-
-The pull request body should adhere to the Symfony standard `as defined here`_
-
-Commits
--------
-
-Before a pull request is merged the commit should be squashed (i.e. there
-should be a single commit in the pull request with all of your work in it).
+The Symfony CMF uses a convention for the commits. This isn't a requirement
+when contributing to the CMF, but it is created to have meaningfull commits
+for big new features.
 
 Squashing
-~~~~~~~~~
+---------
+
+Before a Pull Request is merged, the commits should be squashed (i.e. there
+should be a single commit in the Pull Request with all your work in it).
 
 You can easily squash a commit using `git rebase` as follows:
 
@@ -32,32 +28,31 @@ like this:
 
 .. code-block:: bash
 
-    pick 608cc0f fix link to CoreBundle Documentation
-    pick be141b0 Correctly use Testing features
-    pick 6e2ebf5 Changed PHPunit config
-    pick c396b08 Changed travis config
+    pick 5d4530b port features from simple cms into routing bundle to simplify things
+    pick 1a0eea3 cs fixes and cleanups according to feedback
+    pick 8cbab56 convert settings to options
+    pick 8f3e4f9 cleanups for the options refactoring
 
 Tell github to pick the first one and squash the rest as follows:
 
 .. code-block:: bash
 
-    pick 608cc0f fix link to CoreBundle Documentation
-    s be141b0 Correctly use Testing features
-    s 6e2ebf5 Changed PHPunit config
-    s c396b08 Changed travis config
+    pick 5d4530b port features from simple cms into routing bundle to simplify things
+    s 1a0eea3 cs fixes and cleanups according to feedback
+    s 8cbab56 convert settings to options
+    s 8f3e4f9 cleanups for the options refactoring
 
 Save the file and quit. GIT should now squash all your commits and ask you
 for a new commit message.
 
 Commit Message
-~~~~~~~~~~~~~~
+--------------
 
 The commit message should be formatted as follows:
 
-.. code-block::
+.. code-block:: text
 
-    [<subject] <Short description>
-    ==============================
+    [<scope>] <short description>
 
     Fixes: <list of issues fixed>
 
@@ -73,12 +68,12 @@ The commit message should be formatted as follows:
 
     <list of deprecations>
 
-For example:
+For example, the commit message of a PR fixing 2 issues and adding 2 BC breaks
+would be:
 
-.. code-block::
+.. code-block:: text
 
     [Initializer] Initializers use ManagerRegistry
-    ==============================================
 
     Fixes: #1234, #4321
 
@@ -100,8 +95,16 @@ For example:
     - The first argument to the `GenericInitializer` constructor is now the
       name of the initializer.
 
-    Deprecations
-    ------------
+Short Commit Message
+~~~~~~~~~~~~~~~~~~~~
+
+Not all Pull Requests require this much information for the commit. In most
+cases, a more simpler commit convention is enough:
+
+.. code-block:: text
+
+    <bug|feature|minor> [<scope>] <short description>
 
-    This is just an example, there are no deprecations, but if there were
-    deprecations they sure would be listed here.
+Where ``bug`` refers to a commit fixing bugs, ``feature`` to a commit adding
+features and ``minor`` to commits adding less relevant things (fixing code
+standard, adding comments, fixing typos, etc.).