Clojurians Log v2
community-development
@seancorfield Following up our short discussion from yesterday https://clojurians.slack.com/archives/clojure/p1484685598012679 I get that there are a lot of people in these channels, especially in clojure and clojurescript. Thats why other channels exist and more specific topics should go there. But how do you as a passive follower recognize that two people started DMing if they do not announce that? Discoverability of that is almost non existent. Also the DMs are not logged and therefore, you might find the start of the discussion of a problem via google, but not the solution which was already a problem in the usenet back in time. Of course everybody is free to do what he wants to do and if admins say they should start DMS well then, so be it, but in this case I think it is a disfavour to the community as the advantage of sharing the solutions to problems and the path to finding them overweights the disadvantage of "using a chat medium in the way it was built to be used."
It's a part of Slack that sometimes goes unsaid; several conversations can be held at once, though it can be difficult to follow. In general, search for a relevant existing room that's more specific in purpose, or create one if it doesn't yet exist, or move to a DM if it's too temporal to be relevant to any one room.
FWIW, 50% of messages in Clojurians are in DMs, 50% are in public channels. Based on the weekly report the admin team get.
Wow, that's pretty surprising
I think what should be worth mentioning is that if something is moved to private DM that was starting in a public channel and it ends in a solution that's worth sharing, then that solution should probably be posted back in the originating public channel for the benefit of the community as a whole
Creating an open invitation to that DM as it starts may also be helpful in some (but obviously not all) cases.
Does this solve it?
Oh wow. That's sooner than expected. Excellent ironic timing!
sounds like a terrible idea to me. I assume this is the beginning of the end for Slack :)
It does seem to signal that they aren’t so much replacing email as assimilating it… but we’ll see...
eh, it could work. Flowdock has threads and it works fine.
threaded messaging is great for async communication but it seems questionable to me for realtime chat
both are useful
why does everyone want one thing to do both?
we can have two things :)
I hate to say it, but I think Twitter actually (now) has one of the more interesting models for realtime threaded comms in that you see the message level but can then gain the thread context pretty easily
It's still not email
Because it's discoverable by others in the channel
They made sure that it has hooks that tie the thread to its parent channel and can continue tracing back to it as the conversation goes on.
Hold on, let me pull up their engineering blog (which is a bit slammed right now...)
Think of it more as attaching a rope to a point in the conversation and allowing detailed discussion to continue on that rope. Anyone else can still follow the rope, but major topics at the room-level are also easily navigable.
https://slack.engineering/weaving-threads-bee48dc69d6#.yhotc6mq6
More than anything, it's an information organization problem.
the crux of the problem is that real-time means keeping track of the “horizon"
This actually ends up being approximately Twitter's approach, if I'm not mistaken.
https://cdn-images-1.medium.com/max/800/1*DK4MNJxMDmQY46sPhPfaoQ.gif
when threads fork off the horizon, you then have multiple (possibly unknown) horizons
^ That's how you keep the horizon in sync.
Looping back into the main topic when significant.
well, we’ll see soon enough… I remain skeptical :)
And bringing in just enough context with it.
I think they're smart cookies and seem to have though this through well. It's better than I though it was going to be - definitely did not want 'email but in Slack'
it’s just hard to “be all things” well. I wish them luck. :)
haaaah
😆 Ah, Google Wave… where are you now? 🙂
I just wish G+ had worked out in favor of FB. So much stronger for community management.
Too little, too late.
It's worth noting, that this model seems to be nearly exactly the same model as that explored by the #braid-chat team. I definitely think it makes a lot of sense, I'd definitely felt forks in conversations appear, where I felt that I needed two conversations open. I think the braid version feels more natural, but this has potential.
And with the existing adoption of Slack, will get far more attention than Braid. Will probably strike a blow.
sooooo see y'all in Freenode#clojure 😛
I just noticed threads have been enabled on this slack!
That’s very new — they weren’t enabled a few hours ago when I tried… Nice!
I'm going to overuse them when helping people for the next week
It would be kinda nice to send to main channel after it's been sent. As in, I proposed the solution, it turns out to be correct, and then I want to share that back. But that's only minor
Interesting that in my desktop client I can still see threads as part of the main channel right now (Linux client) - I guess that was a better default than not showing them and the desktop clients will catch up.
seancorfield: I know. I'm pretty sure it only just happened. Also, you're my test subject. Sorry.
I don’t mind being your lab rat 🙂
dominicm: Surely you can't be serious!
Seems reasonable enough. They intentionally made them second-class, it seems.
Their blog post explains their target use case — to allow conversations between just a few team members, without distracting the whole channel. Sounds exactly like what we need here!