In the olden days, a FOSS (Free/Open Source Software) project typically had:
-
tessaraktreplied to Jan Wildeboer 😷:krulorange: last edited by
@jwildeboer What about an issue tracker?
-
Jan Wildeboer 😷:krulorange:replied to tessarakt last edited by
@tessarakt Many (smaller) projects didn't have one. It was often handled on the mailing lists. Setting up a full-blown bugzilla was quite a task. Sorceforge was (like GitHub nowadays) another solution to that.
-
Proxfox Virtual Environment 🦊replied to Miah Johnson last edited by
@miah @lunareclipse @jwildeboer yes but once you've answered the same question for the 500th time you do kinda want full chat search & history
-
Jan Wildeboer 😷:krulorange:replied to Proxfox Virtual Environment 🦊 last edited by
@tay It's called an FAQ and should be publicly available on the homepage of the project, IMHO @miah @lunareclipse
-
Miah Johnsonreplied to Proxfox Virtual Environment 🦊 last edited by
@tay @lunareclipse @jwildeboer There is this advanced technology called a "FAQ" and posting the link in the channel topic, or presenting it to the chatter who needs it bypasses this issue.
-
Proxfox Virtual Environment 🦊replied to Miah Johnson last edited by
@miah @lunareclipse @jwildeboer It 100% does NOT bypass the issue. I've placed error messages in an application where I put the instructions to resolve the issue in the message box body.
I still got hundreds of emails with the title of the message box copied and pasted in. If a lot of users aren't going to read the 2 lines of text in a modal box, they're not going out of their way to read the FAQ.
You need to give users every possible reason to not resort to messaging you, and chat history is one of them.
-
feldreplied to Jan Wildeboer 😷:krulorange: last edited by@jwildeboer counterpoint: when you force people to use IRC, you're excluding a *LOT MORE* potential contributors because so many people do not like or want to learn IRC, especially younger folks. They want a nice app, rich chat features, and limited friction to sign up / connect.
The IRC crowd is old now. A lot of investment needs to be made into making IRC "comfy" for people. I don't know how to solve this. I've worked on several teams where we used IRC and when new people came onboard they were absolutely horrified and confused about IRC. They did not like it and mostly abstained from using it. -
Proxfox Virtual Environment 🦊replied to Proxfox Virtual Environment 🦊 last edited by
@miah @lunareclipse @jwildeboer And the other problem with FAQs is in the name. *Frequently* asked questions. Countless times I've had an issue and ctrl+f'ed the issue and found one other person having the same issue 2 years ago.
-
Miah Johnsonreplied to Proxfox Virtual Environment 🦊 last edited by
@tay @lunareclipse @jwildeboer FAQs can also store the answers to infrequent , but common questions.
-
Jan Wildeboer 😷:krulorange:replied to feld last edited by
@feld I don't even think of using IRC that much. I am describing what we did in the past and how all of that had one thing in common: being open and accessible. Compare that to having to have accounts on two or three external (proprietary) services *per project* you are interested in. THAT's my point.
-
Proxfox Virtual Environment 🦊replied to Miah Johnson last edited by
@miah @lunareclipse @jwildeboer
a) what maintainer is going to put the answer to every single question they've been asked on a FAQ
b) who's going to read a FAQ with a 200 lines TOC
-
Jan Wildeboer 😷:krulorange:replied to Proxfox Virtual Environment 🦊 last edited by
@tay I get it, no matter what we say, you will come back with a "yes, but". I will mute this thread now and concentrate on the more productive parts @miah @lunareclipse
-
feldreplied to Jan Wildeboer 😷:krulorange: last edited by@jwildeboer What is our best option to replace those services, though?
I think we're basically looking at Gitter, Mattermost, and RocketChat with Gitter being the most open option (no enterprise/proprietary features // "open core" junk) -
david_chisnallreplied to Jan Wildeboer 😷:krulorange: last edited by
@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.
-
Jan Wildeboer 😷:krulorange:replied to feld last edited by
@feld The very first question should always be: how much value do these services bring to your project and at what price? Devils advocate question: do we really need these tools or are they maybe a time and resource black hole? I for ne wouldn't even think of adding discord, matrix to my projects. Code, issues, releases via forgejo/codeberg/github , a homepage and maybe a mailing list would be enough for me. So I guess I am the wrong person to ask about alternatives ...
-
@david_chisnall @jwildeboer Signal is a clever use for this, but I think for many projects it would be best if there was accessible chat history and search.
You've got me thinking though... -
Juanlureplied to Jan Wildeboer 😷:krulorange: last edited by
@jwildeboer That's fair enough but didn't answer my second question, sorry
-
Jan Wildeboer 😷:krulorange:replied to feld last edited by
@feld Signal groups as backchannel for core developers and security issues makes a lot of sense, IMHO. @david_chisnall
-
Jan Wildeboer 😷:krulorange:replied to Juanlu last edited by
@astrojuanlu My solution isn't to go back to anything. I just want to promote to care more about the openness and inclusivity of a project. Because it seems we have reduced the priority of that.
-
Jan Wildeboer 😷:krulorange:replied to Jan Wildeboer 😷:krulorange: last edited by
@astrojuanlu So for my next project I will use Codeberg with a mirror repo on Github (mostly for releases), try to keep discussions in the issue tracker and maybe add one or two mailing lists with public archives. And that will be it. If community members/maintainers want to have a chat solution, we will discuss and I, as project leader, will demand that it MUST be open to everyone and the project has full control over all content.