Live data from Hacker News

Spectrum is joining GitHub

spectrum.chat

131–140 of 155 posts

Re: Spectrum is joining GitHub

#132
post #79

I didn't know Spectrum until today. It looks similar to Gitter. As I understand it, it means we now have at least three “slack-like”, well-backed, open-source, community-centered chats: - Gitter, now owned by GitLab; - Spectrum, now owned by GitHub; - Mattermost, independent, but fully integrated within GitLab. That's great to have credible alternatives to the proprietary behemots that are Slack, Discord and others,…

Well I'd prefer that all those solutions relies on standards such as XMPP better than having the NIH syndrome. You should check on XMPP web solutions such as Movim https://movim.eu/ (P.S. I'm the author).

Well I think the new "hot" community standard is turning to be ActivityPub

Re: Spectrum is joining GitHub

#133
post #48

Earlier quoted context omitted.

I have a project within my corp where we need to collaborate with other companies on a shared project. We want to do this privately and right now run our own rocketchat stuff to do this. However we are open to hosted solutions. I was unaware of this product until now, I figured I'd give it a spin to see what was available now and hope for some cool github integration in the future. However the public-by-default stuff…

Hey there - if you selected 'private' during the community creation flow, everything in that community will be private. However, there will still exist the concept of "public" and "private" channels, however those scopes are still constrained by the community settings. For example, a private community with a public general channel means everyone who has access to the community can see those conversations. But if you…

Maybe instead of 'public' [to community] it should use a phrases like "whole community" and "only invited". To me 'public' implies The entire world.

Re: Spectrum is joining GitHub

#135

Earlier quoted context omitted.

Slack has threads. I don't know why nobody knows this. And unlike Zulip they aren't mandatory, which is a bit nicer for small channels.

IME, it is awkward to revisit collapsed threads in Slack; especially after the thread has aged a few hours.

This is exactly the issue with the style of threads used in Slack, Teams, Hangouts Chat etc. Their useful half-life tends to them being forgotten quickly.

Re: Spectrum is joining GitHub

#136
post #33

I spent a fair bit of time trying out many of the different chat systems out there for our tech community. In particular I looking for solutions that could do a half decent job of combining synchronous as well as asynchronous communication. The main benefit of implementations that manage to pull this off is being able to handle real-time chat but also make it easier to catch up with the conversation history if you've…

Slack has threads. I don't know why nobody knows this. And unlike Zulip they aren't mandatory, which is a bit nicer for small channels.

Topics aren't mandatory in Zulip. You can enable the "no topic" thread which makes them effectively optional.

Yes Slack has threads, but they aren't implemented in a way that's conducive to ad-hoc interaction over longer periods of time.

Re: Spectrum is joining GitHub

#137

Earlier quoted context omitted.

Slack has threads. I don't know why nobody knows this. And unlike Zulip they aren't mandatory, which is a bit nicer for small channels.

I think plenty of people knows Slack has threads. Threads in Slack are secondary and are mostly meant for having conversations that people don't care about. Zulip has a much superior threading model. Each and every conversation is a new thread and has a topic. This model makes it extremely easier to catch up and participate in conversations. Once you get used to the threading model of Zulip its hard to tolerate threa…

> Once you get used to the threading model of Zulip its hard to tolerate threading model like Slack which is really inefficient and time wasting.

This!

I got a bunch of our community to try out many of the different chat systems out there. Zulip was an interesting one as there were two points that really changed their perception of it as a platform:

1. When they were told there was a "Night Mode" - aesthetics are important! (something Slack arguably got right, IMHO beyond that it's just fancy IRC).

2. After around 5-10 minutes of playing around the penny drops as to why the stream and topic "zooming" is implemented in the way is it. Usually a "Holy Cow" moment.

Once you "get" it, going back to anything else feels like going back in time.

Re: Spectrum is joining GitHub

#138
post #101

Earlier quoted context omitted.

Personally I'm really annoyed with Scala community's obsession with Gitter. It's such an inferior tool. Gitter search UI is the worst, and search itself is useless, often returning no results when you can spend an hour scrolling to find what you want manually. This is inexcusable when Gitter is your project's de facto Q&A place instead of more structured places like StackOverflow or Github issues. And so the users ar…

Chat works better than forums. Speaking as a library maintainer, I've got GitHub issue that stayed there for months before I replied. That's because my time as a contributor is very limited and I get fatigue when replying to too many support tickets. And you'd think, oh wait but there are other people willing to reply. But not really. Forum, email groups, even StackOverflow only work when the projects you're talking…

As someone who interacts a lot with front line support for a fairly large organisation I find this balance interesting. Support channels are often a strange mix of FIFO with priority based queue jumping. I was at a talk by Kate Russell of BBC Click recently where she showed some stats on customer service based interactions heavily moving towards chat based interaction, obviously more and more backed by AI chat bots with human fallback. The next step on this path being voice chat also with bots.

Without the AI tier though scaling this is near impossible as you tend to a "most recent loudest" priority system, certainly if your support case to support rep ratio isn't balanced. Users also have to resort to repeating requests in a chat-only forgetful system.

This is why I ended up investigating hybrid sync/async interaction systems that cater better for not forgetting threads.

Re: Spectrum is joining GitHub

#139
post #118
post #92

Earlier quoted context omitted.

I used riot.im as my primary IRC client (via its IRC bridge) from home, work, and on mobile, for a year or so. Unfortunately there were lots of issues and bugs, to the point where I couldn't trust that when I wrote someone a message they would get it, or vice versa, so I had to give up on it. I'm now a happy IRCCloud user.

We're dropping riot because of the same reason right now. Sometimes messages do not pop up as push and that makes communication unreliable.

Are you facing this issue with chats on Riot itself or as a bridge to IRC ?

Because as a slack replacement, riot is pretty cool (and there some redesign happening ). Most of the criticism is around its IRC bridging, which I agree is a little unstable. But let's face it - nobody else (slack et al) even tries.

Re: Spectrum is joining GitHub

#140
post #82
post #78

Earlier quoted context omitted.

I must've lucked out, then, as I only pay $15 a month for an Internet-only plan through Spectrum. Granted, the speeds aren't anything to write home about (30 Mb/s download), but it's more than serviceable.

Where's that? I have an old $15 plan for 3 mbit grandfathered in but I would like a little more speed. The only plan they are offering to me is $49 for 12 months which then goes up 70.

In Los Angeles. Oddly enough, I went to see if I could find that plan again and it's nowhere to be found. The cheapest it's showing for me is a $50 a month plan for 100 Mb/s speeds.
Post reply on HN