[HN Gopher] If it will matter after today, don't talk about it i...
___________________________________________________________________
If it will matter after today, don't talk about it in a chat room
Author : mcrittenden
Score : 732 points
Date : 2021-01-12 19:09 UTC (1 days ago)
(HTM) web link (critter.blog)
(TXT) w3m dump (critter.blog)
| danShumway wrote:
| > I'm not saying live chat is useless. It's great at some things:
|
| > - Quick answers to quick questions
|
| > - Low-stakes status updates
|
| > - Swarming around red alerts or outages
|
| Well OK, but the problem is that sometimes those things also
| matter after today. So in practice, it often does end up being
| better to just save everything in an indexable form, because you
| can't realistically decide in advance to every conversation
| whether or not it's going to be important. You can pretend to,
| you can put every conversation you're going to have in one of
| those bins -- but you'll just be pretending, you're not going to
| get the prediction right every time.
|
| The second problem is that sometimes conversations fluctuate and
| change form, and it is not uncommon to have a good long-form
| conversation that needs to occasionally dip into quick questions
| and status updates. When the boundaries between your chat
| environments are too rigid, you can have the same productivity
| losses because people delay having important conversations or
| just avoid them entirely. This kind of categorization of
| communication often ignores that communication is extremely
| fluid. You can change between longform training and technical
| discussion, quick status updates and questions, and even
| affirmation multiple times during the same conversation.
|
| Most people on HN already understand how much harm context
| switching and interruptions can be for productivity in
| programming. But the same can also be true in communication. If
| you're in the middle of a chat and there's a clear opportunity
| in-line with what you're already talking about to explain
| something or reach a decision, you are basically imposing a giant
| context switch if you say, "well, no, don't talk about it. Let's
| all schedule a meeting." Or even if you just say, "keep it in
| your head until you get back to your desk and then email me."
|
| Sometimes that interruption is warranted, and sometimes it costs
| a lot of focus/productivity for very little gain. It's
| situational.
|
| I'm not sure it's wise to have binary rules about how and where
| people on your team should communicate. A lot of the advice I see
| around team organization and management ends up being generally
| good advice but taken to the extreme, where it wraps back around
| to being a barrier to actually getting stuff done. Encouraging
| people to use email for longform technical discussion is a good
| idea, but I suspect that trying to make some kind of policy about
| may be a bad idea for most orgs.
| k__ wrote:
| _" Despite the "asychronous" claim, you have to keep a steady eye
| on it and reply in realtime or the conversation will move on
| without you."_
|
| For me, sync and async communication is a spectrum and chat (as
| it is used in the majority of companies) is more on the sync half
| of it.
|
| I'm currently thinking about building a microblogging alternative
| to Slack, that will be more on the async side, not as much as
| email though.
| nicktorba wrote:
| There really needs to be some sort of mix between chat and a
| collaborative note-taking app.
|
| How can we transform chats into a reasonable, permanent reference
| materials?
|
| Maybe it would be possible to build a slack-bot that could
| identify which part of these threads are the most important, and
| even move them to a more permanent storage.
|
| Or, slack channels could add functionality to allow users to vote
| for which messages are most pertinent, or should be moved to
| longer-term storage or a featured position for everyone.
|
| I think there is probably value in these rapid fire IM's, but I
| feel the Mike's (the author's) pain. I skip over threads everyday
| because reading them never feels worth it.
| notacoward wrote:
| This is one of the things that drove me nuts at my last company.
| I had been remote all along, which meant I was left out of many
| discussions. Chat was my lifeline, because it was the only thing
| both I and others on the team used. When everyone went remote, we
| had an opportunity to make a change for the better, but instead
| _nothing at all changed_. Meetings were done via video chat
| instead of in person, but they were just as un-findable and
| ephemeral as before. If you mapped out the lines of communication
| before and after, there 'd be no difference. In person vs. online
| matters far less IMO than ephemeral and closed vs. open and
| permanent.
|
| The irony is that the company happens to be the world's largest
| platform for easily findable/joinable permanently archived
| conversations. Go figure.
| kazinator wrote:
| I tried to follow the course using the backcountry map, but due
| to some Slack in the GPS, I ended up Discoursed. I fell, badly
| twisting my ankle, and was not able to Github and walk. Thus
| stranded in the middle of nowhere, I peered into my backpack. I
| only one Carrot left to eat, and to my utter dismay, I had left
| the Flarum gun at the Basecamp. Luckily, my cellphone's data
| connection somehow worked well enough that my E-mail client was
| able to clear the SOS message of the outbox after some 23
| retries.
| mkr-hn wrote:
| I forget which podcast it was on, but Automattic's CEO (Matt
| Mullenweg) talked about how they use blogs internally for much of
| their communication, so there's a huge searchable archive of
| information back to the early days of the company. People
| occasionally write posts to collect useful information that's
| fallen too deep.
|
| It was probably either in his interview[0] on The Knowledge
| Project or a recent episode of his own podcast[1]. Probably the
| former since the latter usually focuses on what other people are
| doing instead of his own company.
|
| [0] https://fs.blog/knowledge-project/matt-mullenweg/
|
| [1] https://distributed.blog/podcast/
| aheckler wrote:
| We call the internal blogs "P2s". You can make one yourself
| even. :) https://wordpress.com/p2/
| shp0ngle wrote:
| Slack is for low effort stuff, while e-mail is for never-ending
| barrage of status updates and notifications from all the systems
| you use.
|
| ...what is for important stuff then
| isaacremuant wrote:
| Opinionated article that doesn't land in my experience.
|
| Slack search is awesome, allows links with previews, reminders,
| easy channel creations, bookmarking, threading to allow sub
| topics...
|
| Better than email for the quick back and forth, better than voice
| that is harder to schedule and synchronic and doesn't keep
| records.
|
| If it's really important, you should have a way to keep track
| besides the "quick communication" but that doesn't mean slack
| isn't a great tool by default. Just keep an eye on the data
| deletion policies.
| Communitivity wrote:
| I disagree with this article.
|
| This is what was said about GMail when it first came out - you
| need folders, without folders you can't keep organized, etc.
|
| Turns out indexing and mechanisms to make use of that indexing
| (labels, advanced sorts, filters) work better than folders.
|
| Persistent chat that can be labelled, indexed, searched and
| filtered is amazing for work related chats, or any chat that
| becomes part of a long running context.
|
| We do this where I work, and it works well, mostly - as long as
| people use the tags.
| zug_zug wrote:
| Exactly, I completely reject the premise of this article. In
| the last hour I searched the "alerts" channel to see how many
| times our database had high CPU in the last year.
|
| I'm not one to defend slack, but there's nothing inherently
| temporary about slack. And searchability > manual
| categorization.
| jodrellblank wrote:
| That doesn't seem enough to reject the premise of the
| article, which explicitly calls out that chats are great for
| both "Low-stakes status updates" and "Swarming around red
| alerts or outages", a high CPU alert that was just a
| notification is the former, a high CPU alert that people
| discussed and fixed is the latter.
|
| Also, your "database", singular? Was the answer something
| like 10 times? Would that scale?
| mbreese wrote:
| I don't know about that. There are a few large differences
| between chat and email, so it's not a great comparison.
|
| 1) length -- most emails are significantly longer than any
| _single_ chat message
|
| 2) context -- email threads are saved (and indexed) in the
| context of their thread.
|
| With chat, you really don't get ether, so it's significantly
| more difficult. You can never really know what a message is a
| reply to. Responses can come fast or slow. Individual channels
| can have multiple conversations happening, if not
| simultaneously, then at least over time.
|
| _> as long as people use the tags_
|
| I mean, that's the difficulty with any system... getting people
| to use it. If your team can be disciplined about the tags, then
| I'm glad that works for you. I not sure it would work well in
| many other contexts.
|
| I've tried a few different options over the years, from
| archiving/indexing IRC chat logs, to bug trackers, to wikis, to
| email, to Slack, to Notion, etc...
|
| Almost anything can work if you're disciplined. My problem has
| always been getting the rest of the team on board.
| Communitivity wrote:
| These are great points, though I disagree with all of them as
| reasons to prefer email over chat.
|
| _> 1) length -- most emails are significantly longer than
| any single chat message_
|
| Agreed. The beauty of a chat, rather than an email thread, is
| that each message contains (or should) a single point. Which
| means the chat thread is more of a sequence of the following
| kinds of responses: Yes, and; Yes, but; No, and further; No,
| but. This makes for a better conversation, and makes it
| easier to process. How many times have you asked two
| questions in an email, only to have someone respond to just
| the last one?
|
| > _2) context -- email threads are saved (and indexed) in the
| context of their thread._ > _With chat, you really don 't get
| ether, so it's significantly more difficult. You can never
| really know what a message is a reply to..._
|
| This is a matter of implementation, not technical capability.
| A decent context is achieved through proper use of tags and
| chronological ordering. Better threading can be achieved
| through a protocol implementation of a reply-id capability,
| which most chat systems have (XMPP, Discord, etc.), coupled
| with GUI presentation of messages in a threaded view.
|
| > _...Responses can come fast or slow..._ True of any
| asynchronous channel, email or chat.
|
| > _Individual channels can have multiple conversations
| happening, if not simultaneously, then at least over time._
|
| I see this as a feature, not a bug. With tagging a chat
| message can be part of several different conversations at the
| same time, even across channels. Which conversation you are
| presented with depends on which tag you are viewing.
|
| > _I mean, that 's the difficulty with any system... getting
| people to use it. If your team can be disciplined about the
| tags, then I'm glad that works for you. I not sure it would
| work well in many other contexts._
|
| In my experience, this is often the biggest hurdle in
| implementing any revolutionary system (as opposed to
| evolutionary) that makes a big change in how people do
| things. For messaging, there are systems with a reminder
| feature similar to most email client's behavior when there's
| no subject. For instance, "This message has no tags. Messages
| are required to have at least one tag, and should have
| between 2 and 7".
|
| You need management to force the issue though. An approach
| I've used in the past is to find a competitor or two using
| the technology, and use business/financial FOMO as a
| motivator.
|
| Also, if you do a typo in an email..it's there forever. A
| typo in a chat can be fixed in many systems.
|
| In a desire to be fair, I will add two reasons to use email:
|
| 1) If you are doing CYA. Email can't be changed, and is
| routed through a number of servers, possibly leaving log
| fingerprints. Email also has bcc. Anything that is important
| you can bcc to a second friendly party to prove you sent it,
| or to a personal email account (do this with trade secrets,
| or heaven forbid - classified - and you should get what you
| deserve, and I don't mean in a good way). If you want a paper
| trail, don't use chat.
|
| 2) If you are sending a document. Most businesses have virus
| scanners built into their email server software. A document
| is typically sent, retrieved, and saved somewhere. Though, if
| a document will be referenced often by many, neither chat nor
| email are best. Use a wiki, or something similar.
| k__ wrote:
| _" as long as people use the tags"_
|
| That's the crucial point here.
|
| UIs need to help users to find the appropriate tags, often
| tagging is either included implicitly, which leads to
| forgetting or clunky, which leads to aversion.
| 1penny42cents wrote:
| The sheer volume of information that Chat holds makes it hard
| to search. The noise to signal ratio is higher than on channels
| with lower throughout (e.g. documentation products). Chat
| doesn't let you send one message and craft it over time, like a
| mission statement, proposal, or architecture guide. It has a
| fundamentally different character.
| pixl97 wrote:
| And some chats are worse than others. Teams does this so
| poorly it brings my battlestation to its knees trying to do
| simple text search.
| kazinator wrote:
| > _Rule of thumb: If a discussion will matter after today, don't
| have it in a chat room. Check out Discourse, Twist, Carrot,
| Threads, Basecamp, Flarum, or heck even GitHub issues._
|
| I see; anything but e-mail! Gotcha.
| relaytheurgency wrote:
| I definitely agree with this. The one thing that I hoped would
| prove useful from these programs vs IRC was the idea of a
| persistent, searchable, history. However my experience has been
| not great. Searching history often just brings up unrelated
| snippets of conversations I didn't have any interst in, in
| channels I never chatted in. It's just more clutter.
| [deleted]
| daneel_w wrote:
| And if it matters after today, don't send it as an SMS, don't
| send it as an e-mail, don't talk about it over the phone, and if
| it matters that someone knows you went out to meet this or that
| person, don't bring your phone with you.
| njharman wrote:
| I thought this was going to be about personal InfoSec ala Parler.
| kevsim wrote:
| In my previous job I battled this a lot. While I really like
| slack in general, no one likes it when things fall through the
| cracks or important people miss out.
|
| It actually bothered me enough that I quit my job and made
| Kitemaker (YC W21) which automatically watches slack
| conversations for mentions of work items and links them together.
| This linkage lets people working on something that there are
| discussions going on about it in Slack. You have your persistent
| place for writing things down (in Kitemaker) and can still use
| Slack. We have lots of plans for making it even more
| frictionless. Also works with Discord.
|
| https://kitemaker.co
| williesleg wrote:
| I thought it was about putting comments on a website that saves
| them forever.
| Footkerchief wrote:
| Slack has fantastic search. It has good filtering, sorting, and
| pagination, and has the right degree of fuzziness.
|
| I use it on a daily basis to discover the reasoning for things
| that happened before my time. I've never known anyone else who
| does this, and I've never understood why.
| Minor49er wrote:
| I would do this at my last job, which was very Slack-heavy. I
| would even bring up any weird dev issues or bits of info that I
| came across that sometimes only mattered to me at the time, but
| it turned out to be helpful when I would search for those
| things months (or even years) later.
|
| My current job has both Basecamp and Slack. Most of the work
| discussion happens in Basecamp, which is fine. However, the
| search is pretty awful, so it's hard to get a quick and
| relevant response back when trying to find out more info about
| a given setting, feature, piece of code, or whatever else.
| There's a lot of extra digging involved with Basecamp's search
| results.
| throwaway-42808 wrote:
| That's encouraging. I haven't had the same experience yet, but
| I haven't worked for someone who pays for full search history.
| paxys wrote:
| Every Slack plan has full search history, so really you
| haven't worked for someone who pays for Slack. Like, I get
| that it is expensive, but it's weird to run your company on a
| product trial.
| throwaway-42808 wrote:
| Yep :)
|
| It's a weird way to try to save money, imo. Down the line
| it just leads to confusion and repeat work.
|
| They also underinvest in documentation, with the same
| result.
| the_arun wrote:
| Well, Slack search experience could be done better. I prefer to
| see search results and selected thread with search keyword in
| the same view. It is annoying to keep going to every thread in
| the results and going to search bar again if that is not I was
| looking for.
| bt1a wrote:
| I second this, I am actually able to find tons of important
| communications on Slack that happened years ago at my work.
| Perhaps it is not well understood by many? I somewhat agree
| with the author, but what is the alternative to Email or a Chat
| Application?
| Torn wrote:
| A product that does threaded conversations. Yammer did this
| pretty well, shame it never really took off for businesses
| dpcx wrote:
| I have struggled for years to find things that I know exist
| within Slack. I specifically (as a test) set up my email to
| forward all mail to a specific address in to Slack
| (https://slack.com/slack-tips/send-email-to-slack) and found
| more often than not that Slack could not find something when
| searching for it.
|
| YMMV, of course. But my mileage was pretty terrible.
| angry_octet wrote:
| I haven't yet seen anything better than NNTP (the protocol of
| Usenet) and a decent news client, which used to mean _tin_ on
| Unix and MT-NewsWatcher on MacOS. We used to have patches and CVS
| commit messages on code review groups and fork discussions
| seamlessly into dev groups. Mailing list email to NNTP gateways
| allowed ready collab with workers outside the group. Common NFS
| share allowed easy joint work without huge amount of code &
| build duplication. And it was possible to just grep every message
| in the News spool.
|
| This was much better than Slack + github + email + Confluence +
| Teams + file shares + SharePoint -- no one knows where anything
| is or which chat system a conversation was on. Searching Slack is
| a fool's errand.
|
| I attribute the failures of these systems to be their reliance on
| the pattern of centralised SQL+httpd+templated crud+js vs
| federated standardized exchange+text.
|
| In modern web apps the client is embedded in the app by its very
| nature, and so the proprietary nature of each system makes
| community contribution impossible.
| mongol wrote:
| Can a chat platform be built on SMTP, and what would be the
| implications of that? Has that been done? I think email has so
| many things going for it, and I wonder to what extent it has been
| rejected as a platform because it is too open.
| cxr wrote:
| Delta Chat
|
| https://delta.chat
| weeboid wrote:
| You can create a specific room for a scoped discourse or
| dialectic.
| jrockway wrote:
| I have always thought that Slack is designed to make information
| go away, and that's why people like it. Email never goes away
| unless you archive the thread. If you have a bunch of things that
| are going on, you open your inbox and realize just how behind you
| are, every time you open it. Slack, conversely, scrolls up and
| always looks the same. If you miss something, the world moved on
| without your input, and you feel the same.
|
| The article is right that the problem is when the information
| doesn't want to be deleted. Now you have to do extra work.
| (Specific example; a long time ago, I figured out how to get
| Github to notify me on Slack when a code review was assigned to
| me. It is not easy to find in the UI and took me a while to set
| up. I wrote down the instructions in Slack... and that helped
| people that were reading it then, but it doesn't help me tell
| someone how to do it that asks me today. Should have written a
| runbook!)
|
| Remembering to persist information is always something you have
| to do, and it's not specific to Slack. Your shell history is
| useless to your coworkers. Your design discussions is useless to
| someone that just joined the team today.
| tshaddox wrote:
| I'm confused. What are the differences between Slack and email?
| Both are generally displayed on a relatively small list where
| new messages eventually cause old messages to be hidden. Those
| hidden messages are still accessible if you try, both with
| similar processes (assuming you're using an email client with
| text search like Gmail).
| barrkel wrote:
| Corporate Slack retention is typically measured in days,
| while email retention is measured in years.
| NoodleIncident wrote:
| My experience with Slack is the opposite. Scanning through my
| list of channels, I'll see some channel I don't recognize, and
| it will still be pinned at the top unread message 4 months ago
| when someone added me for some reason.
| ketzo wrote:
| From my experience, the mark of a well-run Slack is the ability
| to find old, valuable information. You're right that it's not
| always easy, but you can get a LOT further with 1) well-defined
| channels 2) good use of pinning 3) good use of "saving"
| messages for yourself.
|
| It helps that Slack's search is actually pretty good imo, and
| usually quite fast.
|
| But yeah -- it can't be your only tool. If you don't have a
| better system for long-form documentation, you're gonna lose a
| lot of important stuff.
| GekkePrutser wrote:
| Well, a real paid slack instance doesn't go away. All the
| public free slacks do.. The whole fact that Slack charges a lot
| for the privilege of keeping history beyond a couple of months,
| proves that it's worth a lot to many people.
| ogre_codes wrote:
| Yes, but as gmail has illustrated, that just shifts the
| problem. Where before your problem was "It got deleted". Now
| the problem is search pulls up too many things.
|
| Slack seems to be even worse because unlike email, you don't
| really have subjects or thread beginnings, just continual
| flow of chatter.
| GekkePrutser wrote:
| I don't really have this issue with Gmail. It works a lot
| better than O365 search with the same amount of mails in it
| (I recently migrated everything over).
|
| But indeed the lack of organisation of any kind makes it
| harder for chats.
| pcthrowaway wrote:
| You can make threads in slack. The implementation is a bit
| weird but (as of last time I used it circa 2018) it did the
| job sufficiently. For features which required more focused
| discussion from a sub-team over a longer period of time
| there was a pseudo-room feature (I don't remember what it's
| called though)
| a-dub wrote:
| amusingly, my understanding is that the original goal for slack
| was to be an archive.
|
| slack originally stood for: searchable log of all communication
| and knowledge
|
| but then in practice, i saw message retention locked down to 30
| days or less, which kinda defeated the point.
|
| other modern tools, like trello, also seemed to have gaps when
| it came to logging/searching/archiving what happened. trello is
| fantastic for organizing "what needs do", "who do", and "when
| done"... but in my experience is pretty terrible for "what
| happened" and "why". this is fine i think at smaller scales,
| but once complexity starts to scale up, it can be a nightmare.
| it's hard enough fighting issue hysteresis (reoccurring issues
| and bugs that drag on for years) when there's good historical
| views and explanations.
| TeMPOraL wrote:
| I don't know of any productivity tool that handles archiving
| well. You can store done tasks in some way, but all the
| context is lost. Over time, it's annoying even on a small -
| individual - scale.
| alach11 wrote:
| I think Azure DevOps handles context pretty well. I can
| look at old tasks and see associated commits,
| conversations, and related work.
| a-dub wrote:
| yeah, the info is there and you can do the same with most
| tools, but it often requires a lot to extract it. how
| well organized is it? how hard is it to go from line of
| code to complete discussion around when it was last
| changed?
| SulfurHexaFluri wrote:
| Doesn't slack have full history if you pay for it? We use
| Teams and I regularly find myself searching for stuff I
| remember I was sent months ago.
| derangedHorse wrote:
| It does and today I just learned that there are some
| companies that don't store all messages sent. Slack works
| great at my company, I can search for things a year or more
| back and even write messages to myself as a form of note
| taking.
| onionisafruit wrote:
| My company has slack archives going back ten years. They
| imported everything from the old chat system.
| [deleted]
| FalconSensei wrote:
| > I have always thought that Slack is designed to make
| information go away, and that's why people like it.
|
| I think it's exactly the opposite?[0]
|
| People like it because, except for the free plan, you can find
| anything that was ever discussed.
|
| [0]: https://slack.com/pricing
| silicon2401 wrote:
| This is exactly why at my org, slack is one of the de-facto
| sources of truth. And it's awesome. I can often find the
| solution to a specific, niche problem that someone else
| discussed 4 years ago in a few seconds. Assuming your org
| pays for whatever it is that allows full archival, it's a
| great way to capture org-specific, tribal knowledge that you
| won't find on google, but that nobody will take the time to
| add to an internal wiki or something accessible beyond their
| immediate team.
|
| If you want a chat nightmare, try microsoft teams. That
| quickly became one of the most painful parts of one of my
| previous workplaces.
| xpe wrote:
| In a few seconds? Wow. I'm a very fast reader and probably
| need at least 15 seconds to wade through a busy Stack
| Overflow page.
|
| I've found that Slack's discoverability is severely limited
| because it seems to prioritize low-effort input. Here's
| what I mean: in a busy channel, Slack makes it so easy to
| reply in a linear chain. Unrelated messages get
| interleaved. Following a train of discussion can be
| difficult.
|
| In contrast, I very much like how Zulip organizes threads.
| It allows content to be organized both up-front (at posting
| time) and over time. This feels very natural to me.
| silicon2401 wrote:
| cmd+k > copy and paste error message > (few seconds pass)
| > results appear in slack search
|
| I do this all the time at work. I didn't say that I can
| expand and read through all the results in a few seconds,
| that part takes time. But comparing that to something
| like teams, which would often freeze for me when going
| back in a convo history, let alone something like asking
| people individually, slack has been great for finding
| internal knowledge.
| cerved wrote:
| Teams is built by boomers, for boomers
| jrockway wrote:
| I have a paid Slack plan and while I can find specific
| threads where I remember a lot of the details, I've never
| found anything that I didn't personally participate in.
|
| Overall, I think search is a bad knowledge base management
| tool. It proves the positive quickly (search for "foo", see
| "here's how to use foo"), but never lets you prove the
| absence of documentation (search for "foobar", nothing comes
| up, search for "foo bar", nothing comes up, search for the
| previous codename "barbaz", nothing comes up... did you
| forget something, or is there just no
| documentation/discussion? you'll never know. the result is
| that people stop reading documentation.)
| jonathanburke wrote:
| At Automattic we have not been using email for the past dozen
| years for internal communications. We replace email with
| WordPress.com/P2 plus IRC (moved on to Slack).
|
| In our internal P2s we count 1 million posts (that might have
| been emails), 2.6 million comments (that might have been email
| replies) across 1,100 P2s (that might have been email silos).
|
| We are active on Slack, but decisions are made on asynch P2s
| which are the source of truth.
| nitwit005 wrote:
| The rule should be the same as meetings, which is that if
| something important is decided, some document or wiki page should
| get updated.
|
| It's never the case that everyone who might need to know is in a
| meeting. You might hire someone next week.
| saadalem wrote:
| So there is no knowledge hub inside these companies or what ?
| esoterica wrote:
| > Thinking one line at a time lowers the quality of the
| discussion. Knee jerk rapid fire responses become the norm.
|
| I mean, this is also how talking in real life work. Chat is
| supposed to be the closest written replication of a verbal
| conversation. Rapid fire back and forth is how many discussions
| are _supposed_ to happen.
| danielovichdk wrote:
| To me or seems that the author is more frustrated with how his
| team communicates during a sprint than the tool being used.
|
| If you need to discuss something in thorough detail in a sprint,
| which is on the sprint backlog, it is done during refinement.
|
| If a discussion is about a work item/pbi/user story it is
| discussed not in Slack or Teams, but under the item's discussion
| board. Jira, base amp and azure DevOps all support this.
|
| The symptoms of poor communication or following a proces cannot
| be deslt with be changing from Slack to email.
|
| People needs to be educated it seems as where communication must
| go.
|
| Emails are not for work items under a sprint. Imo. Neither is
| Slack. You don't discuss wotk items in a chat, you do that in
| it's appropiate platform where the item livets.
|
| Slack is not email. Should not be used as such. Slack is for
| "hey, where is that vacation spreadsheet" and not "should this
| feature be with bootstrap or vanilla HTML?"
|
| The latter is work. It is discussed where work lives. Work does
| not live in Slack.
|
| Good luck
| generalk wrote:
| The way I've always heard this is:
|
| If it's important, it needs to have a URL.
|
| Your issue tracker works, assuming you're not constantly changing
| your tracker. SharePoint may work but is super clunky for this
| purpose. Confluence or Notion or something work just fine.
|
| Email doesn't work by itself. With some mailing-list interface on
| top it may, but that seems like you're stretching a bit.
| IM/IRC/Slack/whatever chat also don't work for this purpose.
|
| I always think: if I want to put a link to this project's design
| docs, maybe some meeting notes, so new hires can come up to speed
| on what we're trying to do, I want it to be a URL that makes some
| kind of human sense, and I want the format to be conducive to
| communicating the right details.
| barrkel wrote:
| Slack messages all have URLs. They work both in the browser
| (once you're authenticated) and in the clients.
| everyone wrote:
| We use Discord, and have 2 channels for each game we're workin'
| on. 'Updates' and 'Chat'
|
| Announcements you want everyone to see go in 'Updates' So if you
| finished a feature or are starting work on a feature, or have a
| doc to show everyone... ... Everyone working on that project will
| have notifications turned on for the projects 'Updates' channel
| and will read everything on it.
|
| All general chat about the project and also responding to and
| chatting about stuff in 'Updates' channel happens in chat
| channel.
| indymike wrote:
| This argument has been going on for decades. Chat vs. threaded
| discussion vs. email. The best one for me is where the people I
| need to communicate are listening. The hard part is getting
| everyone to listen in the same place. It doesn't matter how good
| the UX is, if you need the CEO in the chat and she only does
| email, then email it is.
| wpietri wrote:
| I find this somewhat incomprehensible. Why the bias for seeing
| and archiving everything? The implicit model, which is right
| there in his title, is "talk", which is not naturally archived.
|
| I've built products just fine using verbal communication nearly
| exclusively. [1] We don't need to create some sort of panoptic
| archive of every conversation ever had to get things done. If
| people miss things, they miss things. We can catch each other up
| on the parts that truly matter.
|
| Forgetting and repetition can be negative, but they can also be
| highly positive. We don't have to carry with us the weight of
| every word ever spoken about a project.
|
| [1] The main exception being index cards with a few words on
| each. https://williampietri.com/writing/2015/the-big-board/
| xpe wrote:
| It seems you disagree, which is fine. But that is very
| different from the blog post being incomprehensible.
| wpietri wrote:
| I understand the words just fine. It's the motivation I find
| incomprehensible. In particular:
|
| > If you go on vacation [...] Often your only option is to
| declare chat room bankruptcy which means missing out on
| important discussions and big decisions.
|
| So what? That's what vacations are for. The whole point is to
| miss things. It's good for both the person and the
| organization to miss things. "The graveyards are full of
| indispensable men."
|
| There's some unstated motivation behind the post. But
| whatever it is makes no sense to me. The options I can think
| of fall in a range from absurd to self-defeating.
| xpe wrote:
| >> If you go on vacation [...] Often your only option
| >> is to declare chat room bankruptcy which means missing
| >> out on important discussions and big decisions.
| > That's what vacations are for. The whole point is to
| > miss things.
|
| That may be an _effect_ of vacations, but that is not their
| driving _purpose_ , which may be: to get away, recharge, do
| something different, travel (remember when that was a
| thing?), visit friends, and so on.
|
| A big part of coming back from a vacation is catching up.
| Vacations can feel a lot better when it is easier to get
| back in the groove when you get back.
|
| There are chat/messaging systems that make catching up much
| easier than Slack. I really like Zulip, for example.
| thaumasiotes wrote:
| >> That's what vacations are for. The whole point is to
| miss things.
|
| > That may be an _effect_ of vacations, but that is not
| their driving _purpose_
|
| That all depends. A confucian official was apparently
| required to take a _two year_ mourning period following
| the death of his father. I have read the theory that one
| purpose this practice may have served (intentionally or
| not) was ensuring that no one could usurp too much power.
|
| More recently, I have read that some bank employees are
| legally required to take a certain amount of vacation,
| with an explicit justification being the idea that if you
| are using your position in the bank to engage in a lot of
| financial fraud, you may find it more difficult to keep
| the fraud going while on your legally-mandated vacation.
| wpietri wrote:
| You're definitely correct about bank employees. I know
| people who've been required to take vacations as a matter
| of policy, and fraud prevention is how they explained it.
| wpietri wrote:
| No, the purpose is to give people time to do what they
| think best. For them to no longer have the demands of the
| organization paramount. That is, to miss things.
| pixl97 wrote:
| Talk was not naturally archived in the past, but I would not
| assume that today. There is no longer anything that is an
| intimate object, pretty much anything can have a microphone and
| some type of wireless connection. Is your desk phone at the
| office listening to you even though it's on the hook?
| Technically it can. What about your smart TV?
| barbs wrote:
| I think the basis of the article is that a lot of people use
| Slack as a storage of sorts for things that should be archived.
| That certainly aligns with my experience - I've worked in teams
| where I've asked for a document or credentials for something
| and have been told "It's on Slack, search for it".
| hbosch wrote:
| > I find this somewhat incomprehensible. Why the bias for
| seeing and archiving everything? The implicit model, which is
| right there in his title, is "talk", which is not naturally
| archived.
|
| Somewhat harder to do now that we are all WFH.
| m_eiman wrote:
| In my reading the point of the post is that it's important to
| have a record of the important things (like why did we decide
| to do X, or to do it in this specific way), and that putting
| such discussion in the same context as things that aren't
| important to record makes it very hard to filter out the
| important bits later on if needed.
|
| So they advocate for putting the important information in a
| separate context, that also allows for more thoughtful
| conversations.
| wpietri wrote:
| That's a plausible interpretation, but the notion that
| "important=anything that matters for longer than 1 day" still
| makes no sense to me. And I also disagree that it's a priori
| important to have a record of important things. It's nearly
| tautological, and even if it weren't, there are some strong
| embedded assumptions about how to build software that at best
| need close examination.
| derangedHorse wrote:
| This sounds like it may be a people problem rather than a
| technology problem. If a problem is moving on without him on a
| messaging platform I don't know why his teammates wouldn't do the
| same on an email thread or a github issue. One-liners also don't
| have to be the norm and I myself have gotten plenty of page long
| responses when warranted. Channels and threads also work for me
| when it comes to skimming, and Slack has a solid search feature
| which manages to make locating things super easy
| nwsm wrote:
| Conveniently Teams has both chat and threads.
| xyst wrote:
| Not really related to the article but at my work they are testing
| deployment of 3 different systems. They were deployed at
| different times so X was first then followed by Y about 1 year
| later, then finally Z ~6 months after deployment of Y. Z is
| expected to be fully adopted and Y and X will be phased out,
| eventually.
|
| Depending on when the person joined they tend to have a
| proclivity towards a specific chat application. The oldest person
| on the group used X almost exclusively. The newer group members
| tended to use Y and Z apps.
|
| So you would get pings from all of these apps and the points
| describes in the article are amplified times three.
|
| In order to reclaim some sort of sanity, I decided to just log
| off from X and Y chat platforms and only use Z. I figured if that
| person really wanted to get ahold of me then they would figure it
| out themselves that I only use Z. Also I did send out e-mails and
| set statuses on X and Y indicating my preference for Z.
|
| I would say thus far it is a success. Haven't had any complaints
| for the past 6 months :)
| 1penny42cents wrote:
| This article describes the problem with "hot" channels, like
| Slack or Zoom. Their information throughout is so high that it's
| hard to hold onto anything. That high throughout also makes them
| valuable for quick syncs and personal conversation. We run into
| trouble when we try to make it do more than it was built for.
|
| "Cold" channels (e.g. documents, tickets) are where important
| information should go. A single piece of information can be
| developed and solidified over time. Cold channels are easier to
| search, easier to catch up on, and easier to onboard.
|
| The problem is not with any one channel, but that we expect one
| channel to handle all types of information.
| kumarvvr wrote:
| I really hope the word e-mail is replaced with something else
| (like 'memo') and a new paradigm is introduced around the concept
| of offline discussions, like forum board or stack-overflow.
|
| The purpose of such a system would be to save discussions and
| understandings in discussions for a long term.
|
| I read Stack Overflow threads now and have a pretty good idea
| about the thought process from problem -> approaches -> solution,
| including solutions or approaches that were rejected.
|
| Real-time chat is not a replacement of a meeting, because
| meetings have substantial outcomes and key decisions taken, that
| are usually recorded as Minutes of Meeting / Meeting notes.
| cowpig wrote:
| I actually think Zulip is an exception to this, because its
| Stream>Topic hierarchy encourages organized conversations.
|
| At my org, we consider Zulip to be an archive of sorts, and make
| an effort (a small one, because Zulip's UX makes it natural) to
| organize our communication such that it serves as a source of
| information for a future date.
|
| I wrote a whole article about this a while back:
|
| https://monadical.com/posts/how-to-make-remote-work-part-two...
| kbrwn wrote:
| Chat will become the primary method of communication and will be
| where most work gets done. Other systems will exist sure
| eventually hackers will build tools for them to be interfaced
| with via chat clients. This has been happening for many years.
| Old people need to get over it and stop writing blog posts that
| basically sound like anti-email rants from 1998.
| skohan wrote:
| Maybe I am one of those "old people" but I don't understand how
| discord is better than more traditional forums or mailing lists
| for technical discussions. With a mailing list, forum thread,
| or GitHub issue, I can search and find something relevant to me
| from years ago. By contrast, discord seems so ephemeral: I have
| to hope I can be in the same place at the same time as the
| person who has the information I need. And it's a closed
| platform, so it's not searchable or indexable the same way as
| content on the open web. And if discord closes their doors, or
| changes their TOS in the wrong direction some day it might all
| just be gone from one day to another. I would be happy to
| understand why you think chat is a better tool for the job.
| andybak wrote:
| I can find useful discussions from 10 or 20 years ago because
| they were crawled and archived. IRC, Usenet, web message boards,
| mailing lists...
|
| Every single discussion happening on Slack or Discord will
| probably be lost in a year or two and is impossible to find
| unless you happen to be already aware of it.
|
| Developers should not use these platforms for anything with any
| value. This is not the way to share information.
| silicon2401 wrote:
| While I enjoy slack at work (not without reservations, but
| overall I like it), I definitely agree slack/discord are
| terrible for communities. I can't imagine how much discussion
| that even I participated in almost 15 years ago is still
| quickly available, would now be lost to the ether of discord
| and slack.
| SulfurHexaFluri wrote:
| This is desirable. I like that my discord conversation will
| be gone in a few years. They serve little purpose being
| archived anyway. Old IRC logs are a horrible thing to search
| for help anyway. Much better just picking a forum/reddit post
| on the same issue which will be better sorted.
| andybak wrote:
| The problem is that for many communities there is only the
| Discord. Quite technical communities - building projects
| they obvious feel will have longevity.
|
| Mozilla Hubs springs to mind but there are many more. It's
| become the norm. It's crazy and more people need to speak
| out if we're not going to lose a big chunk of a
| generation's tech knowledge.
| SulfurHexaFluri wrote:
| I just don't see this being as much of an issue as is
| stated here. I find that over the years its easier and
| easier to find info. Github issues, reddit, or
| stackexchange have huge wealths of info that are
| expanding rapidly.
| andybak wrote:
| I'm talking about communities with very little other
| material footprint. Nearly all discussion is on ephemeral
| platforms. There are no other knowledge bases to refer
| to.
| julianlam wrote:
| The key here is not the format of communication, since you've
| listed email chains, chat, and forums in one list.
|
| It's the fact that slack and discord are essentially walled
| gardens that do not allow for third-party indexing. Therein
| lies the problem.
|
| If public discord servers were indexable you'd have no issue
| with it.
| andybak wrote:
| I would still have some issues. I do find IRC archives much,
| much less valuable than more structured sources.
|
| But I'm picking my battles at this point in time. And the
| lack of indexing is the most critical flaw and one I think is
| immensely damaging to technical communities on those
| platforms.
| kontxt wrote:
| This is one reason I built https://kontxt.io for enterprise. It
| instantly connects people to specific page-parts to have
| localized conversations directly on the source of internal and
| external websites and digital documents, so everything is where
| you need it, when you need it, and anyone that joins later has
| full context.
| legerdemain wrote:
| The problem with "trying it with my team for one sprint" is that
| I now need to have a long conversation with legal. How will the
| service provider handle the content (discussions, screenshots,
| code snippets) that my team will upload? Do our current customer
| contracts contain any clauses that complicate the use of external
| discussion sites? In the unlikely event that the service offers
| the option to host it locally -- who is going to deploy it,
| configure it, set up security and authn/authz around it?
|
| The real answer is: just fucking use email. Why is email not one
| of the options suggested in the TFA? It's universally available,
| durable, allows long-form conversation and thoughtful
| deliberation, doesn't tell you that "someone is typing," and
| offers you the luxury of checking it at a set interval only a few
| times per day.
|
| The way many organizations have collectively abandoned email in
| favor of instant messaging is a travesty.
| mumblemumble wrote:
| There is really only one fundamental problem with email: its
| mechanism for managing who takes part in the conversation is
| all wrong for team communication. The symptoms of this problem
| are myriad: reply-all storms, cya-by-cc, replying to a 5 month
| old email rather than starting a new thread, fyi forwards, etc.
|
| Which isn't to say that all the advantages you list for email
| are not true. They are. It's just that most people will shy
| away from an otherwise-decent solution if it has terrible UX.
| throw14082020 wrote:
| There are many problems with email, not just one. Sure, we
| have SPF, DKIM, DMARC and S/MIME, but they're not used by
| most people. Especially the most important one, S/MIME (to
| encrypt your messages/ keep them private).
| selfhoster11 wrote:
| SPF, DKIM and DMARC are mandatory if you want to interact
| with the big email providers. In practice, you really want
| to set these up.
| fractionalhare wrote:
| I'm surprised if that's actually true. I would guess that
| most peoples' personal and work email accounts are managed
| through providers like Google or Microsoft, which do
| enforce all of those security protocols.
| GekkePrutser wrote:
| Their business products definitely don't enforce S/MIME
| by default (which is prohibitively difficult with
| external contacts anyway), and they _recommend_ to set up
| the things like SPF and DKIM. They usually don 't host
| your DNS so they can't do it for you (though they do tell
| you exactly what to set and provide a checker to see if
| you did it right!)
| swiley wrote:
| Most things I've seen require/enforce S/MIME.
| franga2000 wrote:
| All but the last are used by everyone as it is basically
| impossible for mail to be accepted reliably from an email
| server that doesn't have those set up correctly.
|
| As for S/MIME, certificates are a pain to deal with for
| most people and all they really care about is transport-
| level, not E2E encryption.
| hn_asker wrote:
| I hate it when I'm emailing someone with a deliberately long
| response and by the time I send, the thread has already gone
| on and I have to re-merge it.
| thesuitonym wrote:
| The obvious solution here is to not merge the whole thread
| into your email, instead including only the parts of the
| message that are directly relevant.
| ryandrake wrote:
| I'd like to see email clients offer a nice one-click
| "rebase on top of latest" button.
| tehjoker wrote:
| Dang. I never thought of email like that, but I wonder if
| email+git+UI would help for complex conversations.
| u801e wrote:
| You should look at the git mailing list. They actually
| send patches via email using the git format-patch and git
| send-email commands and have complex discussions around
| some of the patches.
| vinw wrote:
| Sounds a little bit like Google Wave.
| qwantim1 wrote:
| Wave seemed to me to be an unimaginative copy of other
| threaded comment implementations. The indentations seemed
| to waste valuable space on each page. Allowing anyone to
| edit anyone's post seemed insecure. If I hadn't known it
| was Google, I would've thought it to be a bad college
| project.
| paranoidrobot wrote:
| > Allowing anyone to edit anyone's post seemed insecure.
|
| Insecure in what manner?
|
| To me it's no more insecure than a VCS - sure, anyone
| could edit anyone else's code, but version history was
| always there.
| zikzak wrote:
| Now I'm sad.
| Liskni_si wrote:
| It kind of does: https://public-inbox.org/README.html
| It's used for LKML (and many other lists) archives:
| https://lore.kernel.org/lists.html
|
| (but it's read-only, there's no rebasing, people still
| use old-school e-mail clients)
| kingludite wrote:
| If it is worth the wait, announce your response or make a
| list of notes from which you can build the long response
| after things calm down.
| swiley wrote:
| Idk about the company you work at or projects you watch but
| most people know how to use mailing lists.
| extrememota wrote:
| What's wrong with mailing lists?
| brodie wrote:
| I can't speak to how good or effective it is, but the issues
| you mentioned are, I think, why the rust-lang community
| communicates through Zulip (instead of email, IRC, etc).
| fiddlerwoaroof wrote:
| Some of these are solved by things like a corporate NNTP
| server or mailing lists, right?
| Karunamon wrote:
| Some of them. In a previous job this was actually the
| solution my department ended up using - one box running
| Mailman, with various lists set up for things like special
| groups, people who need to receive alerts on specialized
| systems, stuff like that.
|
| The big win was the ability to rapidly subscribe and
| unsubscribe from lists as you needed them. The actual
| corporate email distro lists were handled by a dedicated IT
| team who insisted on tickets for everything, so most people
| just added filter rules to their inboxes instead of dealing
| with that mess.
| mumblemumble wrote:
| Not really, because it still doesn't give people
| sufficiently fine-grained control over demands on their
| attention.
|
| I think the ideal is the approach you get with discussion
| forums: Create a set of boards organized around topics, and
| place named, threaded conversations within those boards.
| People can join a board, in which case they will be able to
| get a list of new conversations related to that board's
| topic. They can then subscribe to just the conversations
| that interest them, and unsubscribe from ones that cease to
| be of interest.
| fiddlerwoaroof wrote:
| What's the difference between that sort of topics and
| news groups or mailing lists (with archives)? If I want
| information on something, subscribe; if I don't want
| information, unsubscribe: I can always follow/search the
| archive (or read digests)
| fennecfoxen wrote:
| The archive on NNTP is a first-class artifact that you
| can interact with in your newsreader via NNTP. You can do
| things like reply to old threads.
|
| The archive on a mailing list is a second-class artifact,
| typically hosted via HTTP, and usually people don't care
| about the quality of the archive's UX.
|
| The structural organization on NNTP is also a first-class
| artifact that everyone can refer to. A mailing list will
| go straight into everyone's inbox, with all their other
| mail, until they filter it away.
| pseudalopex wrote:
| IMAP and Exchange support archives and subscriptions.
| mumblemumble wrote:
| It's a second level of organization/subscription so that
| you can have more fine-grained control over how much you
| get spammed.
|
| News groups and mailing lists don't scale super well, in
| that, when you subscribe, you then get sent _everything_.
| Maybe not terrible for the 5-10 emails a day from my kid
| 's playgroup's email list, but absolutely awful for
| trying to keep up with a team of 100 people.
| twic wrote:
| In a newsgroup, you don't get sent anything. You can go
| to the group and see what's new. If there's a particular
| thread you're not interested, tell your news client to
| ignore it; if there's one you're particularly interested
| in, tell your news client to watch it:
|
| https://superuser.com/questions/458136/thunderbird-watch-
| or-...
| fiddlerwoaroof wrote:
| But the solution is exactly the same: create a new
| mailing list or newsgroup under the sort of circumstances
| where you'd add a topic to a forum or a channel in a
| Slack workspace. Open source projects, for example, will
| have foo-announce, foo-user, foo-devel, etc.
|
| Or use digests, mail filters/folders and a convention for
| tagging message subjects.
| mumblemumble wrote:
| So, that's the top level. The 2nd level would be more
| analogous to individual email threads within those
| groups.
|
| Once you get down to the individual conversation level,
| the fine-grained management bits you talk about are not
| good UX, they're band-aids for dealing with bad UX.
| fiddlerwoaroof wrote:
| Well, whether they're good or bad UX depends on
| assumptions about whether the second-level categorization
| is more meaningful organization-wide or on a user-by-user
| basis.
| dredmorbius wrote:
| _when you subscribe, you then get sent everything._
|
| 1. Killfiles
|
| 2. Contextually-scoped lists. If a topic is of limited
| concern yet intrusive, split it to a separate list.
| Moderation and management may be necessary. Technical
| teams should be scoped correspondingly. 100+ team members
| is excessive, 3-15 far more typical.
| pvorb wrote:
| But isn't that how the typical chat works? Where's the
| difference? At least that's similar to how the channels
| in my company are organized. The only difference might be
| that there's faster feedback in a chat and this leads to
| shorter posts/messages. But I haven't really used any
| forum software in the past decade, so I don't know if
| they don't have similar notifications and unread status
| icons on threads today.
| dsterry wrote:
| The problem with chat is the interruptive, thoughtless
| nature of it. In a large organization, you want
| durability that you won't get from chat.
|
| Internal Q&A, forums, and email all work because you can
| have long-form conversations on them but an important
| consideration is discoverability. If a new user wants to
| find out why X is true for some service, they'd better be
| able to do that without interrupting someone else.
| pas wrote:
| ... why ... not ... just mute it? Also Slack's entire
| business model builds on storing chat for long and it has
| a not too bad search. (Though I hate it, because it's
| slow. But GMail is slow too. Even Thunderbird is,
| probably because it touches IMAP or whatever for just
| displaying what I'm currently typing.
|
| VSCode is somehow fast despite running a bunch of
| linters/compilers/language-servers while typing, and
| similarly built on web tech, and ... in case of a
| JS/NodeJS/TS project it also handles tens/hundreds of
| thousands of files with ease, oh with full text search.)
| fpoling wrote:
| I have found Slack search at work just sucks. Whenever I
| tried it gives wrong priority to results. Plus questions
| and replies are too short and search can not pickup on
| context.
| randoramax wrote:
| Sounds like the approach taken by zulip. Check it out,
| it's a cool paradigm
| u678u wrote:
| Talk to your lawyer on this too. Our lawyer said emails with
| the lawyer in the conversation will have client attorney
| privilege, is not court admissible. I dont know about IM.
| dctoedt wrote:
| > _Our lawyer said emails with the lawyer in the conversation
| will have client attorney privilege, is not court
| admissible._
|
| That's too-sweeping a statement [0]:
|
| 1. Privilege attaches only to communications in the course of
| seeking legal advice.
|
| 2. Privilege is waived -- and thus the emails are
| discoverable by adversaries and admissible in court -- if
| people outside the decision-making group are in the
| conversation.
|
| 3. Privilege doesn't attach if the lawyer is functioning as a
| business executive or -advisor.
|
| 4. Privilege won't apply if the conversation is determined to
| be part of a crime or fraud.
|
| All that said: If a lawyer is involved in the conversation,
| then the company's litigation counsel will almost-
| automatically withhold the emails from being produced to an
| adversary and will list them on a "privilege log." That will
| often set up an ancillary court fight over whether the emails
| should be produced to the adversary. In that ancillary fight,
| the judge might end up reviewing the emails "in camera,"
| i.e., without the adversary seeing them, to decide whether
| the privilege applies -- and depending on the content of the
| withheld emails, having the judge read the emails could do as
| much damage to the company's case as anything.
|
| [0] https://www.nolo.com/legal-encyclopedia/attorney-client-
| priv...
| PaulHoule wrote:
| I worked at a B2B startup that had chronic problems w/ team
| members sharing documents in way that our customers thought
| were insecure. These were some of the biggest companies the
| world.
|
| I asked our biz dev guy who had been trained as a lawyer what
| to do and he told me to the same thing my accountant does with
| my taxes: email an encrypted PDF as an attachment and share the
| password by a separate channel.
| grok22 wrote:
| There are various services like WireDoc, ShareFile, etc, or
| even Mozilla's deprecated Firefox Send that canonized this
| (encrypt on one channel, share the password on a separate
| channel).
| withinboredom wrote:
| So, you're worried about this
|
| > I now need to have a long conversation with legal. How will
| the service provider handle the content (discussions,
| screenshots, code snippets) that my team will upload?
|
| Yet you suggest using email where it basically goes (or can be
| coerced to go) across the internet in plain-text where anyone
| can read it?
| dividedbyzero wrote:
| For email that conversation probably has taken place already.
| Also, lots of larger orgs have internal mail servers where
| this isn't even remotely true.
| alisonkisk wrote:
| Orgs have internal chat servers too.
| tidepod12 wrote:
| They aren't talking about internal chat. The article
| suggests trying out several third party SaaS discussion
| forums like Discourse/Carrot/Basecamp. It's unlikely most
| orgs have internal servers for these services. GP is
| pointing out that using these third party SaaS
| discussions forums is usually a nonstarter unless its
| first been pre-approved by legal (whereas email is almost
| certainly already approved).
| StavrosK wrote:
| Use Zulip. It solves all the problems that email has and also
| enables a bunch of other things you never knew you needed, like
| a sane model for browsing messages.
|
| It can even serve as real-time communication for #random and
| other such work-adjacent channels.
| bandris wrote:
| One problem/feature with email is that that new collagues do
| not see historical conversations. While the typical chatroom is
| searchable.
| ogre_codes wrote:
| > just fucking use email.
|
| I get you. But also:
|
| - Email doesn't retain context very well. If I dig back through
| my email I might have all of the emails in a thread, or maybe
| not.
|
| - Likewise, I can't send someone a link to a previous emailed
| conversation so it makes for poor documentation. I can forward
| an individual email, but not the comment in context.
|
| - Email is not easy to index or post up for reference. You
| can't link it from a wiki or other documentation for example.
|
| An internal mailing list with archiving would solve many of
| these issues and might be the best option, but it's a slightly
| different solution.
| [deleted]
| jaaron wrote:
| Mailing lists is the answer.
|
| - Achievable
|
| - Searchable
|
| - Linkable
|
| - Asynchronous
|
| - Accessible
|
| I like using Slack and we use it heavily with my team, but I
| agree it has issues.
|
| Meanwhile, we've been using mailing lists for established
| open source projects for years for all of these reasons.
| jshier wrote:
| Basecamp does this well, especially version 2, which
| integrated with email. With version 2 you could have topics
| in Basecamp which you could post directly do or email and it
| was searchable and linkable. It was even possible to post
| messages which were optionally emailed to clients, with their
| response becoming part of the thread history. Really the best
| of both worlds. Unfortunately they removed the email feature
| in Basecamp 3 (and my company upgraded) so we can't do that
| anymore, but older projects retain their history.
| ogre_codes wrote:
| Yeah, basecamp is pretty good at this. It is a pretty solid
| tool for building projects where having communications and
| documentation is intermixed is important.
|
| I didn't realized they removed the email piece... seems
| like a downgrade. Particularly for projects where you have
| fairly casual participants.
| fulafel wrote:
| We have IMAP URLs that address some of this.
| StavrosK wrote:
| I've commented this too much in this thread, but it's
| important: Zulip solves all this, has other advantages _and_
| a fast and extremely usable interface.
| duckmysick wrote:
| Is there anything in particular you don't like about Zulip?
| StavrosK wrote:
| The UI looks a bit outdated, but it's so fast and usable
| that I don't mind the aesthetics at all. It had some
| annoyances like the inability to move topics, bit AFAIK
| they solved that with the latest release.
|
| There isn't really much else I don't like about it, I
| never stop being amazed by how great the keyboard
| navigation is and how much the "river" of messages
| improves usability.
| duckmysick wrote:
| Thanks for the reply!
|
| I'm intrigued by the Guest option. Do you think it's a
| good way to communicate with the clients during longer
| projects?
| StavrosK wrote:
| Yeah, I've used that and it worked well (though I haven't
| used it extensively). As long as clients don't get
| confused by the UI, it's great, but it might take a bit
| of onboarding due to the different UI (though in its core
| it's just "Slack, but everything is a message thread").
| swiley wrote:
| This is why most replies include quotes.
|
| But yeah for groups you need a mailing list with an archive.
| It's still better than most IM apps IMO.
| ogre_codes wrote:
| Yes, but quotes are pretty limited in usefulness,
| particularly since different clients quote email
| differently and threads can get shredded quickly.
|
| > It's still better than most IM apps IMO.
|
| Yes, but you are trading one set of limits for another.
|
| It's a bit surprising that at this point we haven't
| standardized on something better than essentially IRC
| versus email.
|
| (Ok not surprising, frustrating)
| emidln wrote:
| Many organizations seem to use Outlook/Exchange and configure
| Exchange to make it difficult to use other mail clients (not
| enabling imap, not enabling caldav support so that a separate
| calendar and email client need to be used unless you use
| exchange, etc). Outlook is truly awful as a mail client and it
| would make one want to use anything else.
| Const-me wrote:
| I've been using Outlook for 20 years or so, and I generally
| like it. Lots of features, some of them are borderline
| unique. For instance, I wonder which e-mail clients allow to
| create complicated rules that are then running on the mail
| server as opposed to that client?
|
| The necessary conditions are (1) one needs to learn it. Too
| many features are making UX non-intuitive. (2) fast
| connection to e-mail server (3) ms exchange on the server,
| some features only work there.
| welterde wrote:
| That feature of course needs support server-side, but
| Thunderbird does have a Sieve add-on (in case sieve is
| enabled/available on the server). I don't use it myself,
| since I prefer to edit the sieve filter file directly
| instead of using a GUI for it, but the option is there.
| Const-me wrote:
| I prefer to right-click on e-mail and "create rule from
| message" from context menu. Also, the feature doesn't
| require any steps to configure, install or enable, it
| just works out of the box.
| welterde wrote:
| Unlike the Outlook+Exchange combination Sieve is an
| actual open standard (RFC 5228 & RFC 5804 & co) though
| that can be implemented by all mail servers and mail
| clients. Or is the Outlook+Exchange feature based on the
| same?
|
| Looking at the sieve website it seems quite a few desktop
| and web mail clients do have support for it either out of
| the box or as an add-on. So I would say that having this
| functionality is more on the "common" side than
| "borderline unique".
| Const-me wrote:
| > Or is the Outlook+Exchange feature based on the same?
|
| Not sure but unlikely. It works in Exchange for 20 years
| now, that RFC was written in 2008.
|
| > having this functionality is more on the "common" side
| than "borderline unique".
|
| The complete UX makes it borderline unique. Available out
| of the box, has a nice GUI, and is reliable in practice.
| p_l wrote:
| Exchange rules configured through Outlook are
| _omnipresent_.
|
| Sieve might be supported by many email clients, but is
| pretty much nonexistent in corporate email.
|
| Actually, if someone points me to one hosted email
| provider that does support it, I'd be glad - I was
| wondering about trying it out but nobody supports it.
| bchanudet wrote:
| I recently switched some of my email addresses to Migadu.
| I haven't tested it yet but they apparently offer Sieve
| support.
| legerdemain wrote:
| So you're saying you'd rather lose all the productivity
| benefits of a solution that's not instant messaging than use
| Outlook? Powerful stance!
| TheSpiceIsLife wrote:
| Is it really that bad?
|
| I'm just a dumb machine operator that uses Outlook at work,
| Fastmail for myself, and Gmail because I'm an idiot too, and
| really can't tell the difference.
| nobody9999 wrote:
| >I'm just a dumb machine operator that uses Outlook at
| work, Fastmail for myself, and Gmail because I'm an idiot
| too, and really can't tell the difference.
|
| Install Thunderbird[0] and use it for a week. You'll be
| able to tell the difference _very_ quickly.
|
| [0] https://www.thunderbird.net
| jcrawfordor wrote:
| I'm a Thunderbird user, but I don't really think that
| there's a clear winner in that comparison. Outlook has
| features that Thunderbird has been missing for over a
| decade, like reliable send-in-background (and other
| database operations in background unlike Thunderbird that
| likes to interrupt you to ask permission) and a far more
| mature calendar product.
| indymike wrote:
| Not to mention replies listed in threads. You have to
| move sent messages to the inbox to get this to behave
| correctly in TB.
| Joe_Cool wrote:
| Right click -> open message in conversation
| nobody9999 wrote:
| >I'm a Thunderbird user, but I don't really think that
| there's a clear winner in that comparison. Outlook has
| features that Thunderbird has been missing for over a
| decade, like reliable send-in-background (and other
| database operations in background unlike Thunderbird that
| likes to interrupt you to ask permission) and a far more
| mature calendar product.
|
| A fair point. As someone who has used both Outlook
| (professionally) and Thunderbird (personally) for decades
| (IIRC, the oldest message in my Thunderbird email store
| is from 1996), calendaring in Thunderbird isn't as robust
| as in Outlook and some of the other weaknesses you
| mention are absolutely valid.
|
| However, I'd say that many of the advantages of Outlook
| that you mention are more related to better integration
| of Outlook into Exchange back ends than to the Outlook
| client.
|
| If Exchange had better IMAP support and appropriate
| plugins for Thunderbird, Thunderbird would be vastly
| superior to Outlook in most respects.
|
| As it is, Thunderbird is already vastly superior to _any_
| web-based MUA[0], including OWA[1].
|
| [0] https://en.wikipedia.org/wiki/Email_client
|
| [1] https://en.wikipedia.org/wiki/Outlook_on_the_web
|
| Edit: Clarified Outlook/Exchange integration vs. Outlook
| as client.
| jcrawfordor wrote:
| I tend to really harp on send-in-background because I
| view it as a _core feature_ of an MUA, but as far as I
| know it 's still hidden behind an about:config flag in
| Thunderbird because it has an excessive number of known
| bugs, and it's been this way for many years. Another
| ongoing pain with Thunderbird is the inability to switch
| between HTML and plaintext when composing a message.
| Outlook lets you do this, in Thunderbird you have to copy
| the message, discard it, start a new one in the right
| mode and paste.
|
| On the other hand, yes, Outlook Web Access is hilariously
| bad. It's hard to understand how Microsoft flubbed it so
| bad considering that their consumer outlook.com has a
| radically better webmail. Different teams, obviously, but
| you'd think they would have shared notes.
|
| All in all, it feels a lot to me like Microsoft had a
| really good MUA in 2003 and hasn't done much with it
| since, while Mozilla had a not-quite-done-yet MUA in 2003
| and hasn't done much with it since. Both feel bolted
| together out of spare parts but in a way that's
| subjectively a bit different.
| easton wrote:
| Outlook.com and the current version of OWA in Microsoft
| 365 are nearly the same. What are you still missing? (If
| you're on-prem still, you're probably running a much
| older version)
| bluGill wrote:
| Outlook takes to long to start up in the morning. If it
| could start instantly I'd walk into the conference room on-
| time, but instead I'm several minutes late. Now that I'm
| working from home it needs to get the chat client started
| instead, but the the end result is the same, if I'm not
| running early I'll be late to important early morning
| meetings. (my early morning meetings are with India, so
| they will quickly assume I'm not joining at all and head to
| their supper - timezones are such that the best time for
| everyone is my breakfast and their supper)
|
| Outlook also has been chasing the flat look fad which is
| against usability. Most of the others are too so it is hard
| to fault them, but I still wish they would have the guts to
| say this fad is wrong...
|
| Once they are all running and you are used to the ui quirks
| they all work well enough.
| selfhoster11 wrote:
| Outlook starts faster for me than Slack.
| GordonS wrote:
| There is something very wrong with your Outlook and/or
| Exchange install if it takes "several minutes" to start.
|
| I've used Outlook in several organisations over the
| years, and start time has always been in the order of
| 5-10s.
| berryjerry wrote:
| For me it takes less than 2 seconds to start up fully.
| Not sure what is wrong with you guy's computers. Maybe
| you need an SSD or more RAM.
| _4570 wrote:
| Took about 10 seconds. Using a mobile workstation with an
| SSD and 32GB of RAM. Maybe I should go for 64GB? :D
| wussboy wrote:
| It's the worst. Unless you have to use any of the other
| ones.
| Aeolun wrote:
| In terms of experience using the product, I feel the
| Fastmail client handily beats both outlook and gmail.
| TheSpiceIsLife wrote:
| I agree, it's the user experience I notice the least. It
| doesn't get in my way at all, and I don't recall it
| changing or if it has the changes have been so mild and
| consistent I haven't noticed.
| dumbfounder wrote:
| Those emails are only available to the users participating in
| them, and in some places are automatically deleted after a
| certain amount of time. The point of TFA is knowledge capture,
| and email isn't transparent enough for sharing knowledge.
| legerdemain wrote:
| Enter team aliases and topic-based distribution lists.
|
| Adding a distribution list to an email thread is almost
| exactly like choosing a Slack channel to type into, except
| you no longer have the mess of needing to share and re-share
| messages and threads across channels. You can just add
| multiple distribution lists.
|
| You can also subscribe and unsubscribe from distribution
| lists and set up filters for them, which is basically like
| joining and leaving Slack channels based on your interests,
| except it gives you much more control over what you want to
| read and when.
| powersnail wrote:
| This gives me an idea. What about setting up an archiving
| script?
|
| After a archive-worthy discussion in email, you forward the
| thread to "archivebot@my-company-domain.com". The script will
| parse the email chain and generate a static web page hosted
| on a local server.
| bluGill wrote:
| You don't want a bot to archive it. You want a human (or an
| AI smarter than what exists today) to create a summary.
|
| Everything you have in your archives will be taken out
| context, misinterpreted, used against you in court.
| Alex3917 wrote:
| > After a archive-worthy discussion in email, you forward
| the thread to "archivebot@my-company-domain.com". The
| script will parse the email chain and generate a static web
| page hosted on a local server.
|
| Unfortunately there isn't any such thing as "forwarding an
| email thread", at least not currently. If you hit the
| forward button in your email client it will only forward
| the last email in the thread, which sometimes contains the
| entire thread as quoted reply text, but only in situations
| where each person has only replied to the most recent email
| in the thread. Some email clients also truncated the quoted
| reply text after a certain number of messages, and it's not
| generally parsable.
|
| Our email archival product uses a G Suite add-on for this
| reason, which provides the same benefits as OAuth but works
| on a thread-by-thread basis. I think Outlook extensions
| work the same way, but I'm not 100% sure on that.
|
| Actually technically Gmail does have a little known
| "forward thread" button that's hidden in one of the
| dropdowns, but it doesn't work that well. (Which you'll see
| if you try it on any longer thread.)
| pwdisswordfish0 wrote:
| > Unfortunately there isn't any such thing as "forwarding
| an email thread"
|
| Mailing lists have for years offered mailing list
| archives that you can read directly in your client,
| exactly as if the messages had been hitting your inbox
| from the beginning. The bigger problem with email is that
| messages are not as easily _addressable_ , unlike links
| on the Web.
| Alex3917 wrote:
| > The bigger problem with email is that messages are not
| as easily addressable, unlike links on the Web.
|
| You can format email messages for display on the web and
| generate permalinks for each message. E.g. look at what
| we do for https://www.prettyfwd.com. I haven't yet added
| a JS snippet to autoscroll to a specific message if you
| pass it in the UUID for that message as a URL parameter,
| but it's been on my TODO list for a while.
|
| Example thread, where each message is formatted for the
| web and has a UUID:
| https://www.prettyfwd.com/t/5XVkc401RiCTO9hwsSRziQ
|
| The other problem with most mailing list archives is that
| they look terrible and have poor readability, poor SEO,
| and generally terrible lighthouse scores. Whereas I think
| we score perfect 100s across the board, albeit only 99 on
| mobile perf because we don't prerender.
| Alex3917 wrote:
| We made FWD:Everyone (https://www.fwdeveryone.com) for this
| exact problem. It works via a Gmail add-on, so you can upload
| an email thread after it's over without having to grant OAuth
| access to your inbox. It makes these threads taggable and
| searchable within your company, and formats them to make them
| look beautiful.
|
| The advantage over just copying everything to a mailing list
| is that most conversations aren't worth archiving, so having
| conversations be opt-in after the fact keeps the signal-to-
| noise ratio much higher than it would otherwise be.
|
| We're still a very small platform, but since we're completely
| bootstrapped and grew 34x year-over-year in the past year,
| we're not going anywhere. :-)
| acjohnson55 wrote:
| Hi Alex! Glad FWD:Everyone is still going strong. I'm still
| waiting for it to become the dominant way of presenting
| email correspondence in media, like embedded tweets :)
| Aeolun wrote:
| Trying to have sensible conversations in an enterprise email
| client, where 90% of the messages are just garbage is basically
| impossible for me.
| slykar wrote:
| I'm not sure what you mean by the universal availability of the
| email. It has the same deploy/configure/security issues any
| other tool has. It's even worse, because you can send email to
| "outsiders" unless certain rules are in place. The UX is bad
| and depends on email clients.
| NationalPark wrote:
| Email isn't searchable by people who weren't on the threads. In
| an org that uses IM well (they exist!) the chat system actually
| becomes sort of like a wiki, except a lot more helpful.
| [deleted]
| eagsalazar2 wrote:
| Except you can only find stuff by spelunking with search,
| hoping you hit on the right set of keywords and then
| scrolling through a jumbled mess of hits. Wikis are organized
| and have navigation. Also being at a company that uses email
| _and_ Slack, I will say it is very very rare that anyone
| actually uses Slack to search for conversations they weren 't
| in. Email has other weaknesses of course but in general I
| agree with the point that Slack is actually worse in many use
| cases.
| swiley wrote:
| >the chat system actually becomes sort of like a wiki
|
| That sounds horrible and very fragile.
| NationalPark wrote:
| Absolutely, it is. It's still miles above every single
| corporate wiki I've tried to use. Your milage may vary.
| africanboy wrote:
| > Email isn't searchable by people who weren't on the threads
|
| Chats have the same problem: they aren't searchable by people
| who weren't in them.
|
| meanwhile https://lkml.org/
| harikb wrote:
| One cannot search channels one is not part of. Don't forget
| channels. Not everything happens on #general and #random.
|
| Also, even if I am part of the channel, there is no way I can
| search and locate what I want without knowing the right
| keyword to search for. Sure, the information is all there,
| but that only ads to the frustration. Search interfaces in
| Slack & all are very limited / too broad.
| gregmac wrote:
| If someone told me "that is documented in the chat channel,
| just search", my response would be "ok. So it's not
| documented."
|
| Even with the best organization (old content deleted), I
| don't want to wade through the conversations about it or all
| the other noise. Chat is temporal, the discussion about
| something like "should x be updated" is immediately
| irrelevant after the decision is made.
| NationalPark wrote:
| That's just not true, Slack in particular is quite
| searchable. Anyway, weren't we talking about email, which
| is even _less_ searchable?
| bluGill wrote:
| Your point is valid, but not exactly correct. I don't want
| to know just what was decided, but why. Often I will come
| back to "should x be updated" again and again. Knowing the
| factors in the last decision is very important. More than
| once I've pushed to update x and had someone say "we can't
| for good reasons that I forget". Often I've spent weeks
| redoing the discussion before someone remembers/discovers
| why we can't do the update and we all go "whoa, I'm glad we
| didn't do that". Other times we discover/remember why we
| couldn't update and they are for reasons that no longer
| apply and so we do the update. Still other times we never
| discover any reason why we shouldn't update. Last sometimes
| we discover why we shouldn't have updated after it is too
| late and we have a mess to undo while backing out the
| update.
|
| The important part is we know why a decision was made. Chat
| logs are not a good archive because there is too much to
| sort thought that isn't relevant. Better than nothing, but
| what is really needed is an effort to document why in a
| place the right people will find it when they need to know.
| gregmac wrote:
| While I fully agree about the need to record reasoning,
| my approach is to summarize and put it in either wiki or
| a ticket. Future me doesn't want to read a long chat or
| email thread (whether it was one I was involved with or
| not), and I assume no one else does either.
| kmano8 wrote:
| Eh, for the golden path, sure (say, having a service
| documented).
|
| Slack search for <insert error name here> is high-value in
| historical context that's tough to replicate elsewhere. All
| at once, you learn if anyone's ever asked about the error
| before, and if so, see the conversation on resolution.
| jayd16 wrote:
| And email solves that? Or you are suggesting both chat and
| email do not solve the issue?
| gregmac wrote:
| Yes, I'm saying neither chat nor email solve this issue.
|
| Email is far worse, in fact, because:
|
| * Everyone has a unique view
|
| * Unless there are lots of cc-everyone style emails, you
| might not even have anything to find. (And cc-everyone
| sucks for 100 other reasons.)
|
| * You can't find anything predating the start of your
| employment
|
| The biggest issue with searching both chat and email is
| the absence of a result doesn't help: it's possible it
| was a private chat, or an email chain that you weren't a
| part of, but there's no way to tell.
|
| (Side note: A very locked-down wiki isn't any better, but
| that's a conscious decision rather than default.)
| pseudalopex wrote:
| Mailing lists exist.
| twobitshifter wrote:
| Mailing lists are not heavily used outside of free
| software. In the corporate world I've never had a project
| provide a mailing list to be used for discussions.
| pseudalopex wrote:
| Tools exist even if you don't use them.
|
| Many companies use Outlook groups. Those are mailing
| lists.
| twobitshifter wrote:
| Not in the sense that they're searchable / archived on a
| listserv.
| Footkerchief wrote:
| Mailing lists (aka Google Groups if you're on GSuite) allow
| retroactive access.
|
| That said, none of my employers have ever made effective use
| of this. I don't think open communication is an instinct that
| most people have.
| DoofusOfDeath wrote:
| > The real answer is: just fucking use email.
|
| I know of at least one large company that forcibly deletes
| emails older than N months, as part of their legal retention
| policy. (I'm assuming it means _non-retention_ to limit
| exposure to lawsuits.)
|
| That would be problematic for persistent documentation.
| munchbunny wrote:
| That sounds like a pathological case. How many companies
| actually do that?
| Spooky23 wrote:
| Usually that varies by legal department.
|
| Attorneys who sue or investigate people for a living want
| everything forever, and those who get sued want to delete
| email before it arrives.
|
| Email is a great way to get in trouble, as people tend to
| say dumb things, even about things that they have nothing
| to do with!
| res0nat0r wrote:
| Most Fortune 500 companies have a document retention policy
| that every employee needs to read the generic training
| video/documents on when getting hired and agree to.
|
| This sets a general policy of deleting documents/emails/etc
| after $X days. This is really a CYA policy to purge old
| conversations if a big lawsuit comes down asking for
| document retention in relation to some scandal, and if its
| older than $X days you're covered since your standard legal
| process was followed.
| eecks wrote:
| What is CYA in CYA policy?
| grzm wrote:
| cover your ass.
| sumtechguy wrote:
| Also depending on industry you may by law need to delete
| things.
| oasisbob wrote:
| Many, at least in the US. It's not just companies,
| government agencies also have similar needs due to sunshine
| and open-access laws.
|
| The alternative to having a document retention policy is to
| just have employees delete things in an arbitrary manner.
| It's not just CYA for leaving inconvenient doc lying
| around, it's also to ensure the proper retention in the
| event of a preservation order or public records request.
|
| Some companies go way further than others. One place I
| worked included "notes of a personal nature (eg, birthday
| cards)" in the retention policy and let us keep them for a
| week or two before destruction.
| benhurmarcel wrote:
| That's weird, my company has the opposite policy. Nothing
| can be deleted. Employees can delete emails on their
| side, but the server keeps a copy of every email
| indefinitely in a "vault". That's for legal purposes
| apparently.
| legerdemain wrote:
| I'm willing to bet money that for every company that deletes
| emails older than some age also deletes Slack messages, and
| deletes then _sooner_.
|
| I speak as someone who worked for a company where email got
| archived and then deleted after 6 months, and currently works
| at a company where everyone only uses Slack, and Slack is
| purged after 30 days.
| flerchin wrote:
| Our email has a 90 day retention window, and Slack is
| permanent. We're the largest in our industry.
| KirillPanov wrote:
| Have your Slack chats been subpoenaed yet?
|
| If not, you are very lucky that you are being sued by
| people with incompetent attorneys.
| legerdemain wrote:
| Cool! Where should I send bet money?
| flerchin wrote:
| Mozilla or EFF, your choice. :-D
| legerdemain wrote:
| Excellent, $25 sent to EFF!
| fencepost wrote:
| Do the people who wrote the email policy know that Slack
| is permanent? That sounds like the kind of thing that
| could _easily_ be not-understood by legal.
| KirillPanov wrote:
| Yeah this policy mismatch definitely seems like a "nobody
| in legal has noticed yet".
|
| They're gonna notice _real quick_ the next time they get
| sued by somebody clueful enough to subpoena that
| goldmine.
| grok22 wrote:
| Isn't that just a company policy? At some-point, the
| lawyers will get clued-in and require that even on Slack
| and other company-wide chat there be a limited retention
| window!
| [deleted]
| duckmysick wrote:
| The legal retention policy itself looks persistent. How is it
| documented?
| astrobe_ wrote:
| If they do store persistent documentation in emails, the
| problem lies somewhere between the chair and the keyboard.
|
| Actually, forced deletion - if users are aware of it of
| course - is likely to sanitize everyone's practice. Email
| ain't a backup tool.
|
| That's symptomatic of people doing the most silly things and
| then blame the failures on their tools.
| grumple wrote:
| Is this the part where we pretend your organization doesn't
| already use something like a ticketing service, wiki, etc? I
| find it hard to believe you don't have any sort of tool to post
| information already. If it's true, run.
| tabbott wrote:
| Slack and all its clones are based on the chat room model,
| which structurally has the problem described in this article
| (and many others for productivity, such as wasting attention).
| Fundamentally, the chatroom model pioneered by IRC is poor for
| asynchronous communication because you can't sustain temporally
| overlapping conversations in a channel.
|
| However, you can't "just use email" -- Email's threading model
| is great for asynchronous work, but it is poor for synchronous
| communication and also doesn't support modern features that
| make it easier to communicate ideas efficiently (shared
| history, markdown formatting, image previews, emoji reactions,
| etc.). It's essential to be able to have (semi)synchronous
| written conversations with people you're working with,
| especially if you don't want to spend your days burning out on
| video calls.
|
| This is why we created Zulip -- it's designed as a real-time
| communication tool with email's threading model and all the
| nice features of modern chat apps that email lacks. And the
| reading user experience is actually a lot better than email,
| because Zulip provides is designed with the goal of saving time
| when prioritizing, skimming, reading, and replying to
| conversations. It's also 100% open source software (not open
| core!).
| twobitshifter wrote:
| Zulip sounds a lot like a modernized bulletin board/forum.
| It's interesting how we keep coming back to the same ideas
| again and again.
| dsr_ wrote:
| We've been using self-hosted Zulip for about 18 months now,
| and it's exactly what our company needs.
|
| I have been recommending it right and left to people who
| don't need federation in their chat system. If there was a
| clear gateway to federation -- enabling a Matrix room as a
| Zulip Stream, for instance -- I would enthusiastically
| recommend it for everyone.
| StavrosK wrote:
| Same here. If you like email, Zulip is what you need.
| wryun wrote:
| You can also use something janky like matterbridge to link
| with other things (poorly). Depends on your use case for
| federation.
|
| https://github.com/42wim/matterbridge
| zxexz wrote:
| Zulip really hits the sweet spot for a communication tool.
| Especially with large amounts of users communicating across
| many different threads. The FHIR community "chatroom"[0] is a
| Zulip server and is indispensable for communication and
| knowledge building across thousands of users.
|
| [0] https://chat.fhir.org/#
| Noumenon72 wrote:
| I signed up for that to see what Zulip is like, but there
| are only 19 messages visible if you do that, so I shouldn't
| have bothered. It seems nice, I guess.
| Cyphase wrote:
| New users on Zulip instances get 20 unread messages by
| default - I guess you marked one read. The full history
| is available to you.
| thesuitonym wrote:
| I get that you're just trying to get your software out there,
| but your modern features that email doesn't support are just
| wrong.
|
| >shared history Not if you have a mailing list, and then
| going off the record is as easy as removing the mailing list
| from the CC field.
|
| >markdown formatting This is an implementation failure, not
| really a fundamental problem with email. There is no reason
| that email clients don't support markdown, except that nobody
| has ever wanted it. There was someone who made a utility to
| switch markdown to regular MIME email, but just as a proof of
| concept. It works.
|
| >Image previews I assume what you mean by this is an inline
| thumbnail that expands when you click on it? Again, there's
| nothing about email that prevents it, it's just the way email
| clients are. That could be fixed
|
| >emoji reactions Okay, that's fair, there's no way to do this
| in email, short of sending a single emoji back. On the other
| hand, I think everyone would agree that this is more of a
| nice to have feature, than a necessary one, and one that
| really only makes sense in the world of quick, back and forth
| chat programs.
|
| [1] https://begriffs.com/posts/2020-07-16-generating-mime-
| email....
| tharkun__ wrote:
| This. I mean I get that there are various different chat or
| chat/email hybrid solutions nowadays that are competing
| with each other.
|
| Personally though I have nothing to complain about with
| slack. It has threading. It only has one level threading
| but that might actually be a good thing because we slack
| with non tech people too. One thread is sometimes hard for
| them to grasp. Make that a regular threading model and they
| will utterly get lost. You can see how that completely
| breaks down with emails in most places.
|
| We use slack both for synchronous and asynchronous
| communication. It's all about the culture and what people
| expect. Not really different from email. Remember the
| people that send you another email if you didn't answer
| their first one after 5 minutes?
|
| Group chats you can just link to in a ticket instead of
| having to paste and reformat from a large email
| conversation? Priceless!
|
| Markdown is not necessarily required. Most good email
| clients supported something like it, like actually
| displaying something like _this_ as italics or * bolded *.
| It's like saying "but your app doesn't do XML". Yeah well
| but it does JSON.
| ZephyrBlu wrote:
| > It only has one level threading but that might actually
| be a good thing because we slack with non tech people
| too. One thread is sometimes hard for them to grasp. Make
| that a regular threading model and they will utterly get
| lost
|
| Off topic, but this astounds me.
|
| Not trying to be elitist (I'm genuinely curious), but
| what is it about threads that throws them off?
|
| They seem unrelated to software. I would have thought
| "non-tech" people would also understand them.
| notretarded wrote:
| Something smells fishy. Oh yeah, it's your stale sales pitch.
| randallsquared wrote:
| From looking at the tour slides, a list of threads in the
| current chatroom (which Zulip calls "topics") does seem nice.
| I have often wished I could get Slack's all-new-thread-
| messages view filtered by channel.
| baxtr wrote:
| I just love well thought out emails. They can provide a lot
| clarity and be the basis for great discussions.
| sli wrote:
| Teams trying to enforce conversation threading in a (semi-)recent
| update pretty much put a halt to me and my coworkers using Teams
| for anything but voice for our morning sprints. Trying to follow
| even slow conversations in Teams is just way too much work, we
| instead chat on Telegram where chat works, you know, normally.
|
| Luckily we were never in the habit of tracking anything through
| chat, we stick to our issue tracker, but I can absolutely imagine
| the frustration we'd have felt after that change had we relied
| more heavily on chat.
| harrisonjackson wrote:
| I feel like most of these arguments can be made about in person
| meetings, too. Decision making needs to be documented somewhere
| regardless of the medium the conversation took place in.
|
| Live chat could maybe be a good place for that to happen but then
| someone needs to transfer that information into a tool designed
| for it. Just like you would if you had a meeting in a physical
| office.
|
| Now if the argument you want to make is that live chat is a bad
| place for those discussions to be had then that is different.
| Having worked at multiple fully-remote orgs with team members
| across many timezones and working different schedules I can agree
| live chat is not a great place for decision making to happen
| either.
|
| We use RFCs for async decision making when live chat, zooms, or
| in-person meetings aren't possible. It is slower since you are
| often waiting for a response until the next day, but I also find
| that the waiting time can be quite productive for other tasks and
| gives everyone more time to think about an issue.
| jamespitts wrote:
| I can't agree with this essay more.
|
| In the early days of the Ethereum community a lot of open
| coordination was done on reddit and a threaded forum hosted on
| Vanilla Forums. Initially for privacy and convenience, Skype,
| gitter, Discord, and Telegram began to take hold, and later
| became the primary place for open, public discussions and some
| decision-making as well.
|
| Threaded forums were still used but not central. It was a
| difficult era (but a lot of work still moved forward)! There
| emerged a kind of opacity due to ability to put attention on
| real-time threads, and IMO sometimes key voices were missing
| because they could not weigh in effectively.
|
| What changed the dynamic was the introduction of Discourse for
| the critical https://ethresear.ch discussions (set up by Virgil
| Griffith), and later https://ethereum-magicians.org (something I
| worked on). I was pushing for threaded at the time because of
| experiences I had here on Hacker News, reddit, and Slashdot. The
| person I collaborated with, Greg Colvin, wanted discussions like
| the threaded emails he was used to from the IETF and c++
| communities.
|
| We each knew from long experiences dealing with coordinating on
| tech issue remotely that the quality of the message is the
| medium.
|
| From those successful experiments / re-introductions, many teams
| then began to adopt and host Discourse instances. Later, DeFi
| picked it up for their governance / coordination discussions. Of
| course, real-time never went away, with more gravitating toward
| Telegram and Discord. But tracing the emerging thinking, hashing
| out differences on what to do, and re-activating stale
| discussions improved a lot.
|
| Threaded discussions are a core part of the community and work
| again.
| jamespitts wrote:
| I should also add two more important pieces to this:
|
| 1. In-person meetings and real-time calls have been a major
| part of the work. There is an agenda and very good notes are
| taken during these sessions (https://github.com/ethereum/pm).
| The calls have been essential for coordinating in a more formal
| setting and to get a feel for when consensus is achieved on a
| particular topic or proposal.
|
| What threaded forums later added was the ability for others to
| get involved in the discussion, particularly those who are not
| core developers or not able to attend.
|
| 2. Another important medium has been GitHub issues (e.g.
| https://github.com/ethereum/EIPs/issues/2315). Proposals are
| submitted as a PR and, earlier in the evolution of the
| governance process, many people would comment on them. These
| were not ideal due the flat nature of the format.
|
| What generally changed on GitHub issues in recent years was the
| encouraging of commenters to go to an external forum thread (ht
| tps://github.com/ethereum/EIPs/issues/2315#issuecomment-63...),
| leaving editors and authors to work out structural and other
| basic issues about a proposal in GitHub PR comments.
| j4yav wrote:
| Hey James, I'm building something along the same lines (I don't
| mean to be too spammy, so there's a link in my profile). It
| sounds a lot like what you're describing, but is being built
| from the ground up with this use case in mind.
|
| If nothing else I'd love to hear your feedback on what the most
| important features were and how you'd see a product like this
| evolving.
| zionic wrote:
| Thanks for all the work you've done for ETH! It has enriched my
| life greatly, and I am so excited to see where things go post-
| EIP1559 and 2.0!
| jamespitts wrote:
| You're welcome! I've only played a small part in this amazing
| phenomenon, mainly DevOps and community-organizing. But it
| has been amazing to do anything to help.
| andi999 wrote:
| Why today?
| zmmmmm wrote:
| This is actually about half of the business plan for companies
| like Slack. They want you to start using it on the basis it is
| ephemeral and then end up forced into paying for it because its
| just impossible for people to self-enforce that behaviour and not
| put information in there that needs to be retained.
| nmaleki wrote:
| I disagree with the conclusion of the article. Using this logic,
| one could say that you shouldn't speak about long term projects
| during voice call meetings. I agree that the quality of
| conversation drops when speaking over chat, but I would also say
| that communication increases. In my opinion, the increased
| communication more than makes up for the decline of message
| quality. I also feel that the author of this article is focused
| on Slack and Teams. Teams or a poorly implemented slack group can
| feel very disorganized, so I can see how the author came to the
| conclusion that they did.
|
| I disagree with the notion that "live chat is for the things that
| can get lost." If the chat platform you're using has advance
| search features, announcement channels, and message pinning you
| can easily find information you're looking for and, in my
| personal experience, this is usually faster than searching
| through emails. Despite their major privacy concerns, Discord has
| an amazing search implementation that I wish more developers
| would take inspiration from.
|
| Perhaps my view is influenced in part by my young age and by the
| culture of the company I work for, but I've always felt that
| people around me waste valuable time formulating emails to try to
| capture all edge cases of the reply. And usually this doesn't
| work, so multiple follow up emails over the course of an hour or
| even multiple hours are needed for something that could have been
| solved over text chat in mere minutes.
| kumarvvr wrote:
| > advance search features
|
| These are only useful if the chat content is suitable for
| search. Searching human conversation is much different from
| searching content crafted for long term usage.
|
| Also, there is the problem of what to search for. Many
| meaningful discussions may be lost in conversations that do not
| explicitly mention the topic but build upon the context.
|
| Great many ideas can be expressed in a few words and these may
| not be searchable.
| Jommi wrote:
| 200% agree. First time I've ever really felt young on HN
| before. People still waste time with internal email?
| woah wrote:
| How does this differ from spoken conversation?
| ISL wrote:
| There is never any expectation that spoken conversation might
| be archived/searchable/linkable-to-others.
| lazide wrote:
| Additionally in many locations (California), if that
| conversation is plausibly private (in person, in a hallway
| that isn't super busy or not in a cafe), it's illegal (albeit
| not perfectly) for it to be anything but ephemeral.
|
| People can of course reproduce what they think you said in
| another form, but that is always open for debate and
| challengeable. For better or worse.
| ajuc wrote:
| The funny thing is - it's easier to search and look at context in
| discord than in outlook or on wiki.
| pkrumins wrote:
| Twist (https://twist.com) solves this problem entirely. Instead
| of chat rooms where everyone chats about everything, it organizes
| discussions around tasks. Each task gets its own chat room. When
| you work on task X, you chat in task X's chat room. If you work
| on multiple tasks, you have multiple rooms, one per task. When
| you come back to a task, you just open the task's room and
| continue where you finished. When the task is finished, that
| conversation is pretty much over. It's a get things done product.
| No useless chatting and conversations don't overlap. Go use
| Twist!
| jadell wrote:
| Alternatively, in a tool that allows multiple channels, create a
| channel for the specific issue and invite the relevant people
| into it.
|
| The problem in the essay isn't chat rooms, it's having ONE chat
| room for all discussions. Branch off into another chat/channel
| and title that channel for the specific issue being discussed.
| lxe wrote:
| Slack has a search function that works pretty darn well.
| Conversations or context never get really lost. I wish we used it
| more.
| biztos wrote:
| It's probably an unpopular opinion, but the best online technical
| discussions I've ever seen in a company were done in Bugzilla.
|
| Every bug or feature request was a ticket. Tickets sometimes had
| quite long discussions.
|
| The advantages were:
|
| * Permanent, so you thought about what you wrote.
|
| * Public, same effect.
|
| * Sequential, so it was very rare for people to reply over each
| other.
|
| * Goal-oriented, you wanted to move towards resolution, which was
| then archived forever.
|
| * Opt-in for following, so you had some control over your
| attention.
|
| * Available, so you could search and see old attachments etc etc.
|
| * Safe, Local, easily self-hosted and backed up.
|
| * Customizable, e.g. easy linking to the repo even if you change
| repos.
|
| The more things moved to various forms of the all-consuming
| Jirapoly, the attention sink of Slack, the anarchy of mail+chat,
| the less useful and (importantly) the less _productive_ these
| conversations became.
| u678u wrote:
| Nice I haven't seem bugzilla for a while now, it looks good
| maybe we can use to replace Jira.
| https://bugzilla.mozilla.org/home
| kogir wrote:
| Or, discuss in chat but make sure to end with a summary email
| detailing the relevant decisions. Maybe include a link to the
| chat so you can find it in the future.
| syntheticnature wrote:
| Funny thing, I've worked places where emails were deleted after
| 30 days but Slack was forever.
| LinuxBender wrote:
| Your admin can set retention per channel or per organization.
| MichaelApproved wrote:
| How often does that actually happen?
| [deleted]
| blakeburch wrote:
| When we were first growing our team out remotely, we really tried
| to emphasize this style of thinking. All decisions and larger
| discussions would need to be written down so the conversation
| could be easily referenced for long-term context - we chose
| Threads for this purpose. Any quick questions or one-off
| communication could live in Slack. Any documentation needed to
| live in Notion.
|
| Over time, our usage of Threads quickly decreased. If decisions
| needed to be made, we had a meeting to cover it. Meetings always
| had a few days notice with a written agenda and problem context
| so that everyone could think through their ideas beforehand. The
| end of a meeting usually resulted in a decision, which would then
| get documented in Notion for posterity. The documented decisions
| and reasoning would be circulated for approval by everyone that
| was a part of that meeting to verify that nothing of importance
| was missed. Once everyone approved, the decision was locked in.
|
| As our process developed, we found that the need for written
| back-and-forth on decisions was less necessary. Instead, when we
| identified that an issue needed to be solved, we identified the
| key components of the problem, gave everyone some thinking time,
| and knocked it out over the course of a call. We rarely need to
| revisit the decisions since we write out the reasoning
| afterwards.
|
| I still love the concept of having a tool specifically for
| asynchronous discussion. However, I think these tools assume that
| the conversation is the important part when in reality, the only
| part that matters is the decision and the reasoning. If you can
| get your team to document those, you'll be just fine.
| dionian wrote:
| > Anyone who takes the time to ponder and respond thoughtfully
| with context and explanation will find that they're too late.
|
| I think this is a reasonable point, however, is this really a
| problem with the medium itself?
| [deleted]
| keiferski wrote:
| _Despite the "asychronous" claim, you have to keep a steady eye
| on it and reply in realtime or the conversation will move on
| without you. Anyone who takes the time to ponder and respond
| thoughtfully with context and explanation will find that they're
| too late._
|
| I like the idea of a time-limited channel. You can only reply to
| it during the meeting, and up to 15 minutes after. Theoretically
| it would force everyone to communicate succinctly and not drag
| meetings on indefinitely over the course of a day.
|
| Alternatively, have a channel that only allows one message per
| hour. Call it #deep-thought. You'll really need to think about
| what to say before you write it down.
| j4yav wrote:
| I'm building a collaborative, timeboxed collaboration tool
| called AsyncGo at https://asyncgo.com. We are pre-launch but
| have a prototype, and if anyone here would like a demo or has
| any questions I'd be happy to answer.
|
| It's meant to replace chat and meetings with something designed
| to be connected with at your convenience, and then publishes
| the decisions and how they were reached to wherever your source
| of truth is (or we can act as your source of truth).
| eli wrote:
| There's a Slack plugin for time-limited channels from Postlight
| https://dashforslack.com/
| Karawebnetwork wrote:
| "Snapchat"-like, in the workplace.
| ve55 wrote:
| I have noticed a similiar issue when I was searching for
| technical support with some applications, and eventually I had to
| make a Discord account, join a given server on it, and then
| search its backlog to find my answer.
|
| The server was 'public' in that anyone could join it, but it will
| not be indexed by search engines, so I can't imagine how many
| other people were unable to find the solutions to their problems
| because they were spoken in a chat room and never posted on the
| 'public' Internet. Given the scale at which services like this
| operate (soon to be billions of users), this is a pretty big
| problem.
| sam1r wrote:
| Okay, but what about real time search history? That's not
| mentioned as a key. feature in the article.
|
| That's the whole point of not worrying about these lines without
| sufficient thought.
|
| Being able to query the past instanteously via live chats is
| vital.
|
| I see live transcripts via iMessage and live chats as a huge
| benefit -- your thoughts in real time, basically, shared
| externally without energy wasted verbally.
|
| One of my biggest regrets is not pro-actively hitting aim support
| right before mass account deletion post mortem acquisition by
| Verizon.
|
| Imagine scrolling back in time to your high school chats-- one
| can easily use that context to go back in time like Mac OS time
| machine.
|
| Put all of those time stamps in whatever format (t, chat service,
| message) on a visual calendar and you'll be able to do much more
| with your data. Including attachments.
| paulryanrogers wrote:
| My hope is most of my youthful chats have been forever
| destroyed. It's not a season I'd like to revisit.
| grimgrin wrote:
| hitting aim support for what? afaik they weren't holding onto
| aim chats. tho my memory is fuzzy here
| jayd16 wrote:
| I think an interesting difference between chat clients like Slack
| and email is this.
|
| With email every user must organize a single firehose of an
| inbox. Chat channels area already a default compartmentalization
| but beyond that, chat services default to shared organizational
| structures like channels and threads.
|
| In email each user must manage the conversations themselves
| through labels or what have you. In successful chat systems, you
| can passively benefit from the organization of others. Mailing
| lists help but aren't enough in their current, aging incarnation.
|
| It might be possible to disrupt the email space by recognizing
| and adopting these UX differences.
| Karawebnetwork wrote:
| I don't know, it is quite easy to search a well indexed chat for
| keywords in order to find important information.
| x86_64Ubuntu wrote:
| Sounds like people are trying to asymptotically approach email
| functionality without actually using email. I do agree that
| chat stuff has a place, but it seems like the new functionality
| is just being copy-and-pasted from current email functionality.
| happytoexplain wrote:
| Usually - but the cases where this is both well implemented and
| stores infinite history, or even very long history, is
| vanishingly rare.
| tspike wrote:
| Yeah, I think the real solution here is: let's make chat
| permanently archived and searchable. I find it more useful
| searching through Slack for old conversations around a topic
| than searching Confluence for the same.
| AndrewUnmuted wrote:
| But aren't these both pretty terrible tools or storing
| information?
|
| Slack is an attempt at legitimizing and organizing stream-of-
| consciousness. It has short feedback loops and therefore
| cannot communicate deep research, novel concepts, nor well-
| cited evidence.
|
| This is the wrong way to bring the tools of the consumer to
| the enterprise. Nobody asked for this chat tool - Slack is
| something sold to somebody who doesn't want to worry about
| something, not somebody who wants to do something well with
| low attrition.
| have_faith wrote:
| I think part of the problem is not all conversations are
| obviously 'short and shallow' or 'long and broad'. What starts
| out casual might unearth something that needs going into deeper,
| and going in deep on something might not have results worth
| documenting yet.
|
| To me this points out a gap in our software for knowledge
| archival. The closest concept Slack has is "pinning" a message to
| a channel, which has very limited use for this. Really what you
| want is to be able to have a conversation with someone in any
| manner (casual or formal meeting) and be able to easily extract
| the conclusions and decisions made into a different location,
| ideally through an easily discoverable UI in the software already
| being used.
|
| In an ideal world my chat software has knowledge of the projects
| I'm working on (through some protocol to something else that acts
| as a source of truth) and I can select a message/file upload in
| chat and tell it to archive it against a project. It can easily
| fill in the details for me about who made this decision and when.
| Ability to effortlessly organise information arising from a
| connversation should a priority I think, this might remove the
| need for having seperate software depending on how "deep" you
| think a conversation is going to be.
| fwip wrote:
| I know that AI is a pile of buzzwords, but.... is this
| something we could train AI to do reasonably well? A flow like
| "click button and highlight conversation start/end" and it
| picks out the relevant messages and tries to generate a set of
| takeaways? (and allows user to edit them before saving).
| have_faith wrote:
| AI (or some primitive concept of...) could be useful in some
| aspect, perhaps for sugggesting tags or categories the
| information looks like it could belong to. Actually
| extracting the "facts and takeaways" sounds very hard but
| then I'm not a linguist so maybe there are methods.
| ajsharp wrote:
| There's a great rule of thumb for workplace communication mediums
| I saw long ago. It was something like this:
|
| - Email: Not urgent. Expected response: ~1 day. - Chat: Somewhat
| urgent. Expected response: < 1 hour. - Text: Shit is on fire.
| Expected response: Immediate.
|
| Building on the points OP makes re the problems thinking one line
| at a time in chat, in this little mental model there's a whole
| lot of daylight between email and chat. And there's lots of
| problems with email that make it not a great communication medium
| for semi-urgent things.
|
| My sense is that we need a better primitive inside chat platforms
| to differentiate between "this is important and we need to have
| this discussion now" and something closer to email-ish pace.
| pottertheotter wrote:
| That's an interesting perspective. To me, if it's urgent,
| better be a phone call. I definitely don't see a text as
| urgent.
| GekkePrutser wrote:
| I have to agree with this. When we started using MS Teams, it
| worked really well to replace person to person chats, email etc..
|
| But since it's become commonplace, it's become a crapbucket of
| stuff that I can't find anything back in. I have too many
| channels, too many teams (and you can't opt in to channels like
| you can on Slack, you have to join them all). And the search
| function is even worse than Outlook's. It's all just too
| unstructured. Even if I search for someone's name plus a keyword
| I know it's there it can't find it back for me.
|
| Such an app (not just Teams) is just not the right tool for
| everything related to communication, even though Microsoft is
| pushing it as exactly that.
|
| A forum though is too '2000' for me. I would see more in a
| managed wiki, provided people can stomach working in a structured
| way. Enforcing that will be an issue but it will result in a
| beautiful oracle of information. I've seen it happen before (and
| I've seen it fail many more times, sadly).
| [deleted]
| kingludite wrote:
| I don't know what to call it but some kind of training course, a
| spec or some other conditioning seems needed to get the best out
| of email. If the participants know 10 basic things like how and
| where to insert their responses and do not add 100 graphical
| signatures to each mail it gets 1000 times more wonderful and
| enjoyable. Long form doesn't become all that desirable that way.
| (It seems forums played a major role teaching how to quote to and
| gmail did a good job making it impossible.) Even on HN we rarely
| see quotation go on for more than one level.
|
| <- your comment never goes here
|
| > > > > person 1 original message paragraph 1
|
| > > > person 2 first response to paragraph 1
|
| > > person 1 response to person 2 first response
|
| > person 2 response to 1's response
|
| <- your comment goes here (the context is still paragraph 1,
| anything about this goes here not some place else)
|
| > > > > person 1 original message paragraph 2
|
| > > > person 2 response to paragraph 2
|
| > > person 1 response to above
|
| > person 3 response to above
|
| <- your comment about p2 goes here
|
| > > > person 2 elaborates
|
| > > 1 responds
|
| > 3 responds
|
| <- your comment on p2's elaboration goes here
|
| <- if it cant fit the 3 previous topics it goes here.
| twobitshifter wrote:
| Interestingly, outlook supports changing colors to help with
| inline replies and putting your name at the start of your
| online reply. I am the only person I have ever seen use that
| feature. Outlook.com no longer has the option.
| mullingitover wrote:
| Slack isn't a bunch of chat rooms, it's a database _disguised as
| a bunch of chat rooms_. I 've never had a problem pulling up some
| random conversation from three years ago as long as I remember
| the general topic.
|
| In that regard it's no different than using email, everything is
| indexed and you're just searching a different database.
| omosubi wrote:
| use JIRA as an internal stackoverflow :D
| LinuxBender wrote:
| In fact Atlassian have a module for this that plugs into
| Confluence which looks and feels a lot like SO. Trying to find
| the module name. It might just be called "Questions". I think
| this is the one we use [1]
|
| [1] - https://marketplace.atlassian.com/apps/1217080/questions-
| ans...
| omosubi wrote:
| that'll only work if the module name also makes confluence
| search usable
| LinuxBender wrote:
| Yes, their search leaves a lot of room for improvement. I
| am only suggesting it for the folks that are already using
| it.
| grahamjpark wrote:
| If you're into Cal Newport, he's got a new book coming out that
| seems related:
|
| https://bookshop.org/books/a-world-without-email-reimagining...
| u678u wrote:
| Cal Newport has a new book coming out every few weeks. Usually
| its 90% of the last one with a different target audience. :)
| hawktheslayer wrote:
| I like the concept of declaring bankruptcy on chats. I've done
| this on email more times than I'd like to admit.
| jodrellblank wrote:
| I dislike the concept; take Anki the spaced repetition learning
| system as an example for comparison: you add in some flashcards
| around a topic you want to learn and remember, and it prompts
| you to work through the cards you are most likely to forget.
| One failure mode is that you don't bother checking it for a few
| days, and suddenly there's a ton of cards to work through and
| it's overwhelming and you don't want to or can't spare the
| time, the next day there's even more they pile up until you
| "declare bankruptcy" on them.
|
| But your memory doesn't magically work better after declaring
| bankruptcy, if you imagine Anki is approximately correct about
| when you'll forget things then /not/ going through those cards
| means forgetting things you said you wanted to remember. That's
| a fundamental problem that should be addressed - you desire to
| remember more things than you have space in your life to
| sustainably commit to. Reset and restart is one way forward,
| but it's not a way out; presumably some of the things you
| wanted to remember are more important than others, and you're
| leaving it completely to chance which survive the reset and
| restart. If none are important then don't restart. If it's only
| for fun and that's not fun, it's not working well.
|
| To bring it back to email, the idea is "if I declare
| bankruptcy, the important things will come back again
| eventually". Things other people think are important will come
| back - using other people's brains to track the tasks which
| aren't good at that and are busy with other things - while
| throwing out the computer which is extremely good at record
| keeping - so good it's showing you the overwhelming amount of
| information you /actually have/ personally requested, or
| organisationally been subscribed to. If it's too much for one
| brain then it's too much. If it's too much irrelevant or
| redundant, then the organisation systems or tools are broken.
|
| If the response to that is to throw it all out and reset then
| it stays being too much, too irrelevent, too broken,
| indefinitely, for everyone. It's covering over the symptoms to
| avoid addressing the sickness. It's a trip to the ER to have
| your stomach pumped so you can go back to binge drinking from
| the firehose instead of going to rehab and making difficult
| changes, it's a part of our hoarding culture that's so widely
| supported in this thread, a part of the obesity crisis,
| information addiction, and panic in the face of mortality, and
| all those unrelated (but related really) things.
|
| "If I just do everything, know everything, have everything, eat
| everything, keep records of everything, I'll maximise my life
| experiences and save myself from {unspecified future horror
| {eventually death}}".
|
| There's an amount of work an employee can reasonably,
| practically, pragmatically do, and computer systems we have
| developed which are /completely incapable/ of helping us track
| and prioritise that, but /absolutely fantastic/ and
| overwhelming us with nonsense trivia and redundant messaging
| noise and tasks nobody is going to do that are socially unable
| to be dropped but are actually going to be kicked down the road
| until they don't matter. It's an awful system we've built where
| "declaring bankruptcy" on the messages we (individually or
| collectively) have to be involved in is a consideration at all.
| But if that is the way forward, it shouldn't be a guilty
| pleasure that you don't want to admit; evolution has an
| aggressive reaper function to cull all but the most fit, if
| we're going to adopt that, we should wholeheartedly do it
| openly and enthusiastically - any job which isn't worth
| remembering by brain can be wiped off the system after X days,
| no harm no foul. The combination of "too much" and "archived
| forever" is killer in the bad way.
|
| (How many people have left their jobs just to trigger this
| reaper function? If it was overwhelming the employee, the next
| employee won't have to deal with it, fresh start for both
| leaver and position).
| [deleted]
| andrenotgiant wrote:
| It sounds like the author was mostly thinking about INTERNAL
| discussion, but I think the real tragedy is in using chat like
| Slack for your public customer community forum.
|
| Think of all the knowledge and employee-time locked away in the
| scrollback of a chat based community forum.
|
| Better to have chat for informal community discussion, but when
| someone asks a question that others in your community might find
| useful in the future, politely direct them to post it in a more
| permanent (read: accessible via google search) medium.
| Sodman wrote:
| My experience so far with companies that operate in this
| manner, has been something like:
|
| 1) Community member asks question.
|
| 2A) Answer is already in documentation, which can be easily
| linked to.
|
| Or
|
| 2B) Can be answered in-line, with an action item to add
| clarification/more details to the docs.
|
| This feels like a pretty scalable solution for the most part.
| If there are still recurring questions you might want to look
| at the discoverability/layout of your docs, but usually I've
| found that other community members start linking each other to
| docs if the same question comes up again and again.
| the_arun wrote:
| I agree with the concern author is expressing. Usually, we do not
| start conversations leading to a decision/important, but it
| evolves into useful discussion. Onus is on us to move that
| convo/thread to GitHub issue & socialize it there. May be that is
| what author is hinting.
| getitstraight wrote:
| Better yet, stop using shitware like Slack, Matrix, etc, where
| all the data is kept locked behind closed doors ("in the cloud")
| and you can only access it through a 500 MB bloated shitware app
| that drags your 8 core workstation to a crawl.
|
| IRC sucks, but it sure beats the alternative. AIM or other
| Pidgin-based alternatives wouldn't be too bad either, if you had
| your own private server with everything logged.
|
| _Edit, because I 'm a really shitty commentator, apparently, who
| isn't allowed to post any more today:_
|
| No, _your_ comment was completely tangential to the content of
| _my_ post.
|
| "Live chat" as it's currently implemented and widely used, a la
| IRC, Slack, etc, certainly has its downfalls, much of which can
| be mitigated however by logging to disk, with a quality search
| engine to index it.
|
| Look at all the "alternatives" this guy is suggesting. It's
| basically "switch to a forum instead of chat." Most of the
| suggestions are proprietary, closed junk. Not exactly a smart
| formula for long data retention.
|
| He lists all these advantages of forums, and yet seems to have
| overlooked the advantage of chat, which is precisely that it
| gives a direct connection to someone, rather than having to wait
| a day or a week for a response.
|
| Better advice would be to use IRC (or other locallly hosted, open
| source alternative) for your team, but use discipline in your
| conversations so that you don't bloat the chat log with a bunch
| of chatter that makes searching it harder. Then perhaps designate
| certain persons to organize and summarize the proceedings so they
| are more easily referenced.
|
| There certainly can be better improvements in chat, but "just
| switch to a forum" isn't it.
| galkk wrote:
| It is like saying "drop windows/mac and use arch linux"
| whalesalad wrote:
| this is completely tangential to the content of the post
| svnpenn wrote:
| There's no such thing as "completely tangential". Something
| is either tangential, or it's not.
|
| Perhaps you should read a dictionary before your next attempt
| at "forum police".
| ChrisMarshallNY wrote:
| I've never been much of a fan of realtime chats.
|
| Heck, I even had a personal policy of never scheduling regular
| meetings (they all needed to be "as-needed").
|
| However, I worked for a Japanese company, so regular meetings
| were a part of my life; whether or not I liked it.
|
| I prefer "store and forward" communication (email is the classic
| form). Working for a Japanese company actually helped, there, as
| it was damn near impossible to have realtime chats with Tokyo.
|
| If I use Slack that way, I do miss stuff in noisy channels, but
| I've learned to live with it (so have people I work with).
| asimjalis wrote:
| Biggest use case for using chat rooms for technical discussions:
| I can search through archives a year later and find valuable
| nuggets of information.
___________________________________________________________________
(page generated 2021-01-13 23:02 UTC)