[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 : 384 points
Date : 2021-01-12 19:09 UTC (3 hours 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.
| 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.
| 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.
| 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]
| 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.
| 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
| 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).
| 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.
| 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.
| a-dub wrote:
| it does, it was a conscious choice by management to turn
| retention down to 30 days. it was weird.
| 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.
| 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.)
| 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.
| 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.
| 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/
| 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.
| 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.
| 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.
| 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.
| 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).
| 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.
| swiley wrote:
| Idk about the company you work at or projects you watch but
| most people know how to use mailing lists.
| 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.
| 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.
| 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.
| 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.
| 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]
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| wussboy wrote:
| It's the worst. Unless you have to use any of the other
| ones.
| 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 :)
| 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.
| 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.
| 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.
| 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.
| legerdemain wrote:
| Cool! Where should I send bet money?
| flerchin wrote:
| Mozilla or EFF, your choice. :-D
| legerdemain wrote:
| Excellent, $25 sent to EFF!
| 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]
| 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!).
| 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.
| 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.
| 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....
| baxtr wrote:
| I just love well thought out emails. They can provide a lot
| clarity and be the basis for great discussions.
| 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.
| 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!
| 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.
| 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.
| [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.
| 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]
| 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. :)
| [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".
___________________________________________________________________
(page generated 2021-01-12 23:00 UTC)