Fix typos and grammar mistakes.

wiki/src/contribute/merge_policy/review.mdwn

@@ -24,8 +24,8 @@
   maintenance includes: polishing the proposed changes to make them fit
   for release; writing and updating the design and end-user
   documentations; fixing bugs.
-- As reviewer, you are allowed to to trival checks e.g. {typos in,phrasing of}
-  comments and string on top of the proposed patch to avoid rountrips.
+- As reviewer, you are allowed to commit trivial fixes e.g. {typos in,phrasing of}
+  comments and strings on top of the proposed patch to avoid round-trips.
   You need to report back those changes.
 - Remember that it's hard to receive negative feedback. Don't forget
   to note the good parts, be constructive and precise in your

wiki/src/contribute/merge_policy/submit.mdwn

@@ -5,7 +5,7 @@ be named `feature/XXX`. For a bugfix about YYY, it should be named
 `bugfix/YYY`. Ideally, include the relevant ticket number in the topic
 branch name, e.g. `bugfix/7173-upgrade-syslinux`.
 
-When you think it is good enough and has tested it, you have to:
+When you think it is good enough and have tested it, you have to:
 
 - Set the ticket's *Status* field to *In Progress* (if you do not see
   this field when editing the ticket, ask the [[sysadmin team|contribute/working_together/roles/sysadmins]]
@@ -37,6 +37,6 @@ more dev* or *Needs more info* state, and
 from now on it's the responsibility of the branch/ticket "holder" to
 change it back to *Ready for QA* once they consider the issues raised by
 the reviewer are fixed. The reviewer is allowed to add trivial changes,
-e.g. {typos in,phrasing of} comments and string on top of the proposed patch
-to avoid roundtrips. But the reviewer needs to communicate those changes to
+e.g. {typos in,phrasing of} comments and strings on top of the proposed patch
+to avoid round-trips. But the reviewer needs to communicate those changes to
 the branch/ticket "holder".