More reading material (free for all) from my daily library that you may find useful:

- https://www.theopensourceway.org (from 2020, but full of timeless knowledge)
- Social Architecture by the late Pieter Hintjens at https://hintjens.gitbooks.io/social-architecture/content/chapter1.html

From that book, chapter 4, the C4 (collective code construction contract) annotated description is the one thing you should REALLY read :)

7/7 and end

@jwildeboer I think the long-form and comprehensive discussions you usually find on mailing lists are quite different from the focused ones that should be in issues.

Granted, you can do minute back and forths about diffs and patches in email and try to dissect strategic concerns in github issues, but I think that separating the two alone is worth doing it via email, never mind that I think the different composition environment forces a bit of switch in mind set – text boxes in web browsers are rather casual and ephemeral.

D's NNTP-backed fora might be another good approach here, but alas, who has a good, dedicated Usenet client anymore, so this just ends up as yet another web forum.

I used to think that Wikis were the next level of common strategic discussions, multiple people authoring a proper design document. But it turns out that this isn't a good fit for both collaborative endeavors and the way a lot of people prefer to communicate, i.e. it gets tiresome for most rather wiki-wiki.

@jwildeboer For #CHERIoT, we're using Signal for the public chat. It is similar to IRC and I've set it to auto-delete messages after one week. This ensures that people don't think of it as a place for discussions that they might want to reference in the future. We have the rule that you describe: if there's a discussion that has longer-term value there, someone should write it up.

GitHub Discussions and Issues are for our persistent discussions and where people write up the conclusions from the chats. They're easier to search than mailing list archives and they're readable / searchable without creating an account on GitHub.

The Signal group is easy to join (click on a link or scan a QR code) and doesn't require agreeing to anyone's abusive lack-of-privacy policy. The desktop app uses Electron, but somehow uses a fraction of the memory of other chat things.

@jwildeboer
Not really software, but I've tried running a project consisting of mostly young people with a mix of discord and github. Where they decide stuff on discord then someone (practically me) takes the conclusion and puts it in a repo

I'm pretty sure IRC/Matrix are a high barrier of entry for them, as they already use discord for everything. So in that sense, IRC is the locked down platform
Mailing are a bit different in the sense that everyone has an email, but it still requires some unusual forms of communication which isn't as easily migratable from discord

There is also a small use case where discussions must happen in private, so that goes against the full openness nature if your suggestion. For example moderation concern discussions. Which discord just so happens to have private channels to use. IRC/Matrix also do of course, but just wanted to mention a use case for locking down discussions behind a barrier.

(The use of github (and git in general) is also hard for them, but more so because they're not software developers, so it's not as applicable to the topic)

@jwildeboer I think some of the comment threads are missing the point. The tools of choice don't matter as much as the accessibility.

For OSS projects, we want a codebase, associated docs that are accessible. Install/usage instructions, etc and some manner of contacting the maintainers. Then some form of issue tracker.

If I'm looking for bugs, I like to search through all of the above to see if there is any relevant info already out there. This could be a mailing list archive, a bugzilla issue, GitHub issue, etc. What matters to me in that moment is finding the information. I don't need to login to any of these tracking mechanisms, and they're easily indexed by search engines which makes my quest simple.

When the issue tracker, discussions, and means of contacting the maintainers are in a walled garden like discord or slack, it adds barriers. Additionally, I can't just search across different issue trackers. I have to individually go to each one and use a proprietary search (if available).

1/

@jwildeboer

I'm still in my early thirties but I think I was probably one of the last generations where GitHub was not in basic monopoly for anything-git. At university it was still a decision which to use and some were still using Dropbox :)
So I think it was less of an issue back then, because not EVERYTHING was on GitHub. Now it gets more difficult to get people to do a bit more effort to contribute, is my feeling.

@0leil @jwildeboer

It's not just young people. I'm 56 and I don't care for the "submit patches only by email" rule either.

I've done it, but I don't like it.

The one project I follow that had that rule got a Github mirror, that's the only thing I use now.

They like their plaintext email; they can have it. I will happily live in *this* century.

@0leil @jwildeboer after running a largeish project for a decade now I am immediately skeptical of anyone saying, "you won't get contributions from me unless you change something".

In practice this has always landed somewhere between "when pigs fly" and "don't threaten me with a good time".

@tay

OK, fair enough.
I have no idea what bots are capable of on those systems :)