This resonated well with me. I've always preferred email to chat, for many of the reasons cited in the article.
The trouble is, it's too far to the right. Some people don't respond for days. So we have tools with instant response expectations, and ones with variable expectations. Nothing with clear "within a day" expectations. Email used to be that way, until too many peed in that pool.
> Nothing with clear "within a day" expectations. Email used to be that way, until too many peed in that pool.
Slack, then Mattermost, solved that for us. Our email inboxes became crowded with banter, notifications, as well as info that should be tracked in a centralised place. It was a mess because email became a kitchen sink.
So now we use GitLab for most of the serious "this better be tracked" stuff, Mattermost both for the off- and on-topic live chat, and email takes back its natural place when interacting with third parties (those we didn't onboard on GitLab), reply-soon-enough, and notifications (including GitLab ones, which thus covers "reply-soon-enough+should-be-tracked" in a seamless way).
The key point is having the three tools together, personally configured as each user sees fit WRT notifications, allows for each tool to blend with each other over the gradient of possible use cases.
> Nothing with clear "within a day" expectations. Email used to be that way, until too many peed in that pool.
This is pretty much purely a social issue, and should be set by the management / work culture directly. Nobody can force you to reply to an e-mail any more than they can force you to reply to a Slack message.
Because in private, I try to push as much communication as possible through e-mail exactly so that I don't have to reply to anyone within 24 hours if I don't feel like it.
Unfortunately, it spans farther than inside the company. There's suppliers, outside counsel, partners, customers, etc. Voice for that sort of thing is dying too, because people either disable, or don't check voice mail.
I'm in an enterprise environment; the death of voice is greatly exaggerated. Voicemails? Not dead, just moved to text transcription delivered to my email from unified messaging.
Not dead for you. Too many of my colleagues and customers ignore it for me to use it. I can't keep track of which ones still listen to them.
Edit: Yes, it's a people issue . Wasn't trying to frame it as a tech one. We've ended up with two paths, reply now (slack, other IM, sms) or reply/maybe/never (email/voice). For people reasons, as you say.
There have been some attempts to use tech to solve it. Google's inbox, for example, might have helped unclutter so you could see what was important.
FWIW, in my country voicemail was probably dead on arrival. I'm yet to know someone who actually relied on them and treated them as anything more than an annoyance (if someone calls you and gets redirected to voicemail, they usually disconnect, but sometimes that leaves an "emtpy" message which you'll get later notified about). About the only use of voicemail I've ever experienced is that in American movies (protagonist listening to their voicemail backlog on their landline seems to be a common trope).
Slack is great when used as modern irc. But many teams try to replace email, issue tracker, ci, deploy all into slack and it becomes too much. People in our company made all these integrations to paste back emojis into GitHub comments, to create a new ci run and all sorts of things. Honestly, It was all very irritating to be in love with a tool this way. Sort of like forcing emacs to do everything (peace be upon emacs).
Thankfully it all came to a head when the buggy deploy bot made a broken deploy and we started using it just for plain chat and moved to free plan because we didn't want history on purpose.
Started probably with "Twitch Plays Pokemon", "Twich Plays/Does X" means thousands and thousands of people trying to simultaneously control a single-user game or application, with the whole thing being live-streamed.
> Sort of like forcing emacs to do everything (peace be upon emacs).
Yeah, except that people force Emacs to do everything because it's more convenient and efficient to do things this way. Things within Emacs are much more interoperable than anything else[0] in your operating system - both by having a no-bullshit, powerful[1] and consistent UI, and by being designed for interoperability and third-party extension from the get-go. Basically everything that deals mostly with text - and that includes IRC, issue tracking, e-mail, etc. - is better done in Emacs than in a standalone (or God forbid, web) tool.
Emacs OS maybe a weird and unpopular mindset, but it's a very practical mindset.
--
[0] - besides maybe terminal utilities, but we're talking applications with UI here.
[1] - all the weird shortcuts doing text magic work on everything in Emacs, so the investment pays off across everything you do within this environment.
> [1] - all the weird shortcuts doing text magic work on everything in Emacs, so the investment pays off across everything you do within this environment.
People want their muscle memory to follow them. Emacs solved it by pulling applications into Emacs. Vim/vi "solved" it by virtue of applications adapting vim keyboard conventions. "Solved" in quotes not because it's not a solution, but because the solution wasn't implemented in Vim, but in each application where a developer wanted to use their muscle memory.
An excellent compromise solution is apps that use readline: you can use either editor's muscle memory.
I have an addon installed in firefox that lets me use my Vim muscle memory in firefox.
It's true only for the very basics. Applications adopting vim shortcuts, or using readline, take on the most rudimentary navigation shortcuts. But that's not what I meant about weird shortcuts doing text magic.
Consider e.g. e-mail in Emacs[0] as on this screenshot: [1]. Both the list and the message you see on this screenshot are read-only UI, like in any terminal-oriented app. Except that I can navigate through and manipulate them with all my usual Emacs shortcuts, including:
- using incremental search to find a message of interest
- doing regular Emacs region selection over multiple messages, to apply the same action to many of them
- semantic expansion of selection
- using selection to spawn multiple cursors at appropriate places, and then apply the same actions under each cursor
- using M-x occur to do a "grep" on contents
- using regexp highlighting to highlight lines or words matching regexp
- using narrowing and widening to display only a subsection of the e-mail list
... and many more, and all those examples didn't even touch e-mail-mode-specific things! That's just text-editing shortcuts over text UI! Those are all the things you'll have in your muscle memory as a proficient Emacs user, and you can use them everywhere - be it IRC, terminal, a REPL, list of e-mails, etc.
In this way, "Emacs OS" UX is superior to my "host" OS UX (be it Windows or Linux), because I can perform all those actions in an unified way, without breaking my flow - and I have access to very advanced/complex actions (plus the ability to write my own, or download them from the Internet).
Oh, and even if read-only, the UI is still text, so I can just mark it all, copy over to another buffer, and process it as if I was working with a plaintext file. No need for scrapping anything.
EDIT: changed "expansion" to "widening" in the point about narrowing.
Narrowing and widening to be precise. As many Emacs features, narrowing seems useless at first, but it has surprisingly many uses. Especially with `expand-region` installed: no matter where is my point, I can quickly select current block, narrow the buffer to it and start using bulk-edit tools, like `iedit` or `multiple-cursors` while being sure that they won't affect other parts of a file.
> In this way, "Emacs OS" UX is superior to my "host" OS UX (be it Windows or Linux), because I can perform all those actions in an unified way, without breaking my flow
I still use the combo of urxvt+tmux+zsh though. I could probably get most of the same features with Emacs+Elscreen+Eshell+Auto-Complete/Company, but setting it all up seemed like a lot of unnecessary work, while I had my `.tmux.conf` and `.zshrc` already configured before switching to Emacs. I'd still love to switch to Emacs for terminal emulation, but all the available options right now (from eshell to ansi-term) lack some important features I'd rather still have.
Yes, narrowing and widening are the correct words for that :). Fixed, thanks!
I have the same thoughts about available terminal options; I'd love to use Emacs for my terminal, but unfortunately there are always corner cases that annoy me enough to keep me stuck to urxvt + fish.
Yeah. The customizability of a whole computing environment of Emacs is unparalleled, except by some Smalltalk or Common Lisp ones. From `defadvice` to dynamic scoping to `edebug` and `find-function`, everything in Emacs is optimized for extension development, from the tiniest 3-line long advice to N kloc full-fledged programs. And it got even better once I started using StumpWM, since now I can really control everything from inside Emacs (with window management accessible via SLIME/CommonLisp REPL) - no matter what it is, if I find something irritating I can disable or change it almost immediately. Pure bliss! :)
Yeah, StumpWM is great. There was this blog post I saw once which was very helpful for getting set up, but I can't find it (not very helpful, I know).
What's great is that the .stumpwm is just Lisp code (just like .emacs) and every window management function is available (just like in...Emacs). If there's an error somewhere, you get the full power of the condition/restart system, so your WM doesn't just crash, you can recover interactively.
And with quicklisp, there are so many Common Lisp libraries available, it becomes very easy to script StumpWM however you like...all without leaving Emacs or restarting the WM or anything inconvenient like that.
I feel like this philosophy (editing a program while it's running) isn't really found in non-Lisp languages. Which is such a shame, since I think it's really useful and cool.
Agree with the problems Jason identifies but not convinced by the solution: his suggestions basically rely on the crowd to "get it right" (or on draconian management to enforce rules).
By contrast I'm pretty sure if we could review Slacks internal documentation we'd find it's been built to be addictive by design: its intended purpose is to consume every second and minute you give it because that drives its growth and success.
I'm not convinced that there is meant to be an addictive design flow to Slack so much as it just facilitates familiar environments in a workplace environment. A lot of people treat Slack like a gussied up IRC client, and type and act just like they did when they were in their teens on IRC. Some enforcement of a culture is necessary or else it will devolve into people just spamming gifs and pictures, always with "okay guys, last one" tacked on as the person is looking for the next gif to post.
The idea of communication feedback as noted in Hiri is interesting, but I'm not sure it works well with a more spontaneous and instant communication medium like Slack; chat lets you do off-the-cuff responses. Sometimes it's a curt-but-true "check the documentation", other times it's a longer but quickly made wall of text. Likewise, typically we write differently when there's a larger audience than we do with it's just an email back and forth with a colleague; at my last job, I definitely took a different approach talking to my student employees who were there to learn than I did with my colleagues who should already have some foundational knowledge of the topic at hand.
I forget where it was said first, but anything you measure will impel a person to optimize his score on that metric. (taken from Harvard Business Review) Competing and/or contradictory metrics can cause a lot of difficulty in a chat environment like Slack which I think is meant to foster more spontanaeity than it is a specific style of communication. It is important to curb bad spontanaeity (e.g., aforementioned gif shitposting), but outside of general "avoid this" rules, too many and you start to make people feel nervous or unwilling to participate, especially since the weight of feedback is pretty great to many people; just look at how self-censoring "Likes" make people.
I wonder if Slack usage feedback is a valid case for bots e.g. for a chat that's suddenly very active involving multiple parties the bot might ask "I see this is a hot discussion? Should I invite you all to a video conference to discuss it?"
Are you running anti-tracker extensions? I am seeing the same thing in Firefox with Privacy Badger running. Apparently these kind of pages need images and other resources from medium.com, which is being detected as a potential tracker.
I run into the same problem in Chrome, using Privacy Badger. However, the Mercury Reader extension does a great job reformatting the page for readability.
This makes me curious, is group chat ever a win? Specifically the Slack variety where everyone or almost everyone is logged in and therefore any post by any person has the possibility of distracting everyone.
It seems like something more like personally messaging would solve the immediacy problem. Open a PM (Slack, FB Messenger, Hangouts), add the people you want to include in the discussion, start the conversation. Only those people are notified, if more needed to be added they can be added. That would seem like it would prevent more of the constant distraction part.
You only do that when you want EXACTLY those people to hear it - akin to booking a conference room to discuss something with a certain closed group.
Talking on a channel is more like talking aloud in a team room with one or two people, the other people are allowed to overhear and join if they have some input. Or they can put on their headphones or tell the noisy people to get a room or shut up.
With a team chat system you can just disable the notifications when you don't want to be disturbed and read the backlog afterwards (if you're so inclined). No need to tell anyone specifically to stfu. You can also be invited to the discussion with an @mention and you can immediately read the previous comments and join in without anyone having to spend 5-10 minutes re-explaining everything to you.
> Talking on a channel is more like talking aloud in a team room with one or two people
That's annoying enough on the real world. When an application not only makes it the default, but makes sure you are placed in a bunched of noisy rooms at the same time, it's bad.
There's no reason for "room" notifications to be enabled by default on any application.
First of all, we are a 100% remote team and everything important is captured in a ticket for us. Tickets are the "one true source" of goals and resolutions. Chat/email/phone are ancillary and all treated the same: they are a method to have a conversation. Any conversation must be summarized into a ticket if you want it actionable.
We use Hipchat, so I can't speak for slack, but notifications are only sent out if someone "requests" a notification like @all or @here (those not AFK) or @personName for an individual notification
Each team has their own room as well as a global company room and a social "hangout" room. If you want to catch up on things you are welcome to chime in later or add info to the room/ticket but you are not required if you aren't a stakeholder.
I am never distracted unless someone needs to distract me for an immediate need.
"But the reality is that tools encourage specific behaviors. A product is a series of design decisions with a specific outcome in mind. Yes, you can use tools as they weren’t intended, but most people follow the patterns suggested by the design."
Reminded me of "our writing tools are also working on our thoughts". Our brains are pretty plastic and will adapt to 'the rules of the game' and I imagine that these days, those rules are defined by the affordances provided by the software.
Sorry bit off-topic, but this caught my attention since english is my 2nd language... So I'm thinking that "Does group chat make you sweat?" sounds a bit better than "Is group chat making you sweat", but what about the meaning? (Haven't read the article yet)
The "Is group chat making you sweat" is using a verb form "continuous aspect" which not all languages have. It's more of a feeling of being in the middle of the situation, where "Does group chat make you sweat" is being asked before or after the activity. It's more of a subtle, stylistic choice though and the title could have been named with either of these sentences.
I know this is directed at slack but I've noticed the same thing on whatsapp, where, in my circles - anytime there's a `thing` involving more than two people it will become a whatsapp group chat before some people even kown they're involved in the `thing`. You can easily rack up dozens of whatsapp groups and even though they might not be business oriented they make me sweat socially for most of the reasons listed in the article.
That's just the tip of the iceberg though, since it seems like an almost natural instinct, at this point, to make a whatsapp group chat for everything. School group projects are also added to whatsapp groups and with these everything the author has listed is true. Probably even to a greater extent.
In one project I did a couple years ago our group never met physically for 99% of the tasks, all the meetings we needed to have happened over group chat - bearing all the problems listed in the article. I know for a fact that the resulting work was diminished because of this. Yet, people seem almost enthusiastic about transferring work to whatsapp.
I find it hard to accept that this is a real problem... Managing a business using only group chat just sounds incompetent. Even when I get together with a couple of buddies to do a project we will use a combination of communication/collaboration tools.
Even in my office I've never met anyone with a problem flipping between the correct communication technology for whatever task.
We switch pretty seamlessly between,
* Email (with Outlook's calendar feature for organising meetings).
* Face to face meetings, (formal/informal, presentations, etc)
* Instant Messaging for time wasting but also for quick answers too. Almost always 1-on-1.
* Telephone for awkward but super useful communication with field crew.
* Atlassian's Jira. This is a recent addition and directly addresses many of the flaws of using email for coordinating projects. There are probably heaps of similar solutions out there, but I am enjoying this one.
45 comments
[ 4.4 ms ] story [ 96.5 ms ] threadThe trouble is, it's too far to the right. Some people don't respond for days. So we have tools with instant response expectations, and ones with variable expectations. Nothing with clear "within a day" expectations. Email used to be that way, until too many peed in that pool.
Slack, then Mattermost, solved that for us. Our email inboxes became crowded with banter, notifications, as well as info that should be tracked in a centralised place. It was a mess because email became a kitchen sink.
So now we use GitLab for most of the serious "this better be tracked" stuff, Mattermost both for the off- and on-topic live chat, and email takes back its natural place when interacting with third parties (those we didn't onboard on GitLab), reply-soon-enough, and notifications (including GitLab ones, which thus covers "reply-soon-enough+should-be-tracked" in a seamless way).
The key point is having the three tools together, personally configured as each user sees fit WRT notifications, allows for each tool to blend with each other over the gradient of possible use cases.
This is pretty much purely a social issue, and should be set by the management / work culture directly. Nobody can force you to reply to an e-mail any more than they can force you to reply to a Slack message.
Because in private, I try to push as much communication as possible through e-mail exactly so that I don't have to reply to anyone within 24 hours if I don't feel like it.
Edit: Yes, it's a people issue . Wasn't trying to frame it as a tech one. We've ended up with two paths, reply now (slack, other IM, sms) or reply/maybe/never (email/voice). For people reasons, as you say.
There have been some attempts to use tech to solve it. Google's inbox, for example, might have helped unclutter so you could see what was important.
Thankfully it all came to a head when the buggy deploy bot made a broken deploy and we started using it just for plain chat and moved to free plan because we didn't want history on purpose.
Started probably with "Twitch Plays Pokemon", "Twich Plays/Does X" means thousands and thousands of people trying to simultaneously control a single-user game or application, with the whole thing being live-streamed.
Yeah history is actually cool, because you can forget to track, but it's too easy to say "oh it is in history search for it" ... ok./
> Sort of like forcing emacs to do everything (peace be upon emacs).
Yeah, except that people force Emacs to do everything because it's more convenient and efficient to do things this way. Things within Emacs are much more interoperable than anything else[0] in your operating system - both by having a no-bullshit, powerful[1] and consistent UI, and by being designed for interoperability and third-party extension from the get-go. Basically everything that deals mostly with text - and that includes IRC, issue tracking, e-mail, etc. - is better done in Emacs than in a standalone (or God forbid, web) tool.
Emacs OS maybe a weird and unpopular mindset, but it's a very practical mindset.
--
[0] - besides maybe terminal utilities, but we're talking applications with UI here.
[1] - all the weird shortcuts doing text magic work on everything in Emacs, so the investment pays off across everything you do within this environment.
People want their muscle memory to follow them. Emacs solved it by pulling applications into Emacs. Vim/vi "solved" it by virtue of applications adapting vim keyboard conventions. "Solved" in quotes not because it's not a solution, but because the solution wasn't implemented in Vim, but in each application where a developer wanted to use their muscle memory.
An excellent compromise solution is apps that use readline: you can use either editor's muscle memory.
I have an addon installed in firefox that lets me use my Vim muscle memory in firefox.
https://addons.mozilla.org/firefox/addon/vimfx
https://github.com/akhodakivskiy/VimFx
Consider e.g. e-mail in Emacs[0] as on this screenshot: [1]. Both the list and the message you see on this screenshot are read-only UI, like in any terminal-oriented app. Except that I can navigate through and manipulate them with all my usual Emacs shortcuts, including:
- using incremental search to find a message of interest
- doing regular Emacs region selection over multiple messages, to apply the same action to many of them
- semantic expansion of selection
- using selection to spawn multiple cursors at appropriate places, and then apply the same actions under each cursor
- using M-x occur to do a "grep" on contents
- using regexp highlighting to highlight lines or words matching regexp
- using narrowing and widening to display only a subsection of the e-mail list
... and many more, and all those examples didn't even touch e-mail-mode-specific things! That's just text-editing shortcuts over text UI! Those are all the things you'll have in your muscle memory as a proficient Emacs user, and you can use them everywhere - be it IRC, terminal, a REPL, list of e-mails, etc.
In this way, "Emacs OS" UX is superior to my "host" OS UX (be it Windows or Linux), because I can perform all those actions in an unified way, without breaking my flow - and I have access to very advanced/complex actions (plus the ability to write my own, or download them from the Internet).
Oh, and even if read-only, the UI is still text, so I can just mark it all, copy over to another buffer, and process it as if I was working with a plaintext file. No need for scrapping anything.
EDIT: changed "expansion" to "widening" in the point about narrowing.
--
[0] - which I just managed to get working, thanks to friendly HNers that responded to me here: https://news.ycombinator.com/item?id=14569833.
[1] - http://i.imgur.com/JpnxZSl.png
Narrowing and widening to be precise. As many Emacs features, narrowing seems useless at first, but it has surprisingly many uses. Especially with `expand-region` installed: no matter where is my point, I can quickly select current block, narrow the buffer to it and start using bulk-edit tools, like `iedit` or `multiple-cursors` while being sure that they won't affect other parts of a file.
> In this way, "Emacs OS" UX is superior to my "host" OS UX (be it Windows or Linux), because I can perform all those actions in an unified way, without breaking my flow
I still use the combo of urxvt+tmux+zsh though. I could probably get most of the same features with Emacs+Elscreen+Eshell+Auto-Complete/Company, but setting it all up seemed like a lot of unnecessary work, while I had my `.tmux.conf` and `.zshrc` already configured before switching to Emacs. I'd still love to switch to Emacs for terminal emulation, but all the available options right now (from eshell to ansi-term) lack some important features I'd rather still have.
I have the same thoughts about available terminal options; I'd love to use Emacs for my terminal, but unfortunately there are always corner cases that annoy me enough to keep me stuck to urxvt + fish.
What's great is that the .stumpwm is just Lisp code (just like .emacs) and every window management function is available (just like in...Emacs). If there's an error somewhere, you get the full power of the condition/restart system, so your WM doesn't just crash, you can recover interactively.
And with quicklisp, there are so many Common Lisp libraries available, it becomes very easy to script StumpWM however you like...all without leaving Emacs or restarting the WM or anything inconvenient like that.
I feel like this philosophy (editing a program while it's running) isn't really found in non-Lisp languages. Which is such a shame, since I think it's really useful and cool.
I am not sure if sarcasm or what. It's way worse then IRC because it's so damn slow.
I'd rather see something built from the ground up to get it right. Hiri for example ( https://www.hiri.com ) tries this for email - https://www.google.ch/amp/s/techcrunch.com/2016/06/07/hiri/a... - the product even includes features to rate colleagues emails and help them improve.
By contrast I'm pretty sure if we could review Slacks internal documentation we'd find it's been built to be addictive by design: its intended purpose is to consume every second and minute you give it because that drives its growth and success.
The idea of communication feedback as noted in Hiri is interesting, but I'm not sure it works well with a more spontaneous and instant communication medium like Slack; chat lets you do off-the-cuff responses. Sometimes it's a curt-but-true "check the documentation", other times it's a longer but quickly made wall of text. Likewise, typically we write differently when there's a larger audience than we do with it's just an email back and forth with a colleague; at my last job, I definitely took a different approach talking to my student employees who were there to learn than I did with my colleagues who should already have some foundational knowledge of the topic at hand.
I forget where it was said first, but anything you measure will impel a person to optimize his score on that metric. (taken from Harvard Business Review) Competing and/or contradictory metrics can cause a lot of difficulty in a chat environment like Slack which I think is meant to foster more spontanaeity than it is a specific style of communication. It is important to curb bad spontanaeity (e.g., aforementioned gif shitposting), but outside of general "avoid this" rules, too many and you start to make people feel nervous or unwilling to participate, especially since the weight of feedback is pretty great to many people; just look at how self-censoring "Likes" make people.
Chalk it up to defective website design.
It seems like something more like personally messaging would solve the immediacy problem. Open a PM (Slack, FB Messenger, Hangouts), add the people you want to include in the discussion, start the conversation. Only those people are notified, if more needed to be added they can be added. That would seem like it would prevent more of the constant distraction part.
Talking on a channel is more like talking aloud in a team room with one or two people, the other people are allowed to overhear and join if they have some input. Or they can put on their headphones or tell the noisy people to get a room or shut up.
With a team chat system you can just disable the notifications when you don't want to be disturbed and read the backlog afterwards (if you're so inclined). No need to tell anyone specifically to stfu. You can also be invited to the discussion with an @mention and you can immediately read the previous comments and join in without anyone having to spend 5-10 minutes re-explaining everything to you.
That's annoying enough on the real world. When an application not only makes it the default, but makes sure you are placed in a bunched of noisy rooms at the same time, it's bad.
There's no reason for "room" notifications to be enabled by default on any application.
We use Hipchat, so I can't speak for slack, but notifications are only sent out if someone "requests" a notification like @all or @here (those not AFK) or @personName for an individual notification
Each team has their own room as well as a global company room and a social "hangout" room. If you want to catch up on things you are welcome to chime in later or add info to the room/ticket but you are not required if you aren't a stakeholder.
I am never distracted unless someone needs to distract me for an immediate need.
https://news.ycombinator.com/item?id=11239614
"But the reality is that tools encourage specific behaviors. A product is a series of design decisions with a specific outcome in mind. Yes, you can use tools as they weren’t intended, but most people follow the patterns suggested by the design."
Reminded me of "our writing tools are also working on our thoughts". Our brains are pretty plastic and will adapt to 'the rules of the game' and I imagine that these days, those rules are defined by the affordances provided by the software.
That's just the tip of the iceberg though, since it seems like an almost natural instinct, at this point, to make a whatsapp group chat for everything. School group projects are also added to whatsapp groups and with these everything the author has listed is true. Probably even to a greater extent.
In one project I did a couple years ago our group never met physically for 99% of the tasks, all the meetings we needed to have happened over group chat - bearing all the problems listed in the article. I know for a fact that the resulting work was diminished because of this. Yet, people seem almost enthusiastic about transferring work to whatsapp.
Even in my office I've never met anyone with a problem flipping between the correct communication technology for whatever task.
We switch pretty seamlessly between,
* Email (with Outlook's calendar feature for organising meetings).
* Face to face meetings, (formal/informal, presentations, etc)
* Instant Messaging for time wasting but also for quick answers too. Almost always 1-on-1.
* Telephone for awkward but super useful communication with field crew.
* Atlassian's Jira. This is a recent addition and directly addresses many of the flaws of using email for coordinating projects. There are probably heaps of similar solutions out there, but I am enjoying this one.
The more channels the better!