August 18, 2020
Library Publishing Pain Points – Quality ControlBy Vanessa Gabler
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.
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.