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.

Dos and Don'ts

These are generally accepted best practices for editors.

Do:

• Check spelling and grammar
• Check links
• Check related stories for dupes

Don't:

• Post stories that you submitted
• Add an "editor's note" with your opinion (put that in the comments)
• Edit quoted material. [Unless doing so to provide clarity, using square brackets]

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

(this may no-longer be necessary) mrcoolbp (talk) 16:11, 10 July 2014 (UTC)

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 Stories 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 who has made changes will be maintained (but not what has been changed) 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. 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)

Main Editing Panel 'ToolTips'

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 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 nexuses (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, an 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 occasion 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 contents of the field should be all lower case. The system will insert 'from the' before the contents of the Dept field and 'dept' after. It will also automatically replace whitespace with a dash (-). E.g 'this is an example' would appear on publication 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. 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.

It is possible to create Polls i.e. give the community a list of options for which they are able to vote, and these options are immediately below the fields discussed in the previous paragraph. As I have not currently used this facility I will not explain it any further here yet.

Below the Poll options are 2 selector buttons and a link. The link is invaluable. When you have made major changes to a submission it is possible to lose sight of what the original submission looked like. By using the 'submission' link you can open a BEP with the original unchanged submission within it. Be careful that you do not end up editing 2 different copies of the same submission which is easily done, and difficult to recover from without having to completely redo the submission again from scratch.

The Story

Having gone through all the controls, options and selections detailed above we finally arrive at the point of the entire process - the story itself. A submission might only be a few words or, if you are lucky, a few hundred words. But the story that the editor crafts from the submission might run into a thousand words or more. While this is uncommon, it does happen frequently enough that procedures have been created to help manage and display the story to maximum effect.

Currently, the editing of the story itself is carried out using a subset of Hyper-Text Markup Language (HTML). The editor is rudimentary and the process is error prone. Until an editor becomes proficient at the editing process, (s)he should work slowly and methodically through the story while previewing progress at regular intervals. Do NOT attempt to edit as quickly as more experienced editors, nor fall into the trap of thinking that you are not working hard enough. Most editors would prefer one or 2 well edited stories a day rather than 10 that required substantial reworking during the release checking process, or worse, risked incorrect information being published to the community. Errors will occur naturally and every editor will experience them, but inducing additional errors by undue haste is counter-productive to the entire editorial team. That said, you will make errors - accept this fact, try to learn from each error, and move on.

Every story is capable of being divided into 2 separate portions. The Intro Copy which is essential for every story, and the Extended Copy, which is only used for longer stories. There is no practical physical limit on the size of the Intro Copy but, for presentational purposes and to enable a reader to grasp the essential points that are being made, it is usually kept as concise as possible while maintaining readability and comprehensively covering the essential points. It should be possible to read the Intro Copy as a stand-alone document, understand the basic thrust and outcome of the story, and move on if no further detail is wanted.

Immediately below the Intro Copy editing window are 2 buttons marked initially 'save' and 'preview'. Pressing the 'preview' button will redraw the entire web page that you are working in and show you what your editing so far would look like if released as a story. Use the 'preview' button frequently, especially for checking layout, that the links point to the web pages that you expect them to, and that you are meeting the requirements of the Intro Copy with regards to content. When you have inspected your work so far, return down the page to the Intro Copy window again and place your cursor inside the window. Check that all the red underlined words are corrected for spelling or are correct abbreviations that the dictionary has simply not recognised. Do not correct source material. If the source web page or document says something - that is how it will be published. As an editor you can decide whether it is a simple spelling mistake (in which case put '[sic]' immediately after the error). Do not correct English dialect differences. As long as the summary is consistently written in US-English or UK-English, it is correct. Do not change the spelling of source material to suit your own particular dictionary. If, for example, the material is published in UK English, changing words to US English (or vice versa) can significantly change the meaning of what is being said. You edit the summary - not the source material. For other errors an Editor's Note is probably more appropriate.

If, by the end of the Intro Copy editing process there is nothing more to be said, then the document is complete and ready for publication. Quickly check the stories page to make sure that no one else has published a story while you have been editing (if so - change your timings, leave the published story untouched). If you are finished then press the 'save' button and it should present you with a modified story list. Remember that this is the 'modified' story list and has special properties which make it rather dangerous. If you renew this page, say, by pressing the F5 key in your browser, a second copy of your story at the exact same time of release will be inserted into the list. One of the copies will then have to be disabled. I recommend that you simply check that the timings for you story are as you expected and then close this window. You can then move to the Story Window that you have had open throughout the editing process, click 'stories' at the top of the page to update it, and your story will be displayed.

However, if you have more detail that you think some people will want to read but that might not be of interest to everybody, or simply information that you could not reasonably insert into the Intro Copy, then you use Extended Copy field just below. There is no additional headers or selections, it is simply a way of extending the story except that the contents of the Extended Copy window are not displayed immediately on the main website page but are accessed by the reader selecting 'Read More' from the bottom line of the story display. This conveniently solves the problem of keeping the main page full of short, concise stories but enables longer and more detailed stories to be seen by those who wish to read them. Editing the Extended Copy text is identical to editing the Intro Copy and the use of the 'preview' and 'save' buttons remain the same. If there is text in the Extended Copy field, the system will add '[Continues...]' to the end of the Intro Copy field to show that there is more to the summary when it displays on the main page. You should not add '[Continues...]' manually because there will be two instances.

It is possible to include text from a file into a summary or to attach media links - neither of these are used at present by the site and, for now, their usage can be ignored.