The Collective Code Construction Contract (C4) is a governance model for FOSS (Free and Open source Software) projects that aims to create a solution-focused, iterative, inclusive and positive way of progress. I think it is time to promote it again, as its IMHO unique approach deserves to be discussed and implemented in more projects. It will need some minor updates, as things have changed since the primary author passed away. I started with creating a website at https://c4process.wildeboer.net 1/2
And set up an organisation at #Codeberg with the site sources and a discussion repository at https://codeberg.org/C4process I invite all of you that know or want to learn about the C4 process to join me there. Good governance for FOSS is not magic, Pieter spent years of his life to extract the C4 process from experiences and failures. Let's all learn together! 2/2
@schlauch@jwildeboer I like the approach too, but my final reaction is like "80% awesome, 5% geeze-louise gatekeep much?" Perhaps I am reading c4 ungenerously, but eg. 2.4.5 feels like "you must phrase your feature request in the form of a problem."
@jwildeboer The name C4 seems to be clashing with the other C4 systems architecture modelling language. Can we add or remove a word to end up with C3 or C5? If this is Pieter Hintjens, we're in for a treat. I was always intrigued by the good writing around the #0mq community process and also the work on calling out psychopaths. https://hintjens.gitbooks.io/psychopathcode/content/
AFAIR C4 itself is governed by COSS (https://rfc.unprotocols.org/), and if you change C4, technically it will would become deprecated and eventually retired.
But COSS has never left the draft state :D Do you remember what the ideas behind unprotocols were and why there is a split between unprotocols and ZMQ RFCs?
@xchange@jwildeboer@schlauch the explanation Pieter wrote in the context of zmq, which Jan linked to, does make that clear. That extra explanation and education makes a big difference.
IMHO this is not gatekeeping per-se but more like "just enough process", in the same way that you would expect contributors to open github issues and fill out an issue template over sending a free-form email to the maintainers personal mail address.
Sticking to problem/solution statements is as simple as it can get and helps to avoid the XY-Problem. I'm using this model successfully for many years now (adapted to a corporate setting) and it just works.
@jwildeboer@kdedude@schlauch Ive been re-reading chapter 4 of the book and I feel it would make sense to eventually merge this into the C4 website / repo.
The chapter is the design doc explaining the what and why, while the protocol defined in the RFC is the condensed implementation that explains the how.
C4 doesnt contain much details wrt releases/versions. I remember that e.g. zeromq tried to avoid the producer/consumer relationship that often emerges with software projects, and thus didnt put too much weight into versioned releases. It was expected to work on latest main.