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
## 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 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.
### Code reviews & small changes
Do we just comment on issues found in code reviews or do we actively go out and fix minor things ourselves, although we are not technically in charge of the code at hand?
The recommendation here is to
* start a discussion in the code review
* offer help in doing the change that is recommended
* wait for the discussion to conclude
* decide who implements the change (the merge requester or the discussion opener)?
## On Issues
### Functionality and Discussion issues shall be accompanied by (just) 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.
## On Iterations
### Showing progress
Most agile or lean approaches make a big point of showing visible progress after every iteration. In our case that would mean to show something new in the viewer application everytime. We did not do this during the last week.
We approach this with a "middle-of-the-road" approach: we shall plan each iteration in a way that the iteration backlog includes some features that have a visible outcome at the end of the iteration. This might be visible in a demo or it might be a side by side comparison along the lines of: "Look, I've done this infrastructure bit and now the application developer has to write just these 10 lines as opposed to these 80 lines of code."
## Misc
### Use of boost
Although technically no process element, we decided for the conditional, limited use of boost (#100).
