Update Contributing Guide (#6118)

* Update Contributing Guide

* update docs

.github/CONTRIBUTING.md

@@ -237,7 +237,7 @@ We welcome any useful contribution! For your convenience here's a recommended wo
 
 #### How can I help/contribute?
 
-All types of contributions are welcome - reporting bugs, fixing documentation, adding test cases, solving issues, and preparing bug fixes. 
+All types of contributions are welcome - reporting bugs, fixing documentation, adding test cases, solving issues, and preparing bug fixes.
 To get started with code contributions, look for issues marked with the label [good first issue](https://github.com/PyTorchLightning/pytorch-lightning/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) or chose something close to your domain with the label [help wanted](https://github.com/PyTorchLightning/pytorch-lightning/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22). Before coding, make sure that the issue description is clear and comment on the issue so that we can assign it to you (or simply self-assign if you can).
 
 #### Is there a recommendation for branch names?
@@ -323,14 +323,6 @@ run our/your test with
 python -m pytest tests/..../...py::test_explain_what_is_being_tested --verbose --capture=no
 ```
 
-#### How to contribute bugfixes/features?
-
-Currently we have separate streams/branches for bugfixes/features and release from the default branch (`master`).
-Bugfixes should land in this `master` branch and features should land in `release/X.y-dev`.
-This means that when starting your contribution and creating a branch according to question 2) you should start this new branch from master or future release dev branch.
-Later in PR creation also pay attention to properly set the target branch, usually the starting (base) and target branch are the same.
-
-_Note, that this flow may change after the 1.2 release as we will adjust releasing strategy._
 
 #### How to fix PR with mixed base and target branches?
 
@@ -339,7 +331,7 @@ Do not panic, the solution is very straightforward and quite simple.
 All you need to do are these two steps in arbitrary order:
    - Ask someone from Core to change the base/target branch to the correct one
    - Rebase or cherry-pick your commits onto the correct base branch...
-     
+
 Let's show how to deal with the git...
 the sample case is moving a PR from `master` to `release/1.2-dev` assuming my branch name is `my-branch`
 and the last true master commit is `ccc111` and your first commit is `mmm222`.
@@ -354,7 +346,7 @@ and the last true master commit is `ccc111` and your first commit is `mmm222`.
      #  so open one and cherry-pick your last commits from `my-branch-backup`
      #  resolve all eventual conflict as the new base may contain different code
      # when all done, push back to the open PR
-     git push -f 
+     git push -f
      ```
    * **Rebasing way**, see more about [rebase onto usage](https://womanonrails.com/git-rebase-onto)
      ```bash