Editing Process

Introduction

The editing process describes those actions taken to edit a submission received from a community member into a suitable format for release as a story. Some of these actions are typical of any editing process (e.g. spell checking, reformatting etc) but other actions are less obvious, especially to the new or inexperienced editor. This section aims to assist those new to the editing process to find their feet and help them gain experience. However, there are probably as many ways to edit a submission as there are editors; this section only describes one method which has been proven over time to work but do not feel that you must follow this guide slavishly if you have a better system that works for you.

The standard of submission can vary greatly from a title and a single URL link, to a fully researched story which requires the minimum of effort on the part of the editor to prepare it for publication. Despite the Submission Guidelines, peoples' abilities differ and some are reluctant or unable to allocate sufficient time to fully prepare a submission. Nevertheless, it is the editor's responsibility to try to make a story out of what is given. In some cases this will prove to be impossible but, in the majority of instances, there will be enough to get the editor started although significantly more work will be necessary before a finished story is finally realised. Conversely, there may not be enough time for the editor to complete all the research necessary and (s)he must decide whether to hold the submission until sufficient time is available or delete the submission and move on to something more reasonable to work with.

The Role of the Editor

Introduction

The role of the editor is not as simple to define as one might initially imagine. (S)he must, of course, change what might be a simple submission into a reportable story that will appeal to at least a portion of the community, but there are several other task functions that are equally as important. The final aim is to provide a story that is both interesting and thought provoking thus encouraging as many of the community to read it and, hopefully, contribute further by adding to the discussion about it. However, the editor is also responsible for upholding the standards of the site in general, probably far more than any other member of the team that is working hard to keep the site active. (S)he is frequently the interface between the site and the community, and will also bear the brunt of much of the comment from the community when things are not going as well as they should. So, the task then is to identify how this can best be achieved.

Accurate, Balanced and Impartial Reporting

The first requirement is for an editor to provide accurate reporting which is also balanced and impartial. While it is unreasonable to expect an editor not to have strong opinions on at least some of the story topics, (s)he must ensure that such views do not express themselves in the stories that (s)he edits. Not everyone will share the same views and it is important that the editor does not abuse his or her position by slanting a story in such a way as to demonstrate a bias. Of course, the editor can always join in the subsequent discussion once a story is released and can express his or her views there as they deem fit. Some of the submissions that are received do themselves express a particular view or bias and, if possible, the editor should endeavour to find other links that provide contrasting or opposing viewpoints and include them in the story.

Filter Unwanted Material

Secondly, it is essential that each link in a submission is clicked and checked. This is important not only to ensure that the link is functional, but also to remove links to unwanted material such as political electioneering, pornography, blatent advertising (also known as 'slashvertisements') and off-topic items. Sometimes such links can be the result of an error but, more often than not, they are an intentional attempt by someone to try to defeat the editorial system and to successfully 'troll' the site. Usually, such material is submitted by an Anonymous Coward but it can also be as a result of a misguided attempt at humour by a recognised community member. All such links should be deleted. Remember that we aim to be a global site and, while we should not and cannot comply with the laws of every nation, religion, or regional group, material which is likely to be offensive and is irrelevant to the story should be removed.

Simple Understandable Summary

Finally, aim to write simple, understandable English at all times. The topics that we write about are often complex and technical but by writing in an easy and simple style the editor can make the subject matter more understandable. Leave terse technical writings for the articles that the story links to - and if you can provide several links examining the same subject at differing levels of complexity then you are more likely to have at least one that will appeal to each member of the community.

When Things Go Wrong

From time to time the site will experience technical difficulties. If, because of a technical fault, the site is not publishing stories it is also likely that an editor will not be in a position to produce new stories. At such times the editorial team can divide itself into 2 specific roles. The first, and priority role, is to join the #solent and #staff channels on IRC and act as the first point of contact with members of the community who wish to alert the team to the current problem and, more frequently, want to know when the site will return to normal operation. (This role is shared with other team members who are unable to continue with their own primary tasks). Rather than have each query from the community directed to the team that is trying to rectify the fault, the editorial team field these questions, provide answers when they are available, and act as a conduit between the community and the sys/dev teams such that they, in turn, are able to continue with their primary task of recovering the site. Any other spare editors can begin to collect new stories for eventual submission once the system is recovered.

Preparing for Work

The editing process revolves around 2 lists: the Submission List and the Story List. When you have received your editor permissions on the system, you will notice that whenever you log on to the site that you have an additional menu bar at the top of the page. I recommend that, if you have a browser that supports tabbed windows, you open 3 separate tabs. The first should be the Submission List, the second the Story List and the third the site front page.

Having the front page visible allows to you keep an eye on how the stories are being released. However, for the editing task it is not strictly necessary so you can omit it if you find it interferes with your work. You might also want to keep an eye on at least the #staff channel on IRC because any problems that arise will be flagged up on here in the first instance. Have the #editorial channel ready somewhere as well, if you can manage it. You will now realise that, for everything to work perfectly you need to keep an eye on mulitple windows. Often this is impractical - you simply have to do the best that you can. Ideally, there will be more than one editor active at any time so you can share the responsibilities between you. At other times you will be concentrating on one specific window and you will have to decide when to quickly shift to other displays to keep an eye on things. For the new or inexperienced editor - just concentrate on the editing task and leave others to take care of the rest. As you become more comfortable in your new role you will naturally develop the ability to switch around from time to time.

Submission List

The Submission List is exactly what it says - it lists all the submissions that have been received but not yet processed into stories. The list is in chronological order with the oldest story at the top. Each submission has a number of fields associated with it. Currently (Mar 2014), they are:

• A comment field. This can be used by editors to keep notes on the story either for yourself or to inform other editors about something you might have discovered about the story (i.e. link not working, or a story that is best kept to be released at a specific time e.g. weekend or specific holiday)
• A drop-down list that allows a submission to be tagged as Back, Hold or Quik. [TODO Find out what they each mean/do]
• A drop-down list that allows selection of the Main Page or All Sections. [TODO Find out what they each mean/do]
• A selection box that enables each submission to be individually selected for a subsequent action to be applied.
• The date and time that the submission was received.
• The title provided by the submitter. Clicking this hyperlink selects the submission for editing.
• The nick of the submitter, his/her karma in brackets, and a contact email if it was provided.

Below the list of submissions are 5 buttons with the following labels and functions:

• Update - Updates the comment fields on each of the submissions whose selection box is ticked.
• Delete - Delete each submission whose selection box is ticked. Warning - this is permanent and immediate, care should be exercised when using the Delete function.
• Merge - Merge the selected submissions in to one story. This is useful when similar but not identical stories are submitted on a specific news item.
• Select All - Select all submissions.
• Select None - Deselect all submissions.

Story List

The Story List is in reverse chronological order and shows stories that have been published or are waiting to be published. The display is colour-coded. When a story is released by, say Editor A, it will appear in the list according to the date and time specified during the editing process. It will appear in a yellow colour to Editor A, but to all other editors it will appear in red. This indicates that the story has only been seen by the originating editor and that it has not been checked by a second editor. Wherever possible, stories are to be seen by at least 2 editors before they reach their release time. Once a second editor (Editor B) has viewed it and pressed the 'Update' button the story colour code will change to green for all editors. The action of editing or checking a story is known as a 'Sign Off'. A story opened from the Story List will show the 'Sign Off' information on the screen on the right hand side of the display. In our example, the first sign off will be Editor A and the second sign off will be Editor B. There is no limit to the number of editors who can view a story or make corrections to it and a history of changes will be maintained in the Sign Off information. Stories that have been placed in the list but have been stopped from release are coloured grey.

The format of each line in the Story List is as follows:

• List Index. As the stories progress down the list their index number will change according to their relative position.
• Title. The title is not necessarily the same as that suggested by the submitter. An editor can change the title at any time during the editing process. The title is also a hyperlink which allows the story to be opened for further editing either before or after story release. This is useful when an error is discovered in a released story and it is felt that editing is necessary. However, changes should be done only when necessary because they could affect the meaning and usefulness of comments that have been made to the story by the community.
• Originating Editor.
• Topic. Stories can be can be allocated to one or more Topic groups. Only the first topic group is displayed in the Story List.
• Nexus. Currently, all stories are released on the Main Page nexus however, it is possible for different nexuses to be used.
• Page Hits. [TODO Confirm this!]
• Comment Count. The count is only useful after the story has been released. It indicates the number of total comments but does not differentiate between good and bad comments.
• Release Date/Time.

The Submission

Initial Actions

The initial actions when editing a submission are:

• Open the submission in the editor by clicking the submission's title hyperlink.
• Check all links work, and point to a site relevant to the story. Remove links to political or pornographic material, off-topic items, and advertisments. Check the date of all links, ensuring that they point to current news and not to historic events/stories.
• Check if the story is a duplicate of one that has already been released. (N.b. there is more on this topic in the Editor section.)
• After removing unwanted links, re-check that the story remains of interest to the community.
• Assess if the story is time critical - for example, does it describe critical software updates, or announce significant and relevant breaking news? It it does, prepare the story as quickly as possible and save it in the story queue. If possible, have a second editor sign it off and then release it as quickly as practicable.
• Assess if there is sufficient material to process the submission now or whether it should wait until more time is available. Decide whether to leave the editor and mark the submission with an appropriate comment in the submission queue, begin editing the submission as a standard story, or to start the research.