@weex could you recommend anything particularly interesting from Pieter Hintjens that I could listen to/read?
I’ve worked once in such a team where we practiced what I call “post-integration code review” and enjoyed that culture very much. Later on tried to advocate for it but was unable to convince my managers to change practices except having one master branch instead of many long lived feature branches. They didn’t trust the developers and the argument was that we don’t have good enough tests (what, as I believe, was a consequence of the process and organization structure we had). I built CI pipeline but was unable to influence high level org structure, which was decided 5 levels of manages above me… at least I had the team on my side they knew how much everyone - and me in particular - struggled with the process we had.
In case you wanted to dig in that, the description of my desired development process at that time is here: Cloud discharge - Google Docs (point 1. in proposed solutions section), might be worth moving to separate document one day. Interestingly to what @weex you wrote about separating problem (discussed and worked on collaboratively) from solution (implementation, for devs a way of expressing themselves and a subject of individual craft) I wanted to create strong division between feature suppliers (business) and consumers (developers who implement them). It was an infrastructure heavy project that we worked on, cloud object storage, so the distinction of both was not strong, and I felt like people who do not understand code interfere with it way too much.
(post-integration code review)
It shifts ownership of quality from a tester to the developer.
Code review becomes more like having someone curious reading your code and sharing their thoughts than bug hunting as in traditional flow (hardcoded and promoted by github, btw). It focuses much more on internal code quality (structure and readability of the code) rather then correctness and not breaking-anything. It totally changes dynamics and ends up with better quality, wherever it started.
Devs don’t have to wait for approval to integrate their changes. They feel empowered to take ownership, and as I’ve seen have never been irresponsible. It’s not about seniority, even junior devs can assess the risk of their changes and if unsure, ask someone to give a look at the change before merging it. On the other side the responsibility of not braking anything that was already working is on the person who wrote the feature and did (or not) protect it with automated tests. Usually new code is behind some sort of feature flags anyways and not visible to users until it is decided to turn it on.
Not sure if it is adaptable to oss projects where people come and go, and there is no mechanizm that would convince them to write tests. Maybe if they started from writing tests for the features they work on? Practicing executable specification, expressed as tests. Hope to try it in the fedihospex project. The Definition of Done is already there