@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.
How is it different?
(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
I’ll respond to the rest of your comment when I have more time but this is the best resource I’ve found from Hintjens so far. 6. The ZeroMQ Community | ØMQ - The Guide
Unfortunately I also have this experience with some team processes being better than others. I took a look at your doc and see a lot of similarities between where you were trying to go and this Hintjens/C4 approach.
I’m jazzed about Hintjens work because he’s the first I’ve seen to flesh out and test a top-level protocol for free software development. The best I’d found before was more focused on the why rather than how.
The next step after digesting that guide and reading the C4 spec is that I want to try this whole approach out with a project. It might start by forking something that exists or creating something new. In the guide, Hintjens recommends starting with a crazy and simple goal. I came to this entire space with the desire to improve FOSS social networking perhaps through a scientific approach and am trying to put that impetus into crazy/simple terms.
If you’d like help applying this C4 process to your fedihospex project, I’d definitely be interested to contribute. I have zero experience with hospitality/hostels but I’m sure there’ll be plenty of opportunities to help on the organization/protocol side.
Thanks for sharing! I read it and liked very much. It’s pretty close to what one of my teams did, it was around 2012/13 that I joined that team so I wander if our tech lead new about it.
There were slight differences, we didn’t have branches (same as C4) nor used forks (different), we were pushing and rebasing directly to/on master. It was quite big team of ~30 devs and grew to ~50 working on the same codebase so by integrating often we could avoid conflicts and rework later. We also had pre-commit hook that run sanity checks on the patch before it was accepted to the master.
The other new thing to me is putting features and bugs to one box of issues presented as problem + solution. I’m used to have one backlog for them, but features were usually expressed as user stories with acceptance criteria etc and bugs are bugs. In fedihospex we have “ideas” bin so far, prioritized by user votes. Maybe both approaches are not contradictory though. I am curious to try it out, and rewrite everything to open problems.
The idea actually came from Hospitality Exchange which has little to do with hostels. It’s a network of people who welcome strangers to their homes, and travelers who need to stay somewhere at night and share their stories with the hosts. Bicycle touring community had a platform (160K users dispersed worldwide) built by the community whose board started to make money on the community recently. At first the source code of the server was closed (2015), people who disagreed with the board decisions were silenced (removed accounts) and now new members have to pay to join the community and to use the app (which for many regions with little infrastructure is the only option but not affordable at the price it is). I was contributor to the old, community built WarmShowers android app first released in 2012, which had 55K installs ever since, and which was called a security threat at the beginning of the year when the board released new, payed app and urged everyone to switch to it.
Could it be: Reclaiming hospitality from exchange platforms back to human interactions. ?
(which seems to me true but kind of too aggressive)
Here is some more background and sources of inspiration to form a better crazy, beautiful and easy goal:
a message that we display to the users of our app (currently 20K devices): https://warmshowers.bike
they knew how much everyone - and me in particular - struggled with the process we had.