feat: modify RFC to eliminate fist person language

rfcs/012-merge-rebase-strategy.md

@@ -39,26 +39,24 @@ whilst giving contributors the ability to choose whatever method they prefer.
 
 ## Best Practice
 
-I feel there's no best practice on this matter but different workflows that are suitable for different teams.
+There's no best practice on this matter but different workflows that are suitable for different teams.
 For Open Collective projects only core team members are merging, and we cannot possibly enforce all the 
 community to interactively rebase Git history. Hence, currently we are mostly relying on squashing and merging. 
 
-However, given that enforcing interactive re-bases for all branches are impossible I would argue we need to enforce a standard
+However, given that enforcing interactive re-bases for all branches are impossible we need to enforce a standard
 on our end (when merging). Whether contributors use interactive re-basing or not, or if they choose to use simple merging, we could
 still have a cleaner Git history if we always make sure to squash and merge PRs. 
 
 ### Downside of this approach
 
 One downside is that when squashing and merging the person who merge needs to verify the commit title and description and make sure
 it makes sense. The GitHub interface automatically creates a commit description by concatenating all the commits in the branch. 
-Although I don't see this as a problem since even for an interactively re-based branch; while merging it's probably good practice
-to see if the commit(s) make sense. 
+Although this seems to work in most cases it's probably a good practice to see if the commit(s) make sense while merging. 
 
 ## Solution
 
-[Suggest disabling `Create a merge commit` from the GitHub settings](https://docs.github.com/en/github/administering-a-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests) 
-as it's probably not suitable for our use. Using that option always will create merge commits and we will not have 
-a clean Git history. We could possibly also disable `Rebase and merge` as well although I would argue leaving it in case someone would like to explicitly include
+[Disable `Create a merge commit` from the GitHub settings](https://docs.github.com/en/github/administering-a-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests) 
+as it's probably not suitable for use. Using that option will create merge commits and will prevent a clean Git history. Additionally, suggest also disabling `Rebase and merge` as well although it could be argued to leave it in case someone would like to explicitly include
 several commits to the `main` branch. The squash and merge option should work for us in all cases. 
 
 As an alternative or a stricter enforcement of this standard we can also add the [`Require linear history` branch protection rule