1. Copyediting (original lessons only)
2. Typesetting
3. Generating archival hyperlinks
4. Documenting authorial copyright/permission to publish

Managing Editors should get in touch with our Publishing Assistant when they receive a Recommendation to Publish from an Editor. Copyediting is performed either by our Publishing Assistant (EN) or a freelance copyeditor (ES, FR and PT). Rates for copyeditors must be agreed by the Finance Manager or their assignee in advance of commissioning any work, and will be based on availability of funds. This should not vary substantially from agreed [rates set by the Society for Editors and Proofreaders](https://www.sfep.org.uk/resources/suggested-minimum-rates/; https://www.the-efa.org/rates/). Local cost of living should be considered when agreeing rates, with an aim towards fairness. All quotes must be in GBP and payments will be made in GBP regardless of the local currency of the copyeditor. Note that in most cases expected spend on copyediting will be agreed at the beginning of the financial year (see 'Ongoing costs')

Notes for Copyeditors

Before you begin:

• Read our Author Guidelines, to familiarise yourself with the way we encourage authors to write. The Author Guidelines are available in EN, ES, FR, and PT. Step 2 of those Guidelines covers Writing and Formatting a New Lesson.
• Locate the lesson Markdown file. If you’re copyediting an English lesson, the .md file will either be located in “/en/drafts/ originals” or “en/drafts/translations”.

Where to read:

• In your web browser, via the live preview. You’ll find a link to a live preview of the lesson in the editor’s initial comment. OR • In your favourite Text Editor application, such as Atom or Visual Code Studio. You can make a copy the Markdown file from our Submissions Repository

NOTE: Reading in the browser environment, offers you an opportunity to review the text formatted alongside any figure illustrations, graphs and code blocks that are included.

Objectives:

• To ensure that the text is free from spelling mistakes and grammatical errors
• To support the production of a well-written, accessible lesson
• To encourage clear, lucid expression and correct use of language
• To encourage short sentences and straight-forward instructions
• To read the lesson from the point of view of someone learning from it. Are there places where including a link to an external resource, or a subject-specific glossary could benefit a reader's comprehension?

How to deliver your edits:

You’ll notice that each line of the Markdown file (at left edge) and each paragraph of the Lesson Preview (at right edge) is numbered. These numbers will help you to anchor any suggested edits or comments to specific points in the text.

• Prepare a list of changes for the author to consider and implement OR
• Apply changes yourself for the author to review, working directly on the lesson .md file

NOTE: We don't use the Git Pull Request system in our Submissions Repository, so you don’t need to create a new branch or generate a Pull Request to merge your edits.

• Be clear and specific. Anchor your suggested edits, comments and questions to individual paragraph or line numbers
• Consider writing a 'checkbox' list of suggested revisions to help the author work through your edits in sequence
• Authors can decide whether to apply or reject your suggestions. GitHub’s detailed Commit history allows them to review additions or deletions to the file
• Be prepared to liaise with the author and the editor as they discuss and agree revisions
• Post a comment in the Issue to confirm that your copyedits are ready for review

The following Steps 2 - 4 are undertaken by our Publishing Assistant. Step 2 is a full review of the Markdown file to check the lesson’s layout and structure. Step 3 involves replacing all external links included in the lesson with archival perma.cc hyperlinks. Step 4 is when the author/translator will be asked to complete declaration form to acknowledge their copyright and grant us permission to publish their lesson. Forms are currently available in EN and ES. Declaration forms should be emailed to: admin [at] programminghistorian.org.

Notes for Publishing Assistant

Review the lesson’s Markdown file, paying particularly close attention to its layout and structure. This step aims to ensure that each new lesson is structurally and visually consistent with those we’ve published previously.

Be alert to the presentation of:

• YAML
• Section headings and subheadings
• liquid sytax
• figure captions
• code blocks
• tables
• lists
• endnotes
• bibliographic references

NOTE: Programming Historian uses The Chicago Manual of Style, 17th Edition reference system.

Notes for Publishing Assistant

• Collate a list of all external links included in the lesson
• Review each one to ensure that the given link is correct, and the webpage is still available. If you identify any links that are broken or present problems, liaise with the author and editor to agree alternatives or omissions
• Log-in to our organisational Perma.cc account
• Create a new folder and name it carefully – the folder name should indicate the language the lesson is written in, and mirror the lesson file name, e.g., ES-lesson-file-name-here
• You can either paste in a URL and generate Perma links one-by-one, or choose to create multiple links — this option will open a new window
• Select the folder to affiliate your Perma links with
• Paste in your list of URLs (one URL per line)
• When the archival links are ready, you’ll be able to review the list. It will comprise the original page titles and the original URLs alongside the new Perma links. Perma links have the following structure: https://perma.cc/XXXX-XXXX
• Return to the lesson .md file
• Carefully substitute each original link within the lesson with its archival alternative

Notes for Publishing Assistant

• Prompt the ME to ask the author/translator to complete declaration form and share the download link with them. The form is designed to acknowledge authorial copyright, and formally grant permission to publish the lesson. Authors/translators need to email their form to: admin [at] programminghistorian.org.
• File the form in the appropriate sub-directory of the Copyright folder within our secure Project and Business Archive.

• Freelance copyeditors will be hired as sole traders for individual pieces of work, and will not be employees of ProgHist ltd.

• A list of approved copyeditors can be found below. Managing Editors can choose to engage a copyeditor for original lessons (translations are currently handled through a peer review process instead). ProgHist Members are encouraged to put themselves forward for inclusion on this list if they possess the relevant skills.

• Rates for copyeditors must be agreed by the Finance Manager or their assignee in advance of agreeing to any work, and will need to be based on availability of funds. That this should not vary substantially from agreed rates set by the Society for Editors and Proofreaders (https://www.sfep.org.uk/resources/suggested-minimum-rates/; https://www.the-efa.org/rates/). Local cost of living should be considered when setting rates, with an aim towards fairness. All quotes must be in GBP and payments will be made in GBP regardless of the local currency of the copyeditor. Note that in most cases expected spend on copyediting will be agreed at the beginning of the financial year (see 'Ongoing costs')

• The contact for freelance copyeditors will be the Managing Editor or the Publishing Assistant.

• Invoices should be sent to the Finance Manager or their assignee using the [email protected] email address. All invoices must include the title of the lesson.

• This policy be revisited at least once per year.

List of approved copyeditors. Email Anisa Hawes for contact details (Managing Editors only)

English

• Anisa Hawes

Spanish

• José Antonio Motilla

French

• Hélène Beauchef
• Anne-Laure Fréant