We regularly discuss process elements and decide on process changes. In order to keep things lean, we briefly summarize resulting decisions and the gist of discussions here.
We regularly discuss process elements and decide on process changes. In order to keep things lean, we briefly summarize resulting decisions and the gist of discussions here.
## 2017-09-14
## 2017-09-14
### Merge requests shall have a dedicated person in charge and two reviewers
### 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.
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.
### Functionality and Discussion issues shall be accompanied by enough information to understand it without having the issuer explain it.
In order to keep meeting time within reasonable bounds, everything that requires discussion should be properly documented on gitlab. This can be done in plain markdown or by additional material such as sketches or a couple of slides. Keep in mind to keep this lean. The info should be enough to understand the issue at hand and no more. In addtion, everybody agrees to prepare for meetings by reading through issues which will be discussed in upcoming meetings.
