In the olden days, a FOSS (Free/Open Source Software) project typically had:
-
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
-
@miah @jwildeboer Sure, IRC runs on anything, but it still doesn't work for most people. I say this as somebody who's spent over a decade on IRC.
To get the very, very basic, not at all optional feature "message history", you need to run a bouncer. Which is a tall order for most people.
The amount of people on computers too slow for Matrix is much smaller than the amount of people who can't/won't run a bouncer.
-
@muvlon @jwildeboer As stated earlier. Message history is not a required feature. You simply never go into a social event and ask people for their discussion history for the evening.
I don't know why people using irc think this should be the norm. If you want message history, there are frequently logs for heavily used channels.
Let me ask this question, do you read _every_ line of text that was written while you were absent? And then I'd ask "Do you _need_ to read every line?"
-
Jan Wildeboer π·:krulorange:replied to Miah Johnson last edited by [email protected]
@miah Exactly. Chat, no matter in which way it is implemented (IRC, Discord, Matrix, WhatApp (though, gasp ;)) should never be critical to any project. It is definitely helpful to solve stuff fast, but it should not go beyond that. The real work (and time) should go to documentation, FAQ AND CODING @muvlon
-
Dave Lane π³πΏreplied to Miah Johnson last edited by
@miah @jwildeboer with Matrix - yeah, it's a bit more involved, but you can join from *any* Matrix instance, if you have found one you trust. It's #libre technology, so it's consistent with libre dev. Discord is a non-starter for libre projects in my opinion. I agree with you Jan - wrote this a while back: https://davelane.nz/notslack
-
Wanjareplied to Jan Wildeboer π·:krulorange: last edited by
@jwildeboer @miah I never said it should be *critical*. But it not being critical is simply not enough of a reason to make it arbitrarily *worse* for everyone except nerds like me who run their own servers.
No, I don't ask everyone in a social even about the discussion history, but if I could have that context without bothering everyone, of course I'll take it! And this is way more valuable than being able to use it for a retrocomputing hobby.