Donate to Programming Historian today!

Editor Guidelines

This page contains step-by-step instructions for editors facilitating peer review for the Programming Historian.

The Role of the Editor

Thank you for editing a lesson for the Programming Historian. We are extremely grateful for your efforts. This guide is meant to ensure that all authors, editors, and reviewers receive a consistent and fair experience with the Programming Historian. If you have any questions about anything in these guidelines, please email one of the other editors or post a question on our Github issues. Do the same if you think these guidelines need improvement or updating.


We always encourage prospective authors to pitch their ideas before they start writing. If a piece is not suitable for the Programming Historian our job is to tell an author before they have written a full tutorial. We hope this saves everyone time and energy. Once we have spoken to an author and encouraged their idea, our aim is always to support authors until the piece is publishable. Our goal is to help them reach that stage as efficiently as possible with clear guidance. You may find it helpful to familiarise yourself with our instructions for authors.

Safe Spaces

The Programming Historian is committed to providing a safe space for the exchange of ideas, where everyone can share without fear of harassment or abuse. The editor plays a fundamental role in ensuring that space endures. Your job includes enforcing our anti-harassment policy at all times. If you need help please ask one of the other editors or PH ombudsperson (Dr Ian Milligan - You can read more about our commitment to safe spaces on the project blog.

Anti-Harassment Policy

This is a statement of the Programming Historian’s principles and sets expectations for the tone and style of all correspondence between reviewers, authors, editors, and contributors to our public forums.

The Programming Historian is dedicated to providing an open scholarly environment that offers community participants the freedom to thoroughly scrutize ideas, to ask questions, make suggestions, or to requests for clarification, but also provides a harassment-free space for all contributors to the project, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age or religion, or technical experience. We do not tolerate harassment or ad hominem attacks of community participants in any form. Participants violating these rules may be expelled from the community at the discretion of the editorial board. If anyone witnesses or feels they have been the victim of the above described activity, please contact our ombudsperson (Dr Ian Milligan - Thank you for helping us to create a safe space.

Track Proposed Lessons

Once a lesson proposal has been given the “green light” by the editorial team and has been assigned an editor, the editor will work with the author to clarify the goals of the lesson and to establish an agreed upon submission deadline. The recommended time frame is 90 days from the start of the editorial conversation, though this can be adjusted if needed.

The editor will then create a “Proposed Lesson” issue in the submissions repository on Github and assign it the “proposals” label. The default proposal text is included in the issue template, or can be copied from below.

The Programming Historian has received the following proposal for a lesson on 'PROVISIONAL LESSON TITLE' by AUTHOR(S) NAME(S). The proposed learning outcomes of the lesson are:

- key learning outcome 1
- key learning outcome 2
- key learning outcome 3 (add as needed)

In order to promote speedy publication of this important topic, we have agreed to a submission date of no later than [90 DAYS BY DEFAULT BY LONGER IF AGREED WITH EDITOR]. The author(s) agree to contact the editor in advance if they need to revise the deadline.

If the lesson is not submitted by [THE AGREED DATE], the editor will attempt to contact the author(s). If they do not receive an update, this ticket will be closed. The ticket can be reopened at a future date at the request of the author(s).

The main editorial contact for this lesson is [EDITOR USERNAME]. If there are any concerns from the authors they can contact the Ombudsperson (Dr Ian Milligan -

The editor is encouraged to adjust the issue text to reflect any additional goals or requirements agreed upon between the author(s) and editor.

When the lesson materials are ready for submission, the author will contact their assigned editor, whose job will be to upload them to the ph-submissions repository after first checking to ensure that there are no major metadata issues.

  1. Uploading the Lesson: the lesson itself should be uploaded to the appropriate subfolder (depending on whether it is an original lesson or a translation) of the lessons folder within the corresponding language folder in the root of the ph-submissions repository. If you need help, see GitHub’s instructions.
  2. Uploading Images: if the lesson includes images, make sure all of the files are named according to the naming conventions specified in the author guidelines. The editor should create a folder for the images in the images directory. This folder should have the same name as the lesson filename. Upload the images to this folder.
  3. Uploading Data: if the lesson includes data files, they should be uploaded to a similarly named folder in the assets directory.

After uploading, the editor should check the commit history for the repository to ensure that their upload received a green check mark. If not, something went wrong and the wiki should be consulted for troubleshooting the errors. Upon successful submission of the lesson, the editor will create a review ticket for the lesson and close the proposal issue. From here on, the editor should ensure that the author work from the latest version of the lesson in the repository and upload changes directly to GitHub themselves.

Open Peer Review

The Programming Historian uses a model of open peer review, while we believe this helps maintain civility and the productive sharing of ideas, authors have the right (and we have a requirement to respect that right) to request a closed peer review. There are many reasons why someone might be hesitant to engage in an open review and we encourage authors to always pursue the option with which they are most comfortable.

Before soliciting external reviews, the editor should read and try the tutorial and use their experience with the Programming Historian to help the author make initial improvements (if required). The editor is not expected to be a expert in content of the lesson, this is the role of the reviewers.

The editor should complete an initial sustainability overview of the submission to ensure that software versions and dependencies are clearly marked, specificities of software like screenshots are limited to those required to complete the lesson, and that the lesson makes use of existing software documentation whenever available and appropriate. Editors should also ensure that lessons try, as much as possible, to avoid software specific directions, such as “Right-click on the x icon to access the x menu,” instead favoring general methodological overviews. The Editorial Checklist contains more details about sustainability practices for PH.

Often editors need help clarifying the intended audience of a lesson, or identifying jargon that needs further explanation. This initial review helps let the external reviewers focus on improving the piece. This is normally done openly on our submission system (see below), but it can be a closed review at the request of either party.

Once an author has revised the tutorial to the satisfaction of the editor, it is the editor’s job to invite two formal external peer reviews. In the interest of our commitment to diversity, we encourage editors to ask themselves if they have made a sufficient effort to draw from reviewers who are distinct from themselves either by gender, nationality, race, age, or academic background. Please try not to find two people who are very like you.

To coordinate our requests for reviewers, please use the “Programming Historian - Reviewer Tracking” Google Spreadsheet. (Contact the managing editor if you need help accessing the spreadsheet.) Prior to sending a review request, check the list to make sure that the person has not been recently contacted by another editor. To avoid over-taxing reviewers, please limit requests to once a year. If a reviewer has been contacted in the past year, the “date_contacted” field will display as red.

For each potential reviewer you do contact, regardless of response, please enter:

Please enter the date using the mm/dd/yyyy format.

When inviting reviewers, the editor should provide them with our reviewer guidelines and give them a deadline for completing their review (usually one month) so that we can ensure the timely publication of the tutorial.

When a lesson has been submitted, the editor will open a new ‘issue’ on our Github submissions repository where the open review will take place. This message board allows everyone to keep track of the conversation. You will need to sign up for a free Github account if you do not already have one, as will both the author and reviewers.

The Initial Comment

Your first comment on the message board for a given tutorial review should use our template which outlines the role of the editor and what will take place during the review, as well as everyone’s options in the unlikely event that something goes wrong. Please adapt the template, which should appear automatically in all new issue boxes, as needed:

The Programming Historian has received the following tutorial on '[LESSON TITLE]' by [AUTHOR GITHUB USERNAME]. This lesson is now under review and can be read at:["lessons" or "translations"]/[URL to lesson]

I will act as editor for the review process. My role is to solicit two reviews from the community and to manage the discussions, which should be held here on this forum. I have already read through the lesson and provided feedback, to which the author has responded.

Members of the wider community are also invited to offer constructive feedback which should post to this message thread, but they are asked to first read our Reviewer Guidelines (/reviewer-guidelines) and to adhere to our anti-harassment policy (below). We ask that all reviews stop after the second formal review has been submitted so that the author can focus on any revisions. I will make an announcement on this thread when that has occurred.

I will endeavor to keep the conversation open here on Github. If anyone feels the need to discuss anything privately, you are welcome to email me. You can always turn to our ombudsperson (Dr Ian Milligan - if you feel there's a need for an ombudsperson to step in.

Anti-Harassment Policy

This is a statement of the Programming Historian's principles and sets expectations for the tone and style of all correspondence between reviewers, authors, editors, and contributors to our public forums.

The Programming Historian is dedicated to providing an open scholarly environment that offers community participants the freedom to thoroughly scrutinize ideas, to ask questions, make suggestions, or to requests for clarification, but also provides a harassment-free space for all contributors to the project, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age or religion, or technical experience. We do not tolerate harassment or ad hominem attacks of community participants in any form. Participants violating these rules may be expelled from the community at the discretion of the editorial board. If anyone witnesses or feels they have been the victim of the above described activity, please contact our ombudsperson (Dr Ian Milligan - Thank you for helping us to create a safe space.

Guiding the Conversation

Everyone will be looking to you as the editor for guidance on the system. For most authors and reviewers this will be their first experience with our peer review process. The immediate feedback offered by the message board means that authors may see the reviewer comments before you do. That means you will have to clearly signpost how everything will work and when everyone should participate or wait for further instruction.

If possible it is always best to acknowledge review milestones as soon as possible. For example, after the first review has come in, post a response to thank the reviewer and let the author know that another review is on its way. Suggest that they wait for the second review before responding. This lets everyone know what to expect.

If you are really busy, if possible make a note on the forum to say you have seen the new activity, but will need some time to respond properly. Managing expectations can be key to keeping everyone happy.

Summarising the Review

Once the two formal reviews are in (as well as any informal contributions from the community), you will have to summarise the suggestions and give the author a clear path for any revisions that you would like them to respond to. If any suggestions are counter to our aims at the Programming Historian, politely tell the author to forego those suggestions. Keep in mind what it is like to be an author and receive a review. You want clear guidance, but also the right to reject ideas that don’t improve the piece. You also want assurance that you are not trying to hit a moving target. A good summary of reviews means an author can respond and expect publication if all significant obstacles are met.

Managing the Revision Process

With your summary of the reviews and any final instructions for the editor, include a reminder to the author that revisions should be completed within 4 weeks. This is to ensure that lessons are published in a timely fashion and do not drag on unnecessarily. If the author anticipates trouble meeting the deadline, they should contact their editor to establish a more suitable due date.

Technical Processes of Review - Editorial Checklist

Our peer review is conducted on our Submissions repository on Github. Full instructions for how to upload files, including file formats and formatting guidelines can be found on our Author Submission Instructions which will always contain the most up to date instructions. Please familiarise yourself with these steps or refer to them as needed. If you need help you are always welcome to email another editor directly.

There are a few areas where you should intervene in the process from a technical standpoint. They include:

A) Naming the Lesson File

The Editor should suggest a name for the new lesson file that conforms to these guidelines:

Once you have chosen a name for the lesson file, use the same name to create a new folder in images which will contain all of the images for the lesson. If the lesson uses data files, do the same in the assets folder.

B) Initial Check of Markdown

Authors are responsible for checking that their lesson has rendered properly in Markdown. If they have followed the syntax rules, it should be ok. If you can see any Markdown symbols on the page, something went wrong. Detailed instructions of Markdown syntax are available on our Author Guidelines

You can quickly check that everything looks correct on a lesson submission by looking at the rendered version of the page. It will be found at: (note - no .md at the end)

Note that if it is a translation you would substitute “translations” for “lessons”. If that doesn’t work, let the technical team know, and they will try to diagnose it.

C) Sustainability & Internationalization Review

To increase the lifespan of our lessons, Programming Historian editors should complete a sustainability review as a part of their final checklist. Every submission is different and some of these areas may not be applicable to all submissions. Keeping in mind the difficulty level of each lesson and its intended audience, editors should use these areas as guidelines to ensure that lessons are as sustainable as possible from the date of publication.

To help reach a global audience, authors have been advised to adhere to the following guidelines where possible:

Editors should work closely with authors to ensure that these criteria are met. Where this is not possible, justifications for not meeting them should be clearly and transparently outlined in the relevant review ticket

D) Verify Images

All images should use consistent, semantically meaningful filenames that clearly indicate what they are. If a lesson has a large number of images in rapid succession, and the order is important (for example, a series of screenshots), it may be advisable to use a sequential naming system—ideally using the same hyphenated filename slug as the lesson itself (or an abbreviated version if the lesson title is rather long), followed by numbers to indicate which figure it is (For example, counting-frequencies-1.png, counting-frequencies-2.png, and so on.)

If a lesson does use a sequential image naming system, it is possible that figure numbering will change during the peer review process. We ask that before a lesson is published that all filenames are updated to the proper figure numbers. This makes it much easier for us to update lessons if needed in the future. Thank you for helping us keep the Programming Historian sustainable.

Regardless of how the images are named (semantically or sequentially), they should be placed in a subdirectory within the images directory. The subdirectory should be named using the same URL slug used to name the lesson. Make sure the images are in web-friendly formats such as PNG or JPEG and sized appropriately (both in terms of pixels and bytes).

Full instructions on adding images is available in Author Submission Instructions.

E) Verify Data files

Similarly to Images, all data files should be stored on the site (not linked externally - for sustainability purposes). All data should be stored in the ‘assets’ directory, using the same rules as above, but authors should feel free to use a description for their data file that reflects what it is:

Occasionally, large assets used by particular lessons might be too large to be stored in our GitHub repository. If this is the case, we recommend that authors upload their assets to Zenodo for archiving and then provide the lesson editor with the DOI generated by Zenodo for linking from within the lesson. In the event that such datasets might already exist in an institutional repository, we still recommend uploading the version of the dataset used in The Programming Historian to Zenodo for the purposes of consistent use across all of our lessons.

When uploading to Zenodo, all files (even if there is a single file) should be compressed into a single zip file. The zip file should have the same slug used for the lesson file. This is only necessary when the total size of the assets for the lesson is larger than 25MB.

F) Verify videos/gifs

Videos and gifs are strongly discouraged because they create a range of problems. For example, it is difficult and time consuming to ask for changes to a video during the peer review process, and impossible for an editor to make minor updates to it in years to come as it becomes outdated. Videos also require the administration of a separate channel at YouTube. Videos also cannot be printed, and many of our readers use PDF copies or printed copies of the Programming Historian. As such they should ONLY be used when absolutely necessary.

If a tutorial contains a video it should be hosted on our YouTube channel (which is not set up yet so email the other editors when you get a video). A backup of the file should also be stored in our Github repository, following the same principles of naming and storage as in sections for images and data described above and stored in the ‘assets’ directory:

Recommend Publication - Editorial Checklist

Once you and the author are happy with a tutorial, the next step is to recommend publication to the managing editor. This involves checking the files and adding some additional metadata before contacting them:

1) Create an Author Bio

If the lesson has been written by a new author, the managing editor will need to add a new bio for that person. You will need to provide the managing editor with a version of the following information:

- name: Jim Clifford
  team: false
  orcid: 0000-0000-1111-1111
      en: |
          Jim Clifford is an assistant professor in the Department of History
          at the University of Saskatchewan.

Whitespace is important, so be sure that the indentation matches the other examples.

The orcid ID is optional, but highly encouraged if authors have registered for an ID with the service. Only enter an ORCiD ID that an author has explicitly provided to you. Do enter an ID without first getting that author’s confirmation that you are using the correct ID.

2) Add a table of contents to the lesson

The following code should be added into the text of the lesson, usually before the first subheader:

{% include toc.html %}

3) Add YAML metadata to the lesson file

title: "Your Title Here"
collection: lessons
layout: lesson
slug: e.g. introduction-to-sentiment-analysis
date: YYYY-MM-DD
translation_date: YYYY-MM-DD (translations only)
- Forename Surname
- Forename Surname etc
- Forename Surname
- Forename Surname etc
- Forename Surname
- Forename Surname (translations only)
- Forename Surname (translations only)
- Forename Surname (translations only)
original: slug to original published lesson (translations only)
review-ticket: e.g.
difficulty: see guidance below
activity: ONE OF: acquiring, transforming, analyzing, presenting, sustaining
 - topic one (see guidance below)
 - topic two
abstract: |
  see guidance below
avatar_alt: Description of lesson image
doi: Add DOI (see

4) Find an Image to represent the lesson

We represent our lessons using an old image that we feel captures some element of the task described in the tutorial. You can see the full range of these on the main Lessons directory. These images are selected by editors.

Here are a few places to look for lesson images:

Ensure that the image matches the style of the other images (it should be a book image, not a photograph), is at least 200 pixels in both dimensions, and is not copyright restricted. Make sure the image is not offensive, and keeping with our Commitment to Diversity try to find something that does not perpetuate stereotypes or send a subtle message about maleness and whiteness.

Save the original image. The filename should be the same as the corresponding lesson’s URL slug with -original at the end, and the filetype must be .png. For example, the lesson “Cleaning Data with OpenRefine” has the URL slug cleaning-data-with-openrefine, so its original lesson image filename should be cleaning-data-with-openrefine-original.png.

Then, create a new copy of the image. Crop it to a square without removing any important features. Change the dimensions to 200x200 pixels. Convert the image to grayscale. Perform any adjustments necessary to make it conform to the other lesson images, such as lightening or darkening it, or altering the contrast. Save this new image as the lesson’s URL slug; again, the file format must be png. In our previous example, the filename would be cleaning-data-with-openrefine.png.

Upload the original image to the gallery/originals folder, and upload the edited image to the gallery folder. You will need to direct the managing editor to the locations of these images on the ph_submissions repo when you hand the files off to them for publishing.

5) Inform the Managing Editor of your Recommendation to Publish

The Managing Editor will read and carefully check over the lesson, ensuring that it adheres to our sustainability, internationalization, and style guidelines. If in the Managing Editor’s discretion, the lesson fails to meet any of those thresholds of quality, it may be returned to the author for revision. If it passes these final quality control checks, the Managing Editor will publish the lesson by moving the files to the main website and check everything over.

To make this person’s job easier, post a list in the submission ticket of all files that need to be moved to publish the lesson. This should normally include:

All except the bio should be represented as files somewhere in the ph_submissions repo. The bio can be placed in the ticket directly.

6) Incorporate your lesson into our Twitter bot

In addition to the Twitter promotion outlined below, we also make use of a Twitter bot to regularly re-advertise older lessons. In order to add the new lesson to our pipeline, you need to add it as a row in this spreadsheet. Everyone on the editorial team should have the ability to make changes; email the google group if you have trouble. You will need to add a new row for your lesson to the end of the table with the following fields:

Leave column D blank and untouched - this field is used by the Twitter bot to log its progress through the list. Also note that this step should not replace your own promotion of the lesson. The bot goes through the lessons at random, one a week, so it could be months until your lesson comes up through this means.

7) Thank Everyone and Encourage Promotion

Once you have been given word that the Managing Editor has successfully published the lesson, close the submission ticket, linking to the published lesson. It’s important to send an email or message to everyone involved thanking them for their efforts. In particular, thank the author for contributing and encourage them to think of us again in future. It’s also worth giving the author some ideas on promoting their lesson. The most-used lessons always have authors’ energies behind them. For example authors should be encouraged to:

People don’t find lessons on their own. The hard work is done, so let’s make sure it was worth it!

Managing Editor Checklist

The Managing Editor is responsible for carefully checking the lesson to make sure it adheres to all of our policies and requirements. If the lesson does not meet these requirements it should be referred back to the editor for further revision. This is a crucial part of the editorial workflow. Once the Managing Editor is satisfied that the lesson meets our standards, it is his/her role to move the files to the main website via a pull request.

1) Carefully check the submission preview

Check the submission preview for any errors or failures to meet our publication guidelines. Refer any issues back to the editor.

2) Request DOI

You need to request a new DOI for the lesson following the steps described in the Wiki.

This part of the process should not take you more than one or two days, depending on the time difference you have with the UK (UTC). You can start next steps while you wait, but note that builds will initially fail until the DOI has been added to the lesson metadata.

3) Move the Files

The editor should have left you a clear list of files that need to be published on the submission ticket. If they have not done so, ask them to fix it before proceeding.

There are several ways that you can perform a pull request to publish the files:

  1. Go to the directory for your local ph-submissions repository.
  2. git pull to get all of the newest changes on your machine (or sync if you are using GitHub Desktop)
  3. Repeat Steps 1 and 2 for the jekyll repository on your local machine.
  4. Copy the lesson files and any related image and asset files from the ph-submissions directory on your machine to the appropriate places in the jekyll directory on your local machine. (You can use a command like cp on the Unix command line, or use your GUI file system if you are using GitHub Desktop.)
  5. From within the jekyll directory on your local machine, git add the new files and then git commit and git push the changes.

After the lesson has been moved to the jekyll repository, you’ll also need to archive the submitted lesson on the ph-submissions repository.

  1. Go to the directory for your local ph-submissions repository.
  2. Add a new line to the YAML header of the now published lesson: redirect_from: "/lessons/LESSON-SLUG"
  3. Move the now published lesson from lessons/ into lessons/published/.
  4. Move the image folder containing the images for the now published lesson from images/ to images/published/.
  5. Use git add, git commit, and git push to finalize all the changes (or follow the Making Technical Contributions instructions:

4) Add the author bio to ph_authors.yml

If the lesson has been written by a new author, the managing editor should add information about the author to the site’s authors directory. Follow the syntax for the examples already included there, using the bio that the editor provided you:

- name: Jim Clifford
  team: false
  orcid: 0000-0000-1111-1111
      en: |
          Jim Clifford is an assistant professor in the Department of History
          at the University of Saskatchewan.

Once you push your changes on to the gh-pages branch of the programminghistorian repository, the site will be automatically tested by GitHub Actions. This test process checks three things: first, that all YAML and markdown code is parseable; second, that all the hyperlinks on the site point to valid, operational pages; and third, that internal links to pages on the Programming Historian are all relative links that start with / rather than

We run these builds primarily to check that URLs that once were functional are still functional, as often times external web pages are moved to new addresses, or are no longer live. They are also an excellent way to catch small typos that may have evaded authors, editors, and reviewers. The status of these tests (often called a “Build Status” on GitHub) can be seen by navigating to the programminghistorian repository page, and clicking “Commits” on the upper left side of the code menu.

GitHub commit menu location

This will show you the list of every change made to the main repository, along with a status icon:

If your build has errored, you will need to consult the build logs to see what is causing it.

  1. Click on the red X for the most recent commit (the one nearest the top of the page), and click on the “Details” link. Travis details location
  2. This will bring you to the build log page on GitHub Actions. Build logs are usually several hundred lines long, but the error information we are looking for will be at the bottom. Click on the small gray circle at the upper right of the log display to scroll to the bottom. The top of the Travis CI build screen
  3. You may see two types of errors: first, if a page is missing a required YAML field (e.g. if a lesson does not have an editors field) then this will be marked in red. Failing links will be also be listed in red, grouped by the page they appeared in. If any links in your new lesson are causing errors, go back and double check that they do not have any typos. If they do, then make any necessary corrections and commit the changes to the repository, and wait for GitHub Actions to run its tests again. Locating error details in Travis CI build results

6) Inform the Editor

Once the lesson has been published, inform the editor and ensure they have added the lesson to the twitter bot pipeline.