LPC Blog

Over the past few months, we have published a blog series on pain points from our cohort of library publishers. Our amazing library partners have written about the challenges of quality control with distributed editorial and production teams, the difficulties of funding a non-commercial, scholar-led open access publishing program, the strains of scaling up a program while continuing to keep promises and meet expectations, and the work required to maintain and troubleshoot aging infrastructure. We want to supplement these thoughtful and in-depth pieces with some high-level information about the sources of frustration we identified in the first year of our project.

Time-consuming manual work

Unsurprisingly, the steps in journal workflows that require staff time and attention were the most common pain points mentioned. These manual processes make it difficult to scale up publishing programs or maintain regular publishing schedules. Publishers who typeset and layout articles in-house unanimously identified that work as a pain point. Typesetting and layout are often tedious (especially when working with equations or other types of special formatting), difficult to get correct, and not supported by platforms, requiring library staff to export, use a different piece of software, and re-upload. Several partners also identified quality control and the correction of partially automated processes as time-consuming pain points. Quality control issues occurred at all stages of the workflow, including correcting batch upload spreadsheets, DOI assignments, format conversions, and preservation.

Staffing

Our partners brought up an array of pain points regarding staffing, including inadequate number of staff, training of new personnel, and difficulties replacing or maintaining production when people leave. Staffing is, of course, closely related to the first issue of time-consuming manual work, because a larger number of employees allow for more of that work to be done effectively. Fewer dedicated staff also mean that publishers are less able to provide customized support to journals, including (but not limited to) software development. Most of the library workers we interviewed had library duties outside of publishing, meaning that it could be challenging to balance their work, particularly when publishing work may come in large batches. Several programs also mentioned that much of the work and institutional knowledge relied heavily on only one or two people, so the impact of that employee leaving, especially unexpectedly, could have a catastrophic impact on the program.

Lack of control over publishing process

Library publishing is a necessarily collaborative process that relies heavily on journal editors, authors, vendors, publishing platform(s), and library personnel. Many of our partners reported pain points that stemmed from the inability of the library to control the process, workflow, and timeline of the journals they are publishing. Our partners reported many workflow differences between the journals they publish, often depending on the journal’s field, policies, and editor preferences. These issues are especially prevalent in library publishing, as many of their journals that have been established elsewhere and come with preexisting norms and processes. High levels of journal autonomy mean that it can be difficult for library publishers to institute changes to workflows, or normalize processes across their different journals. In addition to this, many of our partners noted that because articles often come in large batches (sometimes as issues, or sometimes because the academic calendar impacts editors’ available time), it can be difficult to handle such irregular workloads.

Conclusions

We saw an abundance of social issues in these pain points conversations. Communicating with staff members and editors, managing the expectations of editors and authors, and training staff and editors were all significant factors in mitigating pain points. While I had expected a mix of social, technical, and financial pain points to arise, our conversations made clear how closely those three aspects are tied together. This is not an area where much can be automated, so the technology only works as well as the people who maintain it, oversee its use, and fill in for its inadequacy. Library workers are only able to perform this step to the extent that libraries are adequately staffed and time is carved out for them to do the hands-on work and communicate with the other stakeholders.

As we’ve expanded our Open Access journal publishing work over the last few years, growing from 20 or so journals to about 40, Michigan Publishing has encountered some pain in a particular point in our workflow: converting journal articles from the formats in which authors have written them into the flavor of TEI XML that our publishing platform, DLXS, requires. This work takes our team about an hour per article to complete, on average, and that means a significant time investment which can be hard to explain to journal editors. When a journal includes complex math or symbolic logic written in LaTeX, the time to move a single article through our system can easily increase from an hour to a full day, or even several days. All of this slows down our time to publication and, since we bill our journal partners for the time we spend working on their articles, it gets pretty expensive for them.

To further complicate matters, the work of moving a XML document through DLXS to the final web version takes place largely on the command line – an efficient way to work when you’re an expert, but one that requires a fairly significant learning curve for new members of the team. If anything goes wrong, we sometimes need to know perl, XSLT, or shell scripting in order to fix it. The high technical barrier to entry makes it hard to train students to help in our work unless they stick around a few years, and it keeps our developers busy supporting older technology.

DLXS was developed at the University of Michigan Library starting in the late 1990’s, and (although it’s done great things for us) it is clearly showing its age. The Library is planning to sunset DLXS relatively soon. Even if it weren’t going away, Michigan Publishing would still need a new journals platform to help us work more flexibly and efficiently.

We strongly support community-owned open source scholarly communication infrastructure (we have been building our own open platform, Fulcrum, to support digitally-enhanced book publishing), so it was an easy choice for us to select Janeway (from the Birkbeck Centre for Technology and Publishing) for our next-generation journals platform. We’re hoping to move all of our active journals off DLXS in 2021 or 2022, and transition them to a much more industry-standard JATS/HTML-based workflow that can play well with both existing content conversion tools and vendor offerings. We also plan to build an integration between the two platforms so that Fulcrum’s rich media capabilities can be embedded in Janeway journal articles.

There will, of course, be a big pain point here: migrating all of the thousands of journal articles we’ve previously published in these journals from DLXS to Janeway. But we’re optimistic that once we get through that project, the new platform will make the lives of our production team and editors much easier. The move will also help us keep costs low for our publishing partners, many of whose journals would never be sustainable in a commercial environment. Check back with me in 2022 and we’ll see if the pain’s been relieved!