We started using Slack in February 2014. We’d always used chat systems, but I’m glad we [switched to Slack then] because changing a big system like that is difficult the larger the organization is, and we’ve grown a lot since then. I can’t imagine what it would be like to on-board everybody today.

On the editorial side, we use a few channels to organize the typical workflow of the newsroom, from assignments to edits to publication notifications. Most of the channels are for actual chat, but a few have more regimented systems: You go into the assignments channel and say, ‘here’s what I’m working on, how many words, when it’s likely to come in,’ so it’s visible to the rest of the newsroom that someone’s on the story.

We have a production channel that we use for editing, so when a story is ready for edit it’s placed in that channel, and an editor takes it.

When news stories are published, they automatically post into the production channel. We note there if the story’s been placed in our top queue of stories on the site, and if it’s been tweeted or sent out elsewhere, to keep everything organized.

In the last week, we’ve started doing some of those things using emoji reactions. [The ability to “fave” or “like” a message was a long-requested feature; Slack added a way to do this earlier this month, using emojis.] In order to keep things less messy, when editors claim a story, they use a specific emoji reaction — the fist, to show that they’re “grabbing” the edit. We use emojis to show that something’s been published and that we’ve dealt with its distribution.

It quickly became clear that this was really useful. The obvious downside to doing a lot of workflow things in a chat context is that it can get messy fast. Emoji reactions have helped add some structure to the workflow.

All the deployments of code to the site are made using Slack, by using what we call Qzbot within Slack, instead of doing it on GitHub.

We have lots of channels on the editorial side, including more specific ones like #edit-Africa, #edit-Tech, and #edit-Video. Over time we groom channels, because everybody who uses Slack a lot ends up with channel sprawl, and we want to make sure it doesn’t get too overwhelming that people miss important stuff.

But the messiness is mostly an advantage. It helps people figure out, over time, the way in which they want to organize themselves. In the last six months, I’ve had success running some projects using Slack. It compresses a lot of the stuff you might otherwise do in meetings into a Slack channel, so that information is visible to everyone it should be visible to, and it saves people time: They don’t necessarily have to meet but can stay updated on a project’s status.

Slack is one of the threads that holds our internationally distributed teams together. We use it to be incredibly productive and transparent, but also to foster team-building and camaraderie with remote colleagues. Some of our teams work on daily news deadlines, some on two-week product sprints, some through regular sales cycles, and some on a combination of those work styles. We use a mix of custom-built integrations, native Slack integrations and third-party services like Ifttt and Zapier to make the most of it.

On the editorial side, our Chorus Bot tells us when a new story has been published to a site, and who published it.

On the product side, we have a bot to tell us when code is being deployed to a relevant repository, and who deployed it.

Similarly, we have a bot that tells everyone when a new deploy to our publishing platform, Chorus, has been scheduled.

For a team like Editorial Products, which is very deadline-driven and heavily integrated with our newsrooms, Slack is an integral part of our process, with the help of Zapier. Every request for a new project gets submitted through a Google Form. That form makes a new Trello card in our incoming queue, which pings our Slack room. We also ping our Slack room when new comments, members, or attachments are added to Trello, or when a deadline gets updated.

Many teams integrate GitHub or FogBugz, so that conversation around specific bugs/features can happen in a structured way associated with a particular issue, but still be visible to everyone.

We store a lot of essential docs using our bot named “cfbot” (migrated over from our days on Campfire), so everyone can easily access things they need easily.

Across all of Vox Media, we also use cfbot for fun and useful non-work things. We can use it to replace faces in a photo with faces of people on our product team, or to grab funny GIFs, or to get poems we’ve stored, or congratulate new team members on joining our company, or to check the Metro status or the weather, among many other actions.

We use it across the whole digital squad, so we have channels for all the different sections within the team. We’re a big organization with offices in Miami and New York, Oakland and L.A. It’s a lot of people to keep track of, so Slack is kind of our national office in the cloud.

One of the things we’re interested in is what we’re calling “Slackalytics.” How can we put data on stuff that’s going on around the broader web in front of our writers, right in the middle of their workflow? Instead of people going to check Chartbeat, maybe we can just slide in a notification as they’re doing what they’re doing; maybe that alleviates some of that weird Chartbeat crack addiction. We’re trying to see if there are other things we can pull in from the wider web into Slack to help people know what they should be writing about.

The most difficult thing about Slack right now is there’s a real tradeoff between using private rooms for section teams and their editors to get work done, versus public rooms. We’re trying to have people default to doing their work in public, so teams can drop in and see what everyone is working on, but private conversations are okay. That’s the biggest question for us.

The cool thing about Slack is that it’s simultaneously synchronous and asynchronous. You can get immediate feedback on something, but if someone comes into the room later, they might be able to add something, whereas if you didn’t go to a [physical] meeting, you’re not going to be able to contribute later.

If someone’s going on vacation or their anniversary, or if they’re going to be away on a long weekend, we tell them to delete Slack from their phone because otherwise the temptation to check it is too great. Deleting the app really helps people disconnect, because it’s that addictive as a social experience.

If I could give one piece of advice to other media companies, it’s that they should be cool with people deleting the app.

In terms of a vivid, vibrant, virtual community that isn’t stodgily stuck in your Outlook inbox, Slack has been great. We have channels for the New York office and D.C. office. We have #Slate-Cute where people post pictures of their dogs and babies. We have much more tactical channels as well.

One of my favorite channels is a group called #Headlines-and-Framing. Any editor or writer can pop into the channel, offer the headline ideas they’re working through, and ask who has feedback. There are always people who have a few moments to hang out and workshop a line.

Another channel we have is #Whereabouts. People chime in in the morning and say, okay, I’ll be at my desk, or today I’m working from home, or does anybody have an office I can do an interview from at 11? You can just ignore the channel until you suddenly want to find someone.

We also have a channel called #Breaking-News. When someone posts in it, it pings the folks on staff who are responsible for managing our coverage of breaking news.

We have an editors’ channel where the editors at the magazine can touch base with each other. But we tend to use Slack more for coordination than for official decision-making. Because Slate is a big newsroom filled primarily with writers who are working fairly autonomously and directly with their editors, most decisions happen in a very decentralized way, and Slack becomes a nice place to just flag something.

It would be great if Slack could implement a proper away message or vacation notification. If you’re on vacation, is Slack something you have to check when you get back to your desk, or should it just be for real-time alerts and questions? That remains an open question here at Slate.

The whole notion of these newsroom chat tools was that they’d free you from the burden of email, this horrible thing that you have to check all the time; with chat, you were supposed to be able to do all things in real time. But, depending on how you use Slack, sometimes you just have two sets of things to check.

I work on The Times’ Digital Development and Strategy team, and we’re the main users of Slack in the organization. We started when the service was still in private beta, and immediately became paying customers when it was launched. I initiated our using the service, after being frustrated with other chat solutions that are generally forced upon you (Google chat, for one), and wanting more of an overview of what is going on across the team without having to have a stand-up meeting every morning.

We’ve grown our use of the service quite organically since we initially picked it up, and have only had a few “Slack sense checks” where we decided what our policy or rule on how something should be done is. We use the standard general/random channels as you would expect, but also have 34 others, with varying memberships. Some have basically the same number of people as in general, such as #Development, which contains the development team and their managers, but smaller teams have their own presence, such as #Data-Team, which is our data journalism unit.

We have channels for WordPress plugins we’ve built to track the issues coming through GitHub, which only have a few users. We have a #Conference channel, where a lot of users keep track of the one person who represents us in morning and afternoon news conference.

In many ways, Slack has totally removed the need for internal email inside the team, though outside the team we have few people taking it up — generally people that work with our team a lot. [It hasn’t just changed] our communications with each other, which now happen over Slack, but also things like GitHub notifications that now come over Slack, or build confirmations, or systems-reporting issues.

Slack helps alert everyone without the mess of mailing lists, and allows people to effectively catch up without having to be forwarded a long list, and then still remain included in the conversation. It’s a much more effective way to catch up and keep up. We’re a lot more public in our communications now, and people try, even though the nature of newspapers is against this, to talk in public channels as much as possible to keep everyone in the loop.

We’re planning to eventually get round to introducing Slack to more of the editorial staff. We’re thinking of working with the picture/graphics desks first, as they are often sending files to each other over email, and we think Slack’s benefits of the archive and multiuser awareness are more instantly visible for these kinds of workflow.

As far as features we wish Slack had: Out-of-office would be a key one. Better statistics. Better integration with documents. Slack should buy Quip and offer it as a single payment, in my opinion. The ability to create a private group for the discussion of a new product), and then launch it as a public channel. The ability to invite interns to channels without giving them the full archive.

Above anything else, I think, integration between teams. News UK has another Slack with our Technology department, and News Corp has Dow Jones and News Corp Australia. We all have our own instances and don’t really have a way of chatting between them, except via a [third-party technology] like Slackline.

I lead a distributed team of data journalists at AP. One of the primary reasons we started using Slack was to create a common space, an easy way to throw out a question or comment to the group, and while we frequently do bat around ideas there and offer opinions, I find that inevitably we hop on a Google Hangout to come to a final decision. I think the visual component of Hangouts gives us a better sense that we’ve reached consensus — or at least that everyone has been heard.

Because Slack communication can be asynchronous, it’s easier for a decision to slip past without everyone recognizing that it has been made. There’s a sort of decision whiplash that can result: either the topic has to be reopened later, or important considerations get left out.

Another time when we avoid Slack is when we’re discussing anything source-sensitive. Our investigative editors would rightly balk at using it for any conversation relating to stories on a number of sensitive topics. We have more secure communication channels for that work.

Slack helps avoid maddening email chains, and it gives us some possibilities for serendipitous conversations that didn’t exist with our other communication channels. I’ve hoped it would become a sort of virtual water cooler or break room. So far, it has been fairly focused, which is fine, as well. But as we become more comfortable tossing ideas around in Slack, I hope the conversation there can encompass a bit wider range.

We’ve also started to bring our colleagues into the Slack chats — both folks from the tech group and designers and front-end developers from our Interactives team. The latter simply couldn’t have happened while we were still using IRC.

We encourage the staff to disable Slack notifications, particularly for groups. At least in our work environment, we don’t need to be tethered to Slack all day. If it’s super important, someone will call you. Concealing notifications also adds a nice asynchronous feel to the Slack workflow, which helps us slow down and make more deliberate decisions. It lets it be more like email, almost. People can click into it when they want to check it, instead of it being this constant presence.

We have a Slack room connected directly to WordPress VIP, so every time we make a change on Thought Catalog or Shop Catalog, the staff is notified. This has been a real boon for us because writers and producers are in tune with the development roadmap and start to think about how technology can simplify their workflow, or make the site better for readers. It gets some of our writers to think like coders or product people. Features like this came directly from our editorial team, and so have hundreds of micro changes.