Institutional Credit for Editorial Work

This page provides tips and advice for members of the Editorial Board who need to get "credit" for their work on the project. It arises from a discussion on Editorial Retention (https://github.com/programminghistorian/jekyll/issues/994).

It is important to remember that what "counts" varies from country to country, and from job-type to job-type. The advice here may not all apply to your specific context, but we hope it is a helpful starting point.

Get a mentor from within the team

You aren't the first person to go looking for "credit" for their work on the project. We've all been there in one way or another. If you would like to speak to someone or set up an informal mentoring arrangement, please let the team know. We have lots of experience and we're happy to share it. We'd rather be able to keep you on the team, happy and productive, than struggling and miserable.

Have a conversation with your manager

Chances are your manager is not familiar with the Programming Historian or your role within it. Ask for a meeting so that you can explain the project, its achievements, and how you are contributing to it. Use the opportunity to have a discussion with your manager about how your work with the Programming Historian can help your organization achieve its goals.

You might find that members of your institution are looking to build bridges. They might be looking to support open access scholarly publications (e.g. librarians). Or perhaps they are interested in expanding their teaching capacity in digital humanities (e.g. a director of teaching/learning). Maybe they're interested in projects with a global agenda (e.g. colleagues in marketing/communications). It's up to you to work with your organization to find areas of common ground. It is these areas where you are most likely to find pathways to "credit".

Ask for a letter of achievement to be sent to your manager

If you think you would benefit from a formal letter sent to your manager outlining your achievements and the value of your support to the project, please contact the Team Development Manager with details and context of your employment situation.

Practice "selling" the project's achievements

It's always helpful to have a good sales pitch for the Programming Historian so that you can give tangible evidence of its impact when the moment comes. Familiarize yourself with our key statistics - annual traffic reports, number of lessons in each language, size and make up of our team and contributors, list of awards or publicity (and if you can't find this data, ask for it). Find a way to tell a good-news story about the Programming Historian that is backed up by evidence.

Put the Programming Historian in the context of scholarship

Depending on your role, people like you may be expected by your institution to produce certain types of outputs. Perhaps scholarly research monographs or journal articles. The Programming Historian doesn't always fit neatly into those categories. Find out what "counts" for you and then take a look at your contributions to the Programming Historian and see how you can frame them (or even adjust them) to meet some of those needs.

Do research, host events, whatever works for you

We actively encourage editors to participate in activities outside of the daily running of the project. If you need to build your research profile and have an idea for a research paper arising from the project, go for it! If you want to apply for a grant that leverages something the project is doing, go for it! If you want to host an event that draws on the Programming Historian, go for it! The more embedded the project in scholarly activities, the better for everyone involved.

Make the project work for you

If a change in your contributions to the project would help you get "credit" at your home institution, please raise these at the next monthly meeting so that the team can support you to make changes to your roles within the project. We want this to work for you.

Don't just say you are an editor

The Programming Historian is not like other journals. Make that clear by stating your role/roles when you describe your work on the project. If there is a role you take on that we don't formally recognise, then suggest that we do (see 'Make the project work for you). Equally, think about the skills you need to be an editor of the Programming Historian: you can use version control, you can do web publishing, you can work as a part of a multi-lingual team, you can resolve bugs, you can run a peer review process, you can work with contractors, you can translate peer-reviewed articles, you can manage complex workflows, you can develop sustainability plans, you can advise on running a charitable company, and so on.

---

If you have any other ideas, please edit this page and add them to the list.