Issue system

David Mason and Mai Hoang are working to develop an editing issue system that would document necessary changes to various levels of content.

Why this functionality matters

Newspapers do an ample amount of editing on a daily basis. Such editing is done on internal documents, such as a in-house stylebook or police contacts or for content that goes out to the public, such as blogs and stories. In our discussions we determined the following challenges:

• Editors are dealing with multiple layers of content. At one time, it use to be that a newspaper would edit a story at the end of the day. Now newspapers deal with multiple types of content throughout the day including breaking news updates, blogs and then the traditional story at the end of the day.
• Internal documents are not updated. At Mai's newspaper for example, the in-house stylebook is two years old. I don't think it's so much that it isn't a priority, as other content tend to demand more attention.
• Most newspapers, particularity small and mid-sized ones, are short staffed. Reporters are often dealing with multiple pieces of content at the same time. Though it is a myth to do "more with less," it is important to find ways to be more efficient in the editing process.

Therefore the method was developing a wiki-based system that would list and track necessary editing changes.

Features of this functionality

• In-line editing task annotations. Instead of waiting for the editor to complete editing a story, an editor can go and flag changes (tasks) that need to be made. For example, if the task is to fill holes of information, the editor can go ahead and make those edit requests. The reporter could begin editing those aspects of the story while the editor continues to edit the story. The reporter could also note when he or she completes the necessary edited tasks.
• Prioritization of editing. The system would provide a page for reporters and editors to see the priority of those tasks.
• The ability to directly import the information from the wiki to any content management system. (Ideally, it would be nice if the wiki and the content management system was one in the same, but there is an understand that this isn't always the case.)
• The ability to document necessary follow up to a story or other piece of content.

What's been done so far

• The focus right now is the first two features, in-line editing task annotations and the prioritization of those tasks.
• David, who is very skilled at wiki, has worked on providing the infrastructure for these two features.
• David has worked with Mai to determine how these annotations can work within her existing work flow.
• Mai has had the opportunity to test out the system. David provided a short writing sample for Mai to edit. Mai in turn put her edits on the writing system.
• Mai did a follow-up discussion with David to talk about the challenges of the system. (Upfront learning of wiki syntax being one of the major issues. The other issue is how to most effectively use this system under almost real-time, fast paced deadlines.

What's next

Mai and David will continue to work on the tasks annotations and the priority of those annotations. Once those two features have worked, we will begin work on integrating other features.