Editing Process

Parent: Editors Team

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.

Submission Feedback

To be written.

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 #soylent 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 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.

Editing 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 that they 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 Using the Submission Editor below.)
• 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.

Using the Submission Editor

Whilst there is only one Submission Editor, it has 2 possible page layouts. When the editor is first opened, usually by clicking the hyperlink title on either the submissions list (for a new story) or the story page (to re-edit an existing story), the first page layout is invoked. We will call this display the Basic Editing Page (BEP), and it displays a subset of all the fields than can be edited. If you are editing a story from a submission, then you cannot move to the Main Editing Page (MEP) until the nexus and topic fields are completed. Currently, the nexus field usually displays "Main Page" as default because this is the only nexus in use. The topic field next to it, however, has no default setting and it is essential to select a topic before you are able to move to the MEP by pressing the 'Preview' button.

Basic Editing Page (BEP)

The purpose of the BEP is to display enough information for the editor to assess whether the submission is worth processing into a full story. The links can be tested and their content checked, the summary can be reformatted and unprintable Unicode characters can be edited to something more suitable for the slashcode to manage. The submission can be discarded at this point, remembering to provide feedback to the submitter explaining why you feel that the submission is not suitable. However, assuming that you are happy with everything so far, press the 'Preview' button and it will change the display to the MEP.

Main Editing Page (MEP)

The MEP allows the editing of all data. I recommend that you use the MEP as much as possible.

Story Display

The top portion of the MEP page displays the story as would currently appear if released at this point. Unless you are fortunate, there are likely to be layout, spelling or grammatical structure changes required - and in some cases all three! As a guide, use the layout described in the Story Style chapter in the Editors' Documentation wherever possible but, from time to time, you will have a submission that doesn't fall neatly into the usual style. Do your best to make it readable and clear while following the style guidelines as closely as you can. Having said all that, the Story Display is not directly editable - it will be necessary to use the 'Intro Copy' and possibly the 'Extended Copy' fields further down the page to modify the text. We will cover these fields in more detail in a moment.

Similar / Duplicate Story Detection

Below the story display is a small field designed to show similar stories to the one currently being edited. While this can be useful, take care not to rely upon it as a foolproof method of checking if your current submission is a duplicate. It will sometimes show stories that are superficially similar but might actually be very different in content, or it will fail to find a genuine duplicate because the structure and grammar chosen in the original story are significantly different from that which you are currently editing.

The Display Enable Line

Despite the title of this line, only one element on it is actually there to enable a story to be displayed - but it is so important that I have chosen to call name this line as I have. The first two buttons on this line are labelled 'Save' and 'Preview'. This pair of buttons is repeated in several locations on the page but they always fulfill the same function. The 'Preview' button reformats the display to show any changes that the editor has made so far, and the 'Save' button tells the editor that you have finished editing the submission and have accepted it as a story. The system will then transfer the story to the Story List, remove the submission that you have been editing from the Submission List, and finally display a modified copy of the Story List. It is important to recognise that this is a modified copy because it exhibits an unfortunate characteristic that is not shared by the usual Story List. If you refresh the page of a modified Story List, it will insert the same story, at the same release time into the main Story List i.e. you will have 2 identical stories both queued for release at the same time which cannot be deleted. However, all is not lost. At the right hand end of the Display Enable Line is a checkbox, labelled 'Display', which usually defaults to being ticked. This ticked box indicates that, once the story is placed into the main Story List, it will be released at the time that has been allocated to it. If you can recall the colour coding system described in paragraph describing the Story List earlier on this page, the story will initially be coloured yellow for the submitting editor and red for all others. If this box is unticked, it will prevent the story from being released and the colour coding scheme will turn it to grey. If you have accidentally placed 2 copies of the same story in to the Story List, select one of them and bring it into the editor, deselect the 'Display' checkbox, and save the story again. The second, duplicate story will not be released. This is an important function and one that you would do well to remember - any story can be stopped from being published by deselecting the 'Display' checkbox before its release time.

Topics

Each submission must be allocated to a nexus and one or more topics. Currently, there is only 1 nexus - 'The Main Page'. For technical reasons, each nexus should be hosted on its own server and, as Soylent News only has 1 primary server (with backups) then it is limited to one nexus. At a later date, it might be decided to add further nexeses (e.g. 'Nerd Cinema','Mobile Devices' or whatever). However, there are multiple topics (e.g. Business, Hardware, OS, Software etc) and a submission might fit into more than one topic area. It is strongly recommended that, in most instances, only the one most appropriate topic is allocated but, on occasion it might be sensible to select a second and, very rarely, a third.

The selected nexus and topics is shown in a single list with label embedded within it. Immediately to the right of the list are 4 symbols: an up pointer, a delete cross, an addition cross and a down pointer. The two pointers are for moving the order of topics in the list so that the most important one is displayed higher in the list than any others. Because only a single topic is used for the majority of stories the up and down pointer are not frequently used.

The delete cross will delete the currently highlighted nexus or topic. As only a single nexus in use ('The Main Page') there is little to be gained by deleting this nexus, particularly as the software will not let the submission complete the editing process with the nexus field left empty. However, and editor might choose to change the most appropriate topic and so might delete the topic currently displayed in the list.

The addition cross opens a second window called the Select Topics tree. Highlight the desired topic and then press the 'Add' button at the bottom os the Select Topics window. This can be repeated for several topics but, as discussed earlier, is usually limited to one and on occassion perhaps 2 or rarely 3 topics. There are several other buttons at the bottom of the Select Topics window but their usage is self-explanatory and will not be described here.

Title

Each story must have a title. The character length of the title is 100 chars but, at various point in the submission process, there appears to be an arbitrary limit enforced on the title length of 85 characters. [This appears to be a bug - it is being investigated] The title should clearly explain the essence of the story and is printed in Title Case. For full details of what is and is not acceptable, see the section on Editorial Style.

Department (Dept)

The Dept field is an opportunity for the editor to inject a witty or pithy comment appropriate to the Title and content of the submission. It is not always appropriate and there is no compulsion for it to be used at all. If nothing is entered into this field it simply does not display when the story is published. It should not be used to express the editor's personal point of view. The best way to gain a feel for how this field is used is to simply go through previous stories. The system will insert 'from the' before the contents of the Dept field and 'dept' after. The contents of the field should be all lower case and words separated by '-' e.g 'this-is-an-example'. The example would appear on publication, therefore, as 'from the this-is-an-example dept'.

Author

If you are the first author to work on this submission then your nick should already appear in the left-hand selector box. If not, then select it manually. Most stories are published to elicit comments from the community but, for them to be able to do so, the Comments Enabled option has to be selected in the middle selector box. However, there are other options that have specialised uses and an alternative can be selected if it is more appropriate. This would be a fairly rare occurrence. The right-hand field is an editable text box which contains the date and time (UTC) that the story will be released at. It will have a default time within the next 30 minutes or so and this is rarely appropriate. Check on the stories page that another editor has not released a different story since you started the editing process and decide the release time for the submission that you are processing. Remember to change the date portion if you are releasing a story after midnight on the current day.

TO BE CONTINUED