Write new CONTRIBUTING.md (#11)

CONTRIBUTING.md

@@ -2,10 +2,10 @@
 Thank you for considering to contribute to this repository! This file will walk you through all the steps to ensure both
 you and I have a good time submitting and reviewing your contribution. First off, some basic rules and reading material:
 
-- Submit your work in a new branch and make the PR to the `main` branch.
+- Be nice.
 - [Write a short & descriptive commit message](http://chris.beams.io/posts/git-commit/).
-- Rebase before committing the final change.
-- Stick to [PSR-2](http://www.php-fig.org/psr/psr-2/).
+- Rebase before pushing the final change.
+- Stick to [PSR-12](http://www.php-fig.org/psr/psr-12/).
 - Add tests if necessary and ensure all the tests are green on the final commit.
 - Make sure the CI tools used by the repository are all in order. If one fails, you should make it pass.
 
@@ -15,7 +15,7 @@ Here are the steps to follow to contribute to this repository:
 - [Fork this repository on GitHub](#fork-this-repository).
 - [Clone your fork to your local machine](#clone-your-fork).
 - [Create a feature branch](#create-a-branch).
-- [Add an 'upstream' remote](#add-a-remote).
+- [Add an `upstream` remote](#add-a-remote).
 - [Regularly pull & rebase from the upstream remote](#pull-and-rebase).
 - [Work on feature branch](#working-on-branch).
 - [Make tests pass](#make-tests-pass)
@@ -36,15 +36,27 @@ $ git clone https://github.com/<USERNAME>/<REPOSITORY>.git
 $ cd <REPOSITORY>
 ```
 
+### Determine what branch to target
+If your pull request contains a _feature_, it should be submitted to the latest version branch. Say the latest version
+is `v2.3.8`, **you should target your pull request to the `2.x` branch**. 
+
+If your pull request contains a _bug fix_, target it to the earliest version that bug is present in. So if version 
+`v1.2.0` introduced a bug, **submit the bug fix to the `1.x` branch**, even if `v2.0.0` is already out. If you're not sure,
+target the latest version (`2.x`, in case of this example).
+
+I go into detail about this in [my blog post](https://svenluijten.com/posts/tagging-and-branching-strategy-for-libraries-and-packages).
+
 ### Create a branch
-Make your own feature branch in order not to clutter up `main`.
+Make your own feature branch in order not to clutter up the target branch.
 
 ```bash
+$ git switch <TARGET_BRANCH>
+$ git pull origin <TARGET_BRANCH>
 # Think of a good name for your branch:
 #   fix/typo-in-readme
 #   feature/some-feature
 #   bug/some-bug-you-are-fixing
-$ git checkout -b <BRANCH_NAME>
+$ git switch -c <BRANCH_NAME>
 ```
 
 ### Add a remote
@@ -74,7 +86,7 @@ Pull from upstream to stay up to date with what others might be doing in this re
 are your responsibility to resolve.
 
 ```bash
-$ git pull --rebase upstream main
+$ git pull --rebase upstream <TARGET_BRANCH>
 ```
 
 ### Working on branch