1. Lots of people like realtime chat. It's worth having something that fills that niche (the old "mailing list + IRC" combo used to work well)

2. Forum software is usually fairly awful. I don't want to install some 15 year old pile of PHP with bad UX.

3. A "Stack Overflow" style site requires a lot of moderation and either annoys users for being too messy or annoys users for being too strict

4. I actually still have some fondness for Google Groups but Google's brand is too tainted for most people.

5. Nobody under 30 seems to use email any more so mailing lists are out but something that syncs with email is a must (reply notifications etc)

I am also hoping for something free but very easy to install. (SaaS with a free tier, one-click docker or similar). And easy on resources ideally (I guess $10/month for hosting is about our limit at the moment)

Yeah. I'm asking for a lot.

I'm not convinced it's better than irc+proper mailing lists - but given that real users are stuck in awful mail clients (like web/Gmail or outlook) - mailing lists isn't a great option any more.

Main thing I miss from zulip is a proper weechat plug-in (like wee-slack) - although the official cli client isn't terrible - it's just not irc-like.

My biggest issue with Gmail (as someone who interacts with users of Gmail) - is that it generally breaks quoting and hides this from Gmail users with its magic conversation view.

Outlook(web) does atrocious top-quoting rendering it useless for mailing lists.

In general the web interfaces doesn't work well with hundreds/thousands of mails IMNHO.

They also tend to needlessly lean on html formatting rather than plain text - with things like "my replies in blue" - rather than just proper quoting.

Ed: in general I've just given up the idea that the average user has any hope of interacting well with email lists - which means such lists aren't useful for general discussion (but can still work for specialist groups like Linux kernel etc).

The conclusion being that one will need "something else" for a general audience.

Zulip might be a reasonable compromise.

The weirdly aggressive way people talk about top vs bottom quoting is probably one of the things turning new users away from mailing lists.

Sadly I don't think there is a reasonable way to introduce new users at this point - I'm not aware of any great gui clients that do the right thing; and AFAIK neither Gmail or o365/exchange work in a reasonable way with open standards (allow checking for when others are free; accepting/changing appointments etc) - so users are herded towards the semi-proprietary clients. (and interop across silos doesn't really work in a sensible way).

There are things like the d-lang forums that mix a decent web front-end and nntp (and mailman makes an effort for web+smtp) - but I'm not aware of anything that really works great, with a low barrier of entry and reasonably lets users participate across more than a handful of threads.

Isn't Discourse an answer to that?

And then Matrix for real-time chat. Bridge it to IRC if you want. Search is not great in Matrix but sufficient for simple keyword searches.

I am not seeing a lot of projects adopting it and I wonder why because it seems quite good to me

[1] https://www.outverse.com/

Discourse and Flarum are even worse, in my experience.

However, having chat services does not substitute for having documentation; you should also have good documentation, too; you should not expect someone to only ask questions.

Really? There's no way to do verbatim searches and it's "very" generous in deciding what it thinks you meant to search for. It's almost useless for searching technical posts (or anything when you need to disambiguate similar words)

https://www.businessinsider.com/where-did-slack-get-its-name...

But let's not get stuck on this point. There's a dozen other reasons why Discord shouldn't be used for technical forums

But as for why Discord is a bad fit - it's completely opaque to search engines, it requires an invite, it has a fairly complex UI and it's basically "unstructured chat". Threads are an afterthought and don't come close to giving any proper structure.

I want chat for people that, you know, want to chat - but structured posts with topics and categories are needed for any sane, long term knowledge-base.

People on chat (this goes for IRC as well) will continually ask the same questions and you will continually have to answer them again because there's no structure.

Every external chat room logs service I've seen has also had bad SEO, buggy, bad UI/UX, etc..

But on the other hand, when I look at Bun I think it has heaps more going for it than Deno. The fundamental value prop of offering better performance (both runtime and developer experience) is huge, and something that would get me to want to use it. Contrarily, while I see a number of improvements in Deno, the vast majority of them seem to be "niceties" that solve some initial "setup" issues that can be painful in Node - but since I already have taken care of a lot of those Node issues in my own projects, there is not a ton that I see compelling in Deno.

Point being, if I were a betting man, I'd easily put all my chips on Bun vs. Deno. It's a "plan where the puck is headed" vs. a "plan where the puck is now" approach, and from that perspective I see a lot more value in Bun.

I felt this way too before using Deno for a while. So far I enjoy:

- Breaking from npm/node modules support on purpose turns out to be a real plus for me. It's refreshing to have dependencies referenced by URL, and it's good to have them cached centrally by default (in $HOME/Library/Caches/deno on macOS and $XDG_CACHE_HOME/deno or $HOME/.cache/deno on Linux, for example).

- Use of web platform APIs (https://deno.land/manual/runtime/web_platform_apis ) and the work to standardise those across platforms (https://wintercg.org/ ) is encouraging.

- `deno lint` and `deno fmt` make adopting and using JS/TS feel more like Rust/Go/other languages with good built-in ceremony-free tooling.

- Fresh is turning into a very nice Next.js/Astro alternative (https://fresh.deno.dev/ ) that I found very easy to learn and deploy, with great performance and developer experience out of the box.

Bun is interesting, but I wish it didn't embrace node modules: perpetuating its use instead of attempting to move the community on by recognising it for the mistake it was feels sad to me. (See Ryan Dahl's “Design Mistakes in Node” PDF or talk for more: https://tinyclouds.org/jsconf2018.pdf and https://www.youtube.com/watch?v=M3BM9TB-8yA )

This is one of engineering things that happens year over year. We all understand the value of good docs. Yet it keeps happening. Why?

Users don't search for documentation for the sake of finding documentation. They search for documentation because they want to know how or if our product can solve a particular problem they have. My hypothesis is that the documentation discoverability problem is really just a symptom of the product discoverability problem, and that centralizing docs in 1 searchable website to make docs "discoverable" is only addressing the symptom, when that effort can be much better spent addressing the root cause by making the product itself more discoverable and deeply integrating useful documentation into it.

a searchable docs website is the most important thing for me. having to "discover" an api by stepping through code and comments is a waste of time--only useful when you already know the basics, which requires documentation

* Easily get an overview of the entire API. I may just be scouting the library, so I want to understand what the API looks like.

* Examples as a starting point. How do I use your API?

* Makes your product more discoverable / approachable to potential users.

Think of your users like a funnel - how are they using the library? What are the common reasons you’re losing potential users? What are the common reasons you’re losing existing users? Users are also different so you have to analyze by cohort.

Now can something better be done? Maybe It takes a lot of work and would have to address the above issues and I don’t know if it would necessarily change the need for something centralized.

A perfect example of this is documentation generated from docblock comments. Some projects only have such docs, and expect users to go from there. It's as if programmers envision their audience as another machine to program.

I feel similarly about business/marketing aspects of software projects. Many programmers seem to assume, "If you write it (the program), they will come."

Successful software is so much more than just the code, it usually involves a communal effort of various skills, especially human communication, including writing good documentation.

So for the early stages of a project it makes sense to keep the overhead low and work with a small group of focussed early adopters.

As projects grow, mature and become more stable, more investment into learning material becomes important. Doing it too early burns valuable resources.

As I add new features I update the docs to reflect the changes, trying to keep those documentation updates in the same commit as the tests and implementation.

Since I started doing this the quality of documentation I produce has gone up a ton, because I'm constantly exercising those muscles.

It's been a huge win for my coding quality and productivity too - I don't have to remember as much stuff because I can refer back to the docs, and documenting as I go along causes me to make much better design decisions.

Worth noting: I'm a native English speaker writing documentation in English, and I've been blogging frequently and writing online for over twenty years so I've accumulated a LOT of writing experience. So what's easy for me may not be easy for other people!

Writing non-code is easy and fun to me - I used to do it for a living - but when I am pressed to deliver features, documentation takes a backseat. Also, I've never felt like documenting other people's code

I find the same approach I take to READMEs for smaller projects scales up pretty well: any time I make a change to one of my larger projects I ensure that the documentation is updated as part of that change.

If I accept a PR from someone without documentation I'll follow up by adding the docs for it myself in the next commit. I think that's more reasonable than demanding people add documentation if it's not necessarily their core skill set.

Honestly, I'd love to experience working with a professional technical writer on this kind of thing, but that's not something that's happened at any point in my career to date!

I'd argue if should replace as. The point being docs are all but essential for growth (and added participation). To neglect them is self-defeating.

Put another way: Docs are an investment. They have a known return.

Again, we've seen this. We know this. Yet again and again there's case after case of docs denial.

In 2017 I stopped working on the project entirely: I'd coded up a new major version of the library but never released it because knowing I had to overhaul and re-document so many different pages, demos, etc ... like a dementor, it sucked all joy from me.

Then in 2019 I recoded the entire project from scratch. This time I thought about the documentation first, before I wrote a line of code. I decided the best approach was to generate the main documentation from inline comments. I did this for both core code, and for demo examples - the demos stopped being standalone afterthoughts and became instead my end-to-end testing suite. To present the documentation to any developers who might show an interest in the library, I coded up the library's website in a way so that the core documentation[1] and the demos[2], with easily accessible code, could be very easily copied over to the website whenever I rebuilt the library (which regenerates all the documentation). I also added a set of lessons to the website, and a set of "How do I" articles - both of which are an ongoing project.

The library's website doesn't have any functionality where users can ask questions - but that's what the GitHub issues and discussions pages[3] are for.

The system isn't anywhere near perfect (I still need to automate the demo testing, for example, and there's no CI for copying stuff from the repo over to the website, etc) - but, given the depressing messes I've managed to fall into in the past ... it's working really well for me!

[1] - https://scrawl-v8.rikweb.org.uk/documentation/

[2] - https://scrawl-v8.rikweb.org.uk/demonstrations/

[3] - https://github.com/KaliedaRik/Scrawl-canvas

Many people won’t read them at all, no matter the quality, and so it can feel like work wasted.

Plus writing docs is a different skill set than writing code that many simply don’t like to do.

Engineers have to decide where to spend their time, and taking time away from feature development when your early-stage product doesn't have many features is not a winning move.

not necessarily. with the latter, you know the constraints of a solution and can make an accurate judgment on whether it's worth using

It takes a lot discipline to do things right.

Docs !== community

Docs === Odds of gaining traction

To your point, achieving community is a whole other beast to battle.

And to your point, writing docs *is* something to consider when building the team. As is making sure the culture has a reward system if such behavior is important.

Because doing anything is is irrational?

Time is finite, only a rounding error number of projects (especially open-source ones) are going to be successful, with or without docs.

Only an irrational developer would think that they are going to hit the 1-in-a-thousand jackpot with their project.

Any time spent producing documentation is time not spent on adding features and fixing bugs.

Spending time on documentation over and above the bare necessity needed to get out a working product "just in case we win the jackpot" is simply irrational.

This is probably why you don't find many projects spending significant startup time on good, clear and comprehensive docs (as opposed to a README and an FAQ and nothing more): the ones that do as you suggest mostly die before even getting users.

TLDR; don't treat your startup project as if you already have 5m users who depend on you. The odds are that you are never going to get to that point without a good product, and the better the product, the fewer the docs needed.

if you spend your time making sure your product works but don’t write thorough documentation, it can become a breakout hit even though some hacker news commenters may complain about a lack of good documentation

if you spend your time writing great documentation, the product will suffer and nobody will use it

This is an unfortunate perspective. And I could say the opposite is true. If you don’t spend time writing great documentation, your product will suffer and nobody will use it.

Documentation gets neglected because developers don’t feel like doing it. If you are building a product for developers, documentation is critical.

https://snyk.io/blog/open-source-npm-packages-colors-faker/

[Not a fan of Bun] In Bun, you can pin versions with package.json just like in node.js

What would address the malware injection when someone chooses to auto-update packages as part of a build?

What sort of knowledge are we talking about?

This says nothing of what a terrible choice it is for a knowledge base, especially long term. The only way you choose Discord is if you aren’t thinking beyond the “next release”. That’s a huge red flag in a fundamental framework project like this.

It’s a minefield. People will get hurt. Those of us who have been around will be entitled to say we told you so. But I hope users move away before they get hurt, which will happen.

This is a proprietary application and protocol. It will come back and hurt you. Get out while you can.

That's not unexpected given that it has voice and video chat functionality.

if you aren’t thinking beyond the “next release”.

I think that lack of long-term thinking is endemic to the JS community in general, unfortunately.