Git Based SDLC
nordstroem.chI don't think git should be the infrastructure of collaboration. It's good for long-lived artifacts, but isn't good for discussion, for rights management, ...
fossil (https://fossil-scm.org/home/doc/trunk/www/index.wiki) is of course better, but if git must remain, I believe the base infrastructure should be the mailing list. Patches, branches and releases can live inside a mailing list, it is naturally built for discussion with rights, and is a natural queue for third-party tools. I wish we moved away from centralized forges and started to use augmented development clients with the mailing list as the sole communication vector.
I haven't really considered security/rights management yet, that's a good point.
> [Confluence] It’s about the only collaborative WYSIWYG wiki out there.
!? Wikimedia and Notion, just off the top of my head. And Confluence was initially just textarea inputs, its early WYSIWYG was engagingly bad.
Concurrent editing or Collaborative real-time (https://en.wikipedia.org/wiki/Collaborative_real-time_editor) is perhaps a better choice words.
Notion is supposedly able to do it: https://www.notion.so/help/collaborate-within-a-workspace#re....
Wikimedia is apparently working on it: https://www.mediawiki.org/wiki/VisualEditor/Real-time_collab...
if confluence is supposed to be an example of something - it is only an example of what to avoid!
^exceptionally bad
This may sound relatively off topic. But, in defense of my argument, please consider that GitHub was s actually the only SDLC available for git. Then came gitlab, gitea, forgejo, etc. Among those, this self-hostable tool is really outstanding: https://code.onedev.io/onedev/server/~files/main/readme.md
Of course, having one of these apps that is yet-another-github with a local-first approach might turn to be great DX!
This is taking these ideas to the logical conclusion.
That's another idea of mine that's been brooding for a long while.