In the olden days, a FOSS (Free/Open Source Software) project typically had:
-
Jan Wildeboer π·:krulorange:replied to Matthew Lyon last edited by
@mattly I am sure the XMPP crowd will wake up soon and promote their approach
-
Latte macchiato :blobcoffee: :ablobcat_longlong:replied to Jan Wildeboer π·:krulorange: last edited by
@[email protected] Both mailing lists and IRC suck. There's a reason they were replaced.
I'm on two mailing lists and they're already a massive pain in the ass. We don't have to use tech from the 90s religiously. -
Jan Wildeboer π·:krulorange:replied to Latte macchiato :blobcoffee: :ablobcat_longlong: last edited by
@privateger I am not demanding to return to IRC and mailing lists. I do ask however if requiring the use of proprietary systems like discord is a good choice for an Open Source/Free Software project.
-
@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 repoI'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 discordThere 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)
-
Jan Wildeboer π·:krulorange:replied to Guest last edited by
@luca Sure. For backchannels to be used by moderators, core devs and for security stuff I would use Signal. I wouldn't trust Discord or Matrix for those sensitive things.
-
Jan Wildeboer π·:krulorange:replied to Jan Wildeboer π·:krulorange: last edited by
@luca But a more general problem: right now a lot of people have discord accounts. A few years ago that would have been Facebook. And in a few years it will be another (centralised) thing. From a sustainability perspective that's kind of a big problem, IMHO.
-
@feld @jwildeboer You can probably have a bot connect to the Signal chat and mirror it publicly, if that's what you want.
-
Jan Wildeboer π·:krulorange:replied to david_chisnall last edited by
@david_chisnall (I definitely wouldn't want that @feld
-
@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".
-
Vadim Rutkovskyreplied to Jan Wildeboer π·:krulorange: last edited by@jwildeboer >At least one mailing list called announce, typically also one for users and one for contributors
fwiw I've never seen that work as designed. A lot of user questions went straight to contributors list - this is where all the cool kids hang out duh -
Jan Wildeboer π·:krulorange:replied to Vadim Rutkovsky last edited by
@vadim Same as with any channel. Set up IRC channels for users and devs - they all are in devs. Set up matrix channels that way, same. But mailing lists like announce were typically configured to be moderated, only allowing very few people to post.
-
LogicalErzorreplied to Jan Wildeboer π·:krulorange: last edited by
@jwildeboer Hm, I do agree with summarizing the outcome for others to catch up on, however it might be better to have software that groups chat up in a certain way? Like Zulip or Codeberg issues
Problem with Matrix/Discord is that you get repeated questions because 1) search isnβt good 2) there are no βthreadsβ to limit a conversation to one topic
-
Jan Wildeboer π·:krulorange:replied to LogicalErzor last edited by
@Logical_Error In my experience (and that's around 25 years and various projects): When you offer synchronous communication (AKA chat), people will ask first and search later. They have an itch, they post it in a chat and hope for (or sometimes demand) answers. They won't read the FAQ nor the chat rules. With synchronous communication channels like e-mail or issues, there is more motivation to check first (not a lot, though but also more acceptance for delayed answers. Pick your poison )
-
jon βreplied to Jan Wildeboer π·:krulorange: last edited by
@jwildeboer
Would you have some reference to the "only what is coded or in the list archive exists"? This may be an important building block for some other work in another area. -
Jan Wildeboer π·:krulorange:replied to Jan Wildeboer π·:krulorange: last edited by [email protected]
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.htmlFrom that book, chapter 4, the C4 (collective code construction contract) annotated description is the one thing you should REALLY read
7/7 and end
-
Jan Wildeboer π·:krulorange:replied to jon β last edited by
@yala Not a direct line in a book I can link to, unfortunately. I did add some literature to the thread that will hopefully help!
-
@lclapp @jwildeboer
I re-read again and I think I just went on a tangent very fast.I think what triggered it was "young people simply never experienced the olden ways. Maybe they want to explore them a bit" part of the toot. I shared my experience with a few very vocal - assumed - young people trying to make/force projects to use the workflow they are used to.
I then provided my unasked-for opinion on those topics and basically started the typical flame war on git forges and contribution methods, like one could do with the ol' vim/emacs "debate". My apologies. I hope this part of the thread I started dies out soon
-
Jan Wildeboer π·:krulorange:replied to Q last edited by [email protected]
@0leil And I will apologise for my brutal language (I am dutch, though that is not an excuse that allows for misinterpretation. I'll grab a beer at the beer garden now and will start to translate this rough thread to a shiny blog post, taking into account everything I have learned from all of you sharing their critique and thoughts! @lclapp
-
@kevingranade @jwildeboer The issue is that most FOSS projects are underfunded, understaffed, overworked or its devs/maintainers on the brink of burn out or - most likely - all at the same time. Having more contributors and especially retaining them is crucial, so it's not always easy to say "please, more contributors" and then shun people away with "yes but not by changing our contributor workflow". If we keep hearing from different people we lost potential contributions because the contribution workflow was unacceptable to them, we have to decide whether the loss of their theoretical contribution was worth it. I don't have the answer.
-
Jan Wildeboer π·:krulorange:replied to Q last edited by
@0leil Burnout in FOSS projects is real and must be addressed. One part of reducing those risks is to focus, focus, focus. I personally find any for4m of chat system a distraction. It uses up my time in a way that rarely results in code for the project. So my radical position is: no chat stuff at all. If that means losing potential co0ntributors, so be it. They may not be the people I want anyway. WRT underfunding, understaffed: A complicated topic that can't be solved in toots @kevingranade