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 word 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. We have a strong preference that people say NO if they do not want to or cannot take on a piece of work, rather than saying yes and being unable to follow through effectively or efficiently. 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. It is ALWAYS better to say NO than to say yes when you mean no.

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.

Your ME 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 ME 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.

Additional Training & Building your Confidence

Over the years we've identified a series of best practices for editors, which we have put into a series of short training videos. We encourage you to watch these and come back to them as needed:

• 'Finding Peer Reviewers for Technical Tutorials' - 5:06
• 'Approaching Peer Reviewers for Technical Tutorials' - 9:06

A Final Meeting

Once you have uploaded your information to the Project Team page, and have had a chance to shadow a lesson with an established author, you should contact your ME for a final virtual meeting to establish a 3-month plan for your involvement in the project. This is a chance to ask any outstanding questions and to share your goals with Programming Historian so that we can make sure you're able to contribute effectively and in a way that works best for you.

You are always welcome to request additional meetings and to express your wish to expand or change your role within the project. We look forward to working with you for many years, and want you to feel empowered to set your own course for your time with us. Again, welcome to the project, and thanks for joining our team.