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.

Jan Wildeboer 😷:krulorange:

If you want to dive deep(er) into the history and philosophy behind the C4 process, the book "Social Architecture" by Pieter Hintjens [1] is your best bet.

Chapter 4 [2] is an annotated walkthrough of the C4 process that should answer a lot of questions already. If you still have more questions, feel free to join the discussion in the discuss repository [3]. 4/4

[1] https://hintjens.gitbooks.io/social-architecture/content/
[2] https://hintjens.gitbooks.io/social-architecture/content/chapter4.html
[3] https://codeberg.org/C4process/discuss/issues

#C4process

xchangeee

@jwildeboer

IMHO we never had to rely on GitHub:

> The project SHALL be hosted on github.com or equivalent, herein called the “Platform”.

it was just practical to do so. what else do you think should be changed?

Jan Wildeboer 😷:krulorange:

@xchange Minor things. Like changing from "master" to "main" in 2.5.1, maybe add something about preferred use of the platforms release system, similar to how the merging is treated.

Maybe also rephrase 2.1.2 to something like

The project SHALL be hosted on a publicly accessible software forge with git support, issue management, release capabilities that are equivalent , but not limited to github, gitlab, codeberg, forgejo or others, herein called the “Platform”.

Jan Wildeboer 😷:krulorange:

@xchange I am also thinking of converting the Social Architecture book repo to Markdown, as I fear the version at gitbook might disappear sooner rather than later.

jon ⚝

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

xchangeee

@jwildeboer @kdedude @schlauch

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