by Rob Malda
Team workflow is unique to every project. Slashdot’s workflow evolved over time to balance the nature of the community, the team, and the available engineering time
We realized early on that we had to have real-time team communication. Email was nice for a “paper” trail, but the nature of most real time news is that what matters is in the moment a few hours might as well have been last year.
Back in the early 2000s, we experimented with voice chats (using services like Ventrillo and Teamspeak), but we found IRC worked the best. (Today you would almost certainly use Slack.) We all left our clients open 24/7, so when one of us returned from the bathroom, bedroom, or even a vacation, we could scan back and be caught up on the most recent musings. Since our team was almost totally distributed, we didn’t have watercooler discussions in meatspace that were unheard by the remotes.
We maintained three chat rooms: one for coders, one for everyone, and one known as “-cooler” where our most passionate ( offtopic) discussions could take place. These meta discussions about Slashdot material were fantastic, but typically had nothing to do with the actual actions the editorial staff would take.
We used a ‘bot’ in our IRC channels to handle a few general updates useful to the whole team. It alerted us to new articles, and gave us warnings about databases that were getting bogged down. The nice thing about these notices is that the whole team learned together. A writer might not be able to do anything about some system restarting, but he would at least be aware that now would be a good time to get a cup of coffee, or if a reader complained about a performance problem, two seconds later, there would be a ready explanation from the bot.
More difficult was the custom engineering we engaged in to keep our team connected. The IRC bot was mostly a labor of love by Chris “Pudge” Nandor, but the core Slashdot platform (once available as an opensource project to anyone willing to try to install it… a small number of people actually did) had countless features designed to keep the team in the loop.
Slashdot is a highly curated community of user-submitted articles approved by editors. The Slashdot story submission process started typically with a story created by a user. The editor workflow therefore revolved around “The Submissions Bin.” The vast majority of submissions could quickly be rejected for any number of reasons (Boring, Offtopic, Nonsense, Old), but a few dozen might hang around for hours. We thought of these as “Maybe” submissions.
We tried different tactics for dealing with insight on these stories, but it was clear that real-time chat like IRC, or even the IRC backlog didn’t work well for commentary on the Maybes. It was far too easy to miss a note on a story from a couple hours back that happened to be mingled in the logs with a discussion about an unrelated item.
So we tied a simple text field to each submission, for attaching notes. These would be displayed prominently on list views containing messages like “this story seems fishy” or “didn’t we post this last week?” or “this is a stupid lie that keeps getting resubmitted”. These messages were only visible internally to our team. If one editor dropped offline or stepped out for a cup of coffee, there was no way that another team member would miss out on these notes. A more detailed discussion might occur in IRC with interested parties, but at the very least, the red flag couldn’t be missed.
This method extended to users and how we moderated. A routine problem our editorial team encountered was one we referred to as ‘Shills’. These were users who represented a specific, typically commercial interest or publication. Most of the major online publications employed several. Their actions would range from the completely fair (submitting an appropriate story for consideration by the editorial team) to the downright malicious (downvoting a story from publication B to increase the probability that the editorial staff would select a similar story from publication A).
Some users would identify themselves clearly, by incorporating the name of the sponsoring publication into their nickname, or by noting an affiliation in a comment or signature. In the early days, we would simply know most of them by nickname – the internet was a much smaller place 20 years ago. But as time went on, our platform needed to make sure we were all aware of who was representing whom. I never had any problem with a user self promoting anything, but my tolerance stopped when you stepped on the competition.
And so we then added note fields to users, which was displayed clearly to the editors throughout the story editing process. If one editor discovered a pattern indicating an affiliation from a submitter, they would research this by stepping back through the user’s submission history. If they learned that Bob had made 58 submissions in a row of stories from bobby.com on Tuesday, an editor on vacation would be guaranteed to be aware when they encountered Bob the following Monday.
The trick to making this work well was to make sure that the minimum amount of critical information was being displayed in exactly the right place, using exactly the right tool. An email from half an hour ago might not yet be read. A chat from 30 minutes ago might vanish. It was essential that the wisdom of each editor not be lost during the changing of the guard that occurred throughout the day.
Photo: Brocken Inaglory, CC BY-SA 3.0, via Wikimedia Commons
