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. Many of our members also find it helpful to set a particular day of the week that they attend to Programming Historian duties (Friday is popular). You may find that helpful for you too.

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.

Your First Month

In your first few weeks as a Programming Historian editor, there are a few tasks we need to complete to make sure you have access to all of the systems we use to administer the journal you'll be working on, and to make sure you have had a chance to learn how everything works. When you are invited to the project your ME will put you in touch with either the Team Development Manager (for existing publications) or the New Publications Manager (for teams in the setup phase).

This person will arrange a virtual meeting with you to collect the following information:

• Your Google enabled Email Address
• Your Github username (for contributing to our website)
• Your Skype username (for our meetings)

This person will also introduce you to someone who you can 'shadow' (watch and learn) during a live peer review process. This will let you learn how they manage the editorial process from start to finish, including working with authors and reviewers, and overcoming challenging situations if they arise. We will work with you to ensure you are partnered with someone who speaks a language you know well. Please note that English editors tend not to work on much translation so if your role is primarily to work on translations then it may not be appropriate to shadow an English editor. The person you are shadowing should give you a tour of our Submission repository and answer any questions you may have about the editorial process. To make this process as effective a learning experience as possible, you should read the /contribute pages in your preferred language.

We also want to make sure you know how to do some of the more important technical tasks related to using our website, which is built using Jekyll, written in markdown, and uses Git pull requests to add new material. These processes may be unfamiliar to you so depending upon your previous experience you may find it helpful to go through the following tutorials:

• Amanda Visconti, 'Building Static Web Pages with Jekyll and Github' Programming Historian 5 (2016).
• Sarah Simpkin, 'Getting Started with Markdown' Programming Historian 4 (2015).

We have also developed step-by-step instructions for adding material to the website using a Pull Request:

• 'Making Technical Contributions'

Our website files can be found on Github: https://github.com/programminghistorian/jekyll and this is where we make all changes to the site. In order to ensure that you understand this process of making changes, we ask all new editors to add themselves to our Project Team page. This involves adding your details to the /data/ph_authors.yml file, copying the format used by other editors. You should also find a square black and white avatar/photo of yourself (.png). Resize this to roughly 300px square. You should then submit a single pull request containing both the changes to ph_authors.yml and your photo. Full details are available on the 'Making Technical Contributions' page and any member of our team is happy to help you if you get stuck. Please take the initiative to do this task yourself, as soon as you are able. Someone will check over your pull request and help you resolve any issues with it.

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.