My next Open Source project will use #forgejo for git, release and issue management according to the Collective Code Construction Contract (C4 )process [1] (so no lengthy discussions in issues, only problems and solutions). A static landing page with documentation. A read-only archive of the mailing list posts. And only e-mail to communicate. No chat, no discord.
The goal is to slow everything down. So that devs can concentrate and users learn to use documentation and archive before asking.
Forgejo: https://forgejo.org
[1] Collective Code Construction Contract (C4 ) Process https://c4process.wildeboer.net
And no, I have not yet decided which project to start, but it will happen. So I am just preparing myself to set it up the way I think is best.
This approach might totally fail, I am well aware of that. But honestly, it'll be a valuable learning exercise. And I can iterate for the next project. Pragmatic, not dogmatic.
Ehm the name is nice, but it does overlap with the C4 diagramming for it architecture.
@bartvdo You didn't even read the first two sentences on the link?
"Welcome to C4process. A website dedicated to promote and discuss the Collective Code Construction Contract (C4).
Not to be confused with the C4 Model for visualising software architecture."
The Collective Code Construction Contract (C4) is an evolution of the github.com Fork + Pull Model, aimed at providing an optimal collaboration model for free software projects. This is revision 2 of the C4 specification and deprecates RFC 22. License Copyright (c) 2009-2016 Pieter Hintjens. This Specification is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.
Jan Wildeboer 😷
Bart van der Ouderaa
Fernando M. S. 🇵🇸
thejikz