Few rewords

source/reviewprocess.rst

@@ -15,6 +15,6 @@ Here is the process you must follow when you are reviewing a PR.
 
   * If some new methods are added, or if the request made important changes in the code, you should ask the developer to write some more unit tests
 
-6. A PR can be merged back if two developers approved it, or if one developer approved it more than one day ago,
-7. A bugfix PR that has been merged into the `xx/bugfixes` branch must be reported on the `master` branch. If the `master` already contains many changes, you may have to change some code before doing this. f changes are consequent, maybe should you open a new PR against the `master` branch for it,
+6. A PR can be merged if two developers approved it, or if one developer approved it more than one day ago,
+7. A bugfix PR that has been merged into the `xx/bugfixes` branch must be reported on the `master` branch. If the `master` already contains many changes, you may have to change some code before doing this. If changes are consequent, maybe should you open a new PR against the `master` branch for it,
 8. Say thanks to the contributor :-)

source/sourcecode.rst

@@ -39,7 +39,7 @@ In a short form, here is the workflow we'll follow:
 * fork, create a specific branch, and hack
 * open a :abbr:`PR (Pull Request)`
 
-Each bug will be fixed in a branch that came from the correct `bugfixes` branch. Once merged back to the branch, developper must backport the fixes in the `master`; just with a simple cherry-pick for simple cases, or opening another pull request if changes are huge.
+Each bug will be fixed in a branch that came from the correct `bugfixes` branch. Once merged into the requested branch, developper must report the fixes in the `master`; with a simple cherry-pick for simple cases, or opening another pull request if changes are huge.
 
 Each feature will be hacked in a branch that came from `master`, and will be merged back to `master`.