Issue system

David Mason and Mai Hoang are working to develop an editing issue system that would document necessary edits made in stories and other types of written content.

Why this functionality matters

Newspaper editors deal with ample amount of editing on a daily basis. Editors will deal with everything from a blog entry to multi-day series. Editing is also done on internal documents, such as a in-house stylebook or police contacts. In our discussions we determined the following challenges:

• How can editors better deal 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.
• Most newspapers, particularity small and mid-sized ones, are short staffed. Related to point one, 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.
• The editing process is one of the key opportunities for reporters and editors to learn and develop. Unfortunately, in the rush of the 24-hour news cycle, editing has become more rushed. Is there a way to provide insight that can help both the editor and reporter improve? Also, is there a way to promote more front-end editing, which is where the editor discusses with the reporter at the beginning of the reporting process what is necessary for the story?

Out of these discussions we decided to develop a wiki-based system that would list and track the editing of content.

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. This creates more a collaboration rather than the traditional liner process of reporter hands in story - editor asks questions/revises - reporter makes the changes.
• 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 at the beginning of the reporting process what is desired for a story (story focus; people to interview; sides to cover). The system would also allow documentation of necessary follow for a story or other piece of content.
• Eventually, we would like to develop a system that would also allow different areas of the newspaper (i.e. online departments, advertising, etc.) to bring up issues and tasks to each other. For example, if an editor has a problem with the CMS, the editor would be able to log into the system and flag a problem.

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 developing wikis, 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. They include:
  • Upfront learning of wiki syntax. It might be a hard sell for older editors to learn code.
  • This system works great if there is plenty of editing time. It works great for a long-form project. But Mai expressed concern whether this system could handle content done in almost real-time, fast paced deadlines.

What's next

• The focus is to improve on the task annotations and the priority of those annotations:
  • David will continue to adjust the wiki infrastructure to address concerns.
  • Mai will continue to test those two features under different mock situations.
  • We will have feedback discussions based on those tests.
  • Repeat.

• Once those two features are working, we will begin work on integrating other features.