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:wrote last edited by [email protected]
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 updates, as things have changed since the primary author passed away. I started by creating a website at https://c4process.wildeboer.net 1/4
-
Jan Wildeboer π·:krulorange:replied to Jan Wildeboer π·:krulorange: last edited by [email protected]
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/4
-
Jan Wildeboer π·:krulorange:replied to Jan Wildeboer π·:krulorange: last edited by [email protected]
(That's one of the things that has changed. We now have decentralised forges with #Forgejo and don't have to rely on Github or Gitlab alone) 3/4
-
Tobias Schlauchreplied to Jan Wildeboer π·:krulorange: last edited by
@jwildeboer I like the approach and the way it is described. It is compact and even explains its goals and context
-
Matija Ε ukljereplied to Jan Wildeboer π·:krulorange: last edited by
@jwildeboer I love the idea. I'll check it out in detail later.
Sorry to be that guy, but can you link the source code (git repo) to the page in e.g. the footer? GPL and all thatβ¦
-
Jan Wildeboer π·:krulorange:replied to Matija Ε uklje last edited by
@hook Will do. Had to test the build process first, which now works.
-
Jan Wildeboer π·:krulorange:replied to Jan Wildeboer π·:krulorange: last edited by
@hook Site updated.
-
@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."
-
Jan Wildeboer π·:krulorange:replied to [ade] last edited by [email protected]
@kdedude Yes. It sounds like a harsh approach. Pieter explained the Why at https://hintjens.gitbooks.io/social-architecture/content/chapter4.html under "Development Process" (the whole chapter is recommended reading) @schlauch
-
Jan Wildeboer π·:krulorange:replied to Jan Wildeboer π·:krulorange: last edited by [email protected]
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 -
xchangeeereplied to Jan Wildeboer π·:krulorange: last edited by
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:replied to xchangeee last edited by [email protected]
@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:replied to Jan Wildeboer π·:krulorange: last edited by
@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 βreplied to Jan Wildeboer π·:krulorange: last edited by
@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/ -
xchangeeereplied to Jan Wildeboer π·:krulorange: last edited by
@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:replied to jon β last edited by [email protected]
@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.
-
xchangeeereplied to Jan Wildeboer π·:krulorange: last edited by
@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:replied to xchangeee last edited by [email protected]
@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.
-
@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:replied to [ade] last edited by
@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