Onboarding Process for New Editors

Welcome, bienvenidas, bienvenue, bem-vinda, to the Programming Historian project.

We congratulate you on your appointment to our international and multilingual team. This page is designed to help you integrate into the project. This includes learning how our editorial processes work, introducing you to the different parts of the team and the functions they serve, and providing you with a way to ask questions and build your skills so that you can contribute to our world class efforts.

Our History

Programming Historian was founded in 2008 by William J. Turkel as a series of how-to lessons focused on Python programming for historical research. It was written in response to Dan Cohen and Roy Rozensweig's 'Digital History' book, which helped historians in the early new millennium to get history on the web. Turkel recognized that it was also important to teach historians how to get that same material off the web, and to work with it at scale. His blog, "Digital History Hacks" was the first home of the Programming Historian back in c. 2008. In 2011 the project expanded and has now become a series of Four academic journals of methodology in digital history (English, Spanish, French, Portuguese).

How our Project Works

Each journal is run by a Managing Editor (ME) who works with a larger team of editors to solicit and edit content for their journal. You can find out more about your ME and the members of your journal on the Project Team page of our website. These teams have editorial independence over publication decisions (within the limits of the law), but must follow our editorial guidelines at all times, including our peer review guidelines and our safe spaces and anti-harassment policies.

These journals are supported by a publisher wing of the project which provides technical, financial, legal, and communication support. We attract more than 2 million readers per year, from around the world.

Most people on the team are involved with only 1 or 2 aspects. No one is involved in everything, and we encourage all new members to focus their energy on one thing and do it well.

Purpose of this checklist

This checklist is a GUIDELINES for use by anyone responsible for welcoming a new team member onto the project. It was originally written with lesson editors in mind. It therefore may need to be adjusted for people entering non-editing roles to ensure they have the training and support they need to become effective team members. Please use this in the spirit in which it was created rather than viewing it as a rigid set of rules.

---

Welcome

Welcome to the Programming Historian Project Team. We're very pleased to have you on our team. We know that joining a new project and getting up to speed can be a challenge. So we've put together this information to help you get up to speed. It includes details of what we will do and a checklist of tasks you should complete, to make sure you know how to perform key tasks. We hope it won't take you very long and that this process will enable you to contribute your ideas and energy to their fullest.

What we will do

Within 2 weeks of your joining, our current team will ensure that you have been granted access to the following services used by the Project Team:

• Our Google Group email so you can communicate with other editors (@JoshuaGOB)
• Our Google Analytics account for monitoring web traffic (@JoshuaGOB)
• Our Twitter team (@jenniferisasi)
• Our Github Repository so you can upload materials to the site (@JoshuaGOB)
• Our Skype group so that you can participate in our monthly calls (@JoshuaGOB - who will pass your details on to the relevant team member)
• partner you with an existing editor to develop a 3 month plan so that you can acclimatise to the project.
• invite you to become a 'member' of ProgHist Ltd, our not-for-profit company that administers the business end of the project.

What you should do

There are a few tasks you will need to perform to make sure you know how to use our system, and also to make sure your details appear on the Project Team page. All of these tasks are encouraged, but some may be optional:

communication

• set up a GitHub account and inform @JoshuaGOB of your username (mandatory)
• set up a twitter account (optional)
• set up a Skype account and inform @JoshuaGOB (mandatory)
• inform @JoshuaGOB of your Google-activated email (mandatory)
• write an email to the other editors using the Google group (say hello!) (mandatory)

technical

We rely heavily on Github for communicating and conducting our editorial processes. You will need to get familiar with it and the way we use it. We recognise that this can take time, so if you would like one-on-one training, please let someone know and this will be arranged. To make sure you can do all required tasks, try the following activities on our Github /jekyll website.

• contribute to one open ticket on our github repository (mandatory)
• create and assign to yourself a new ticket on the github repository to ensure you know how to do this. Add a relevant label. (mandatory)
• make a technical contribution on your own. This will normally be adding your bio to the /data/ph_authors.yml file, and uploading a square black and white avatar (.png) of yourself to /avatars). You will then submit a pull request for approval so that this bio information can be added to the Project Team page (mandatory)
• Read all sections of the /contribute pages of the website, including author, reviewer, and editor guidelines
• Bookmark the /jekyll (https://github.com/programminghistorian/jekyll) and /submissions (https://github.com/programminghistorian/ph-submissions) github sites so you can find them easily
• Read the 'Making Technical Contributions' wiki page: https://github.com/programminghistorian/jekyll/wiki/Making-Technical-Contributions

The Culture of the Project

We have invited you to join the team because we value your opinions. We encourage all of our editors to contribute to discussions on github or via email, and to civilly express their views, even if they disagree with any or all other members. This right to express one's opinions is central to our project. Please take this to heart.

---

Shadowing the Editorial Process

These guidelines are recommendations for editors who are mentoring/shadowing a peer review.

1. The more experienced editor and the shadowee should have a conversation before beginning that outlines the expectations and needs of both sides. Different people may prefer different approaches. For example, some shadowees may like to watch and be cc'd into correspondence. Others may prefer the chance to take the lead, with comments and interjections from their more experienced colleague. There is no one approach, and the conversation will help you decide what will work best for you.

2. Shadowees may not be used to being in the position of power during a peer review process. Guidance on managing that responsibility should be welcome.

3. Choosing peer reviewers can be difficult for new editors. A good shadowing experience should include a discussion as well as tips on how to best identify suitable peer reviewers, and how to approach them effectively. Shadowees should be reassured that they will probably not know peer reviewers personally, but need to feel comfortable approaching them.

4. Shadowees may have concerns or questions about tone or style. They may not be sure how often or how much to post. It is a good idea to discuss this with them, pointing to examples of other reviews as necessary.

5. Troubleshooting technical issues can be difficult. Make sure you discuss who the shadowee can turn to for support if they are editing a lesson and run into trouble.

6. After the shadowing experience is over, we recommend that both parties discuss the process and learn from each other how they could strengthen the experience in future. This is also a good time to ask further questions.