Onboarding Process for New Editors

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.