Pain Points

Library Publishing Workflows. Educopia Institute. Library Publishing Coalition. Institute of Museum and Library Sciences.

November 10, 2020

Library Publishing Pain Points – Sources of Chronic Pain Points

By Brandon Locke

Editor’s note: This is a guest post in our Library Publishing Pain Points series, featuring reflections from our Library Publishing Workflows partners on the challenges they face in implementing, running, and sustaining their library publishing workflows.

Brandon Locke, Library Publishing Workflows Project Manager

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.

October 22, 2020

Library Publishing Pain Points – Aging Infrastructure

By Jason Colman

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!

September 30, 2020

Library Publishing Pain Points – Scaling Up

By Joshua Neds-Fox

Joshua Neds-Fox, Wayne State University

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). Library Publishing Competencies. Atlanta, GA: Educopia Institute. https://doi.org/10.5703/1288284317123

September 1, 2020

Library Publishing Pain Points – Funding

By Sonya Betz

Operating a non-commercial, scholar-led open access publishing program through our library is intensely rewarding work. On a daily basis we connect with motivated and resourceful editors and scholars, who are deeply committed to open scholarship and to enriching the commons. Each new issue published on our platform feels like a small victory for our team, and we know what we’re doing is meaningful, not just to our small community, but also to all the invisible readers who come across our content and engage with it in some way. However, this work also comes with its own set of complex challenges and thorny issues.

Our program is provided at no cost to eligible Canadian open access scholarly journals and we wholly fund the staffing and infrastructure of the program through our library’s operating budget. Our institution has elected to do this, rather than charge service fees, as an effort to reduce one of the many barriers to publishing that small scholarly associations face. We’ve also chosen to take a strong stance against charging APCs or submission fees at the University of Alberta, and one condition of participating in our program is that our journals do not charge fees to authors. While we believe this model benefits both journals and their communities, this lack of externally generated revenue comes with predictable challenges around resource constraints.

While we provide a fairly robust suite of services to journals – including technical infrastructure and hosting, training and consultation in publishing tools and practices, digital preservation, content dissemination, and client support, we only provide minimal support for content production. Many (but not all) large commercial publishers provide copyediting, layout and design, and journal management services as part of their service offerings, funded through revenue collected by the publisher through subscriptions or APCs. Within our no-fee model, we simply cannot offer these services to the 70 journals that we publish and instead, we grudgingly off-load the problem to our editorial teams, who must immediately face this issue when they join our program. Finding revenue to fund some of the operational elements of their journal production, without resorting to subscriptions or APCs, is a constant pain point for all of us.

Journal editors have been incredibly resourceful in addressing this challenge. Some, like Evidence Based Library & Information Practice, have fostered a community of dedicated journal volunteers who carry out this labour. Many of our journals belong to scholarly societies, and are able to direct revenues from membership fees into paid positions for copy editors or technical managers. Some of our journals have been successful in securing grants, such as the Canadian Social Sciences and Humanities Research Council (SSHRC) Aid to Scholarly Journals grant, which provides three years of funding to cover costs associated with the journal. Some journals are supported by their home institution or department, and some editors use their own research funds to pay salaries for graduate students to carry out this work. Occasionally, journals have been able to negotiate royalty payments from commercial aggregators to supplement their operations. We have even worked with journals who solicit donations from their community, and very rarely, those who bring in advertising revenues.

Despite this demonstrated variety and creativity in approaches, most of these measures don’t provide stable and consistent support to journals to help cover some of the real costs of publishing. We need a better model!

In my ideal world, libraries, post-secondary institutions, and research granting agencies would redirect their budgets away from paying commercial for-profit publishers indirectly for this work (through APCs, pay-for-open fee options, and subscriptions that prop up for-profit models), to invest instead in directly supporting community-based not-for-profit publishing infrastructure and labour. Here in Canada, we are making small strides forward. For example, Coalition Publica and the Partnership for Open Access directs funds from a consortium of Canadian research libraries into real financial support for open access journals. This is not a radical or new idea – scholarly journal publishing in Latin America has successfully operated under this model for decades. However, a recent exchange between Eduardo Aguado López and Arianna Becerril García from Redalyc, and Johan Rooryck from cOAlition S, on the London School of Economics blog illuminated for me how divergent some opinions are around what a new scholarly communications ecosystem might look like.

Of course, solving a deeply broken and inequitable global publishing system is (perhaps!) out of scope for the Library Publishing Workflows project. However, I am hopeful that the work undertaken to describe and document our own local processes will help to highlight just how much of the work of publishing library programs like ours are already successfully carrying out. Perhaps it’s not such a stretch to imagine a future where we can more confidently occupy this space and present better alternatives to the status quo.

August 18, 2020

Library Publishing Pain Points – Quality Control

By Vanessa Gabler

Vanessa Gabler, University of Pittsburg

Library publishing programs often operate as a collection of individuals or teams working both independently and together throughout various stages of the process. An editorial team (Editor in Chief, editorial board, managing editor, etc.,) typically manages the editorial process, perhaps with guidance from the library. Other portions of the workflow like production, indexing, and support of the software platform, may be managed by the library, the editorial team, third parties, or a mix. Many people work on the same journal with a variety of roles and responsibilities, people are often coming and going throughout the lifetime of a journal, and the work is performed at various locations rather than in a central office housing all participants, so who does what and how can sometimes get confusing.

A significant pain point for us is control over the “publish button.” We use the OJS software platform, and anyone with the role of an editor in the system is able to publish content. Editors create issues in the system and can then publish the issue with the press of a button. We also have several journals using a publish-as-you-go model, and to adapt OJS to this workflow we publish an issue and then add content to it one article at a time. In that workflow, articles become published at the time they are scheduled for publication in a current or back issue, something anyone with the role of editor in the system can do.

However, our program’s workflow requires that only the library publishes content after a quality control review. Our journals’ editorial teams perform the production activities, but we perform a quality control review of the articles to ensure the metadata is complete and matches the content in the PDFs and that there are no problems with the PDFs. This is particularly important for DOIs, which appear on every page of the PDFs we publish.

Common errors caught during our reviews are mismatches in authorship, e.g., an author is missing in one place or formatted differently between the metadata and PDF; changes to titles, abstracts, or references during copyediting that were not updated in the metadata; incorrect issue enumeration in the PDF; and incorrect DOIs in the PDF. Errors that affect the metadata or the DOI cannot simply be corrected in the online system and often require an erratum and/or cleanup work with CrossRef and indexing services. Journal editors typically want to avoid publishing errata whenever possible, and cleanup of downstream services can be complicated. It is far better to catch these errors prior to publication whenever possible.

With our current setup of many people working independently but together, a member of the editorial team will occasionally publish content without notifying us. Our Service Agreements state that only the ULS can publish content after receiving notice at least 3 business day in advance of the intended publication date, but these Service Agreements are not always shared with the entire editorial team and incoming members. We also discuss this requirement during the initial stages of taking on a new journal, but that information can be easily forgotten or not shared with other team members. We will continue to communicate the importance of this to our journal partners and find ways to improve that communication, but the best solution for us would be for the system to allow for greater limitation of the publish and schedule for publication functionality, perhaps allowing for one or both functions to be limited to only admin users when those options are selected by the site administrator.