HN user

libertycabbage

2 karma
Posts0
Comments4
View on HN
No posts found.

Yeah, the Slack and message limit thing is why Discord > Slack as far as real-time chat goes for projects. Free workspaces in Slack have a 10k messages history limit so once you get big enough, you start "losing" older messages (although they still exist, and if you end up paying, you get access to them again).

There are some other options out there to address the "company walls" bit. Products like [Matrix](https://matrix.org/) come to mind; it does require a bit more setup, but you keep control over data. It makes discovery a bit harder though (i.e. you can assume that a significant % of folks already have a Discord account for some reason, and people aren't averse to creating accounts on Slack, but they might back off from engaging with solutions like Matrix because it feels like a new thing they would need accounts for).

That's an interesting thought.

I can definitely see the gating being a problem down the line, although there are solutions to this (one that comes to mind is publishing channel archives in some indexable format periodically).

The "why" feels flow-related to me. The message board format isn't super well adapted to active discussions, but real-time chat on spaces like Discord and Slack feel snappy if you want to have a "chitchat experience" with other devs. I wouldn't necessarily call it a new thing though; before Discord and Slack, IRC was a pretty popular way for OS communities to organize, and that too suffers of the same lack of indexation (unless steps are taken, i.e. publishing archives to make them accessible to those outside the chat server).

From the perspective of someone who runs some public-facing OS-related Slack / Discord spaces, my approach has always been to try to get folks to create issues on projects' GH tracker when it looks like other folks would benefit from the insights or to organize reports / requests. That way, while the initial chat happens in the chat spaces, there are artifacts that are also available outside of them so that others can engage without joining the chatrooms.

To the last point about repeated support request -- questions asked should always drive documentation. Whether it's on Discord, GH Issues or some forum, if a question is asked repeatedly, it should end up in the FAQ / troubleshooting docs. That feels more like an organizational problem than a problem with the platform (case and point, StackOverflow is a treasure trove of questions about everything and anything, but there's active moderation to weed out dupes despite everything being indexed, repeats will happen regardless of previously asked questions being available or not).

One important thing to dispel about open source is the idea that good contributions are about galaxy-brain level PRs. Contributions can happen at all level, from non-technical to technical, from reporting issues to opening PRs to solve them. And when it comes to PRs, the gamut is large: writing documentation, adding test coverage, suggesting micro-fixes or refactors are all good and valuable ways to contribute.

As you contribute more to a given project, you become more acquainted with the lay of the land, which in turn opens up more opportunities to contribute to open problems.

Long story short: contributions don't have to be complex and deeply technical to be valuable, and you gotta start somewhere. Pick a project you're interested in or look for issues needing attention (for example, via `Good First Issue` labels on Github), try something out and have a chat with more active maintainers. They'll show you the ropes and get you started!

IMO healthy work culture is about clear work/life boundaries, keeping bad stress (i.e. managers breathing down your neck / dealing with impossible deadlines is bad stress, whereas working on high-stakes stuff can be good stress, but that's just my take on it) as low as possible and having agency / freedom with respect to how you approach problems (within reason).

If the above is satisfied, feels pretty healthy to me.