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 ensuring reviewers follow our peer review guidelines and our safe spaces and anti-harassment policies.

These journals are supported by a publisher wing of the project which is committed to open access for all of our publications.

The 'publisher' provides infrastructural support to each publication. This includes the technical infrastructure that runs the website and integrates our work within the wider scholarly publishing world (eg, through exposing metadata and providing library catalogue entries). A communications team helps to spread the world about our publication's successes and to otherwise build our international community of contributors, readers, and supporters. A Global team works with international communities to explore relationships, potential new language teams, and to ensure we are striving towards building a fairer and more inclusive version of digital humanities. Finally, ProgHist Ltd, a not-for-profit company in England was founded by the team to administer the legal and financial aspects of the project.

From time to time, our project members also do research or outreach activities relevant to our work. You can find some of our published outputs or past activities listed on our Research page. We encourage you to do relevant (ethical) research based on your experiences with digital history/humanities and the project. Feel free to reach out to others if you'd like to pursue a research question, apply for funding to support your work, give a conference paper, or develop a workshop idea. If the project directly impacts others or the way we run things at Programming Historian, it is a good idea to raise it with your ME to make sure it doesn't conflict with other agendas, but we encourage you to use your time with Programming Historian to enrich your own career ambitions.

Your Role & Working Remotely

Most people join the Programming Historian team as an editor for one of our publications. If that isn't the case for you then you will be given specific training relevant to your circumstances. For at least the first year you are with us, we ask you to focus on that role only, as it will take time to develop your skills and confidence.

We recognize that most editors are participating voluntarily in the project, so we do our best to make sure that your role is well defined, the processes are clear and easy to use, and that you are not asked to take on more than you have time or energy to commit to. If at any point you are unsure of how to do something or think that something is designed in a confusing or inefficient way, please raise it with your ME who can feed back to the relevant team members about an improvement.

As a growing international project operating entirely remotely, we also have to ensure that everyone understands their responsibilities and that we can work together efficiently across timezones. Your ME will be relying on you to conduct the peer review process fairly and efficiently. Your authors and reviewers will to be looking to you for a positive experience without undue delays or long periods of no communication. Everyone has times when other things get in the way and they can't focus as much on the project as they would like. To acknowledge this we have a 'Sabbatical' option that allows you to step away from the project for a defined period.

If you are not on sabbatical, we will expect all members to adhere to our Privileges and Responsibilities of Membership which provide clear guidelines on responsiveness, and how we will manage members who have disappeared or fallen out of contact. Please keep in mind that we do not share an office, so we can't use the visual cues that might be more obvious in a traditional setting. If we don't hear from you, we can't tell if you're working on something or if you've disappeared completely. That's why it's extra important that you communicate periods of unavailability to your ME so that s/he can ensure we are able to continue to offer our authors and fellow volunteers a good experience. We find it excruciatingly awkward to send emails to our volunteers who have gone missing without telling anyone. Please help us avoid those awkward experiences by letting us know if and when you will need help covering a task. It is ALWAYS better to ask for help than to struggle on your own.

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.