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!

In my contribution to a series of social media posts on pain points for the Library Publishing Workflows project, I wrote that “the sheer volume of articles is a significant challenge for our team” (https://twitter.com/LibPubCoalition/status/1280511836744495108). Upon reflection it strikes me that I’m really describing the discomfort that any successful project brings, as demand begins to grow in response to that success. A new library publishing program can often feel like a start-up: a scrappy entrepreneur in the library has a bright idea, access to the tools for production and a platform for dissemination, and a generalist’s competence in many of the skills and tasks necessary to effect library publishing (LPCPDC 2020). But the entrepreneurial energy involved in an early start-up, which can often be maintained by a few highly motivated individuals, eventually either dissipates or becomes insufficient to the work of producing a successful stable of titles. Even if a library publishing program doesn’t grow substantially in output, the production work that felt exciting at volume 1 issue 1 may start to feel insurmountable by volume 6 issue 4.

Some of this may have to do with the temperament of the library publisher. Lacey and Parlette-Stewart (2017) write about the incidence of imposter syndrome (IS) in the profession, and theorize that the need to appear intelligent about a range of poorly defined responsibilities may lead librarians to overwork a program. The failure to properly delegate tasks, commonly associated with IS, can saddle a small library publisher with an unmanageable workload. Delegation requires identifying what we can’t do well, which can be difficult for academic librarians, who are constantly being asked both to do more with less and to justify our value to the academy.

In my own publishing program, which fits most of the above bill, the entrepreneurial energy with which I began publishing journals is matched in some truly driven faculty editors. Their output can be prodigous, and while I remain committed to the success of their journals, my team struggles at times to meet their production needs given the volume of scholarship they review and publish. Identifying, sourcing, and training the labor necessary to do the technical, tailored and often tedious work of turning manuscripts into published articles is itself a demanding process, which can feel at odds with the imperative to produce. Recruiting volunteer labor or attracting graduate student interest means enhancing the learning and project opportunities of a role in the digital publishing unit, often at the expense of the sometimes monotonous work of production. But the unique skills and detailed requirements of production also often preclude using un- or underskilled labor to prepare manuscripts for publication. And we are very aware of the tendency for academic work-study opportunities to be exploitative and inequitable, and hesitant to continue those practices simply to meet our production schedule.

We have experimented with outsourcing production work to a third party contractor. While this has yielded some possibilities to ease our backlog, it also requires additional manuscript preparation and quality control labor which reduces the total net gain in capacity (not to mention chasing funding). We have worked to increase the quality of the editorial processes and policies in our journals, which results in a more selective acceptance rate and helps create a more sustainable production slate. And as our program grows, so does my commitment to designing a sufficient policy and procedure infrastructure around our publishing activities. Our participation in the Library Publishing Workflows project is part of that commitment, to help create a body of standards that can in turn inform our own practice.

My digital publishing program was the pilot interview of the Workflow project, and the resulting flowchart is one of the two test cases being used to fine-tune the process that will be used to document the remaining data. To be honest, I felt slightly naked seeing our own workflow outlined so starkly in directional arrows and decision diamonds. I recognize my anxiety is really about seeing our process evaluated against other publishing programs’ processes. Will we end up on our own, looking foolish? But again and again, collaborating with other institutions in the Library Publishing Coalition on capacity-building projects like this helps reveal the extent to which our pain is shared, and not an indication of failure. Jason Coleman at the University of Michigan related in another social media post that XML conversion of incoming content can be intensely frustrating (he called it “just a bear”). Knowing something about Michigan’s platform and process, thanks in part to our work in the Coalition, helps me picture that pain clearly, and creating XML from tricky input myself for aspects of our publishing program helps me identify with it. As a small shop in comparison to Michigan, it’s a good reminder that I work in a community of practice with affinities across vastly different publishing programs. That’s something worth sustaining.

References:

Lacey, S., & Parlette-Stewart, M. (2017). Jumping Into The Deep: Imposter Syndrome, Defining Success and the New Librarian. Partnership: The Canadian Journal of Library and Information Practice and Research, 12(1). https://doi.org/10.21083/partnership.v12i1.3979

Library Publishing Coalition Professional Development Committee. (2020). L​ibrary Publishing Competencies. A​tlanta, GA: Educopia Institute. https://doi.org/10.5703/1288284317123