Process_Log.md

@@ -4,8 +4,12 @@ We regularly discuss process elements and decide on process changes. In order to
 
 ## On Merge Requests
 
-### Merge requests shall have a dedicated person in charge and two reviewers.
-Long-standing merge requests can bottleneck the entire process. Hence we assign one person in charge of the merge (different from the person issuing it). This person will a) act as the primary reviewer and b) be respoinsible to get the necessary reviews asap. Two additional reviewers should be assigned via the MR's comment section. These three people review and eventually close the merge request.
+### ~~Merge requests shall have a dedicated person in charge and two reviewers.~~
+~~Long-standing merge requests can bottleneck the entire process. Hence we assign one person in charge of the merge (different from the person issuing it). This person will a) act as the primary reviewer and b) be respoinsible to get the necessary reviews asap. Two additional reviewers should be assigned via the MR's comment section. These three people review and eventually close the merge request.~~
+
+* Everyone can :thumbsup: a Merge Request.
+* If you want a special person to review the MR, assign him/her. Otherwise don't assign anyone.
+* The 3rd :thumbsup: can merge the MR (if the potentially assigned Assignee also :thumbsup: ed it).
 
 ### Merge Requests and Milestones
 We tend to get bogged down by merge requests. As of today (21 Sept 2017), most of them are single-issue MRs. We should see to go "back" to the intended model of (roughly) having a merge request per functionality issue, i.e. per milestone. In essence, MRs should get a little bigger and less frequent.