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.

xchangeee

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.

Jan Wildeboer 😷:krulorange:

@yala Yes, the C4 model (which AFAICS was created AFTER the C4 process) is explicitly mentioned as disambiguation right on the front page.

Seeing how both operate in very different fields, I feel OK with using #C4process for the process and refer to #C4model for the modelling approach.

xchangeee

@jwildeboer +1 for all suggestions.

But what about the document status?

AFAIR C4 itself is governed by COSS (https://rfc.unprotocols.org/), and if you change C4, technically it will become deprecated and eventually retired.

But COSS has never left the draft state Do you remember what the ideas behind unprotocols were and why there is a split between unprotocols and ZMQ RFCs?

Jan Wildeboer 😷:krulorange:

@xchange Yes, I remember. Which is why I'd like to discuss with COSS (if they still care on possible ways forward before making any changes. My priority and motivation is to take the #C4process as-is and promote it. If changes/updates can be made in a way that all stakeholders agree with, that's a big bonus.

[ade]

@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.

Jan Wildeboer 😷:krulorange:

@kdedude I've added a link to Chapter 4 on the frontpage at https://c4process.wildeboer.net to help people find the explanations faster. @xchange @schlauch

xchangeee

@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.

Jan Wildeboer 😷:krulorange:

@xchange I wanted to convert the blog to support multiple authors anyway. I'll play around with it a bit to see if I can post Chapter 4 as a guest post by Pieter @kdedude @schlauch

xchangeee

@jwildeboer @kdedude @schlauch

might be relevant, too?

http://hintjens.com/blog:93 (C4.1 - an Exothermic Process)

http://hintjens.com/blog:26 (The End of Stable Releases?)

http://hintjens.com/blog:85 (The End of Software Versions)

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.

Jan Wildeboer 😷:krulorange:

@xchange His big dream of an open world running on stable and reliable APIs that make releases and versions an archaic artefact of a chaotic past have not come to fruition, unfortunately. @kdedude @schlauch

Jan Wildeboer 😷:krulorange:

@xchange But when you follow the #C4process, a release is just a tag in your repo and the platform will build the release files automagically. Good enough for me @kdedude @schlauch

Jan Wildeboer 😷:krulorange:

@xchange Chapter 4 reformatted as markdown and posted as second blog entry at https://c4process.wildeboer.net/blog/2024-12-21-C4-Annotated/ @kdedude @schlauch

Jan Wildeboer 😷:krulorange:

@yala But to make it very clear to any visitor of the website, I changed the logo at the top to include that it is about theCollective Code Construction Contract. I hope that helps and thank your pointing at this possible point of confusion!