PKP Minnesota Sprint Summary #3 – Continuous Publication

The third sprint summary from the PKP Minnesota Sprint, hosted by the University of Minnesota Libraries in May 2024, is now available. 

Sprints involve PKP community members joining diverse groups to work on PKP software and support. The University of Minnesota Libraries hosted six working groups at the PKP Minnesota Sprint in May. This is a summary of one such group’s work.

Continuous Publication

Continuous publication includes both “rolling publication” (publishing individual articles as they are ready) and “forthcoming publication” (publishing “author’s version” articles before the formal layout and page numbering). This group found some outstanding issues, received updates on them, and discussed possible resolutions.

One example was the seemingly random ordering of articles in a continuously published issue. The group suggested that editors have the option to add the article in the “article order” view of an issue and lock in the order.

They also tested the Forthcoming Plugin, recommending some tweaks to ease the burden on editors having to unpublish and republish different versions, and additional possibilities for notifications.

Working Group Members 

• Jeanette Hatherill, Coalition Publica
• Susan Collins, Crossref
• Emma Molls, University of Minnesota
• Lauren Collister, Invest in Open Infrastructure
• Audrey Larivière, Érudit 

Background 

There has been a shift in publishing models at the University of Minnesota, where hosting and publishing institutions use new approaches to maintain competitiveness. Meanwhile, at the University of Pittsburgh, continuous publishing has become the norm, fulfilling the promise of digital and open-access publishing. 

However, this transition needed workarounds and has raised issues surrounding data models and workflows, creating a need to reconsider existing mental models, particularly around indexing in other services.

One common challenge is the use of pre-publication versions followed by the final version, leading to random article ordering when using the current workaround. Additionally, there are concerns with dates within the current issues, as when publishing an article, the issue date becomes an issue itself.

Goals 

• Review the Hannover sprint document
  • Possibly answer outstanding questions
    • Portico uses “Issue” as a unit, OJS allows deposits to Portico only by Issue
    • The problem remains that “item publication” is not possible for individual articles, issue only (see GitHub issue #4504) 
• Review York University documentation
• Review open GitHub issues
• Make recommendations based on 3.4 and future development
• Potentially document 3.3 workaround advice, keeping in mind PKP Education Interest Group goals of pragmatism, the why of doing something

Results

Confirming & testing random ordering issues with Continuous Publication 

We tested the issue #8998 in PKP Testdrive 3.4 in a new issue. The question is, how is the order of articles added to a continuous publication determined? 

Observed problem

• The publication date of the individual article is what determines the order:
  • The group published an article with a date of 2021, and it was at the bottom of the list
  • Then they published an article with a May 13, 2024 date, and it was on top
  • Then they published an article with a 2022 date, and it published the article in the middle of those two
  • This showed them that their hypothesis about the publication date was wrong
• The GitHub issue reports that articles published with the same publication date will flip around in the Table of Contents:
  • Publishing another article with a date on May 13, 2024, made it so that it was published third in the list, between the 2022 and the 2021 articles

Steps to reproduce

In an open issue

1. Publish an article with a past date
2. Publish an article without a date (which gives the article today’s date)
3. Publish an article with a date between the past date article (from step 1) and today’s article (from step 2)
4. Publish an article without a date (which gives the article today’s date)
5. Publish an article without a date (which gives the article today’s date)

Actual order

1. First one as today’s date (from step 1)
2. Article with publication date between the oldest article and today (from step 3)
3. Today’s date 2 (from step 4)
4. Today’s date 3 (from step 5)
5. Oldest article 2021 (from step 1)

Expected order (by publication date – newest on top)

1. Today’s date 3
2. Today’s date 2
3. Today’s date 1
4. 2022
5. 2021

An editor might expect the newest articles to appear at the bottom of a list, which would be

1. 2021
2. 2022
3. Today’s date 1
4. Today’s date 2
5. Today’s date 3 

Neither of the expected outcomes occurred. 

From the user interface, we cannot easily determine what is causing this order. It is not the submission ID,  submission date, publication date, author name, or article title. Therefore, we believe that the problem reported in GitHub issue #8998 is still a problem in OJS 3.4 in the test drive.  

A proposed solution to this problem

• Okay: be able to predict what order a newly assigned article would appear in the new issue (e.g. on top)
• Okay: Allow editors to choose the default behavior for continuous publication by publication date – newest on top, or oldest on top
• Best: Allow editors to choose where the newly published article will appear in the list, perhaps with a pop-up or sending editors to the Issue Article Ordering view after hitting the “Publish” button
  • This could be an optional feature that editors could turn on in the configuration somewhere. There should still be the default mentioned in #2

To continue working on a solution, the group analyzed the Forthcoming Plugin, workflow, and workarounds further. They found a need to for additional functionality on the plugin that affects article handling. Testing indicated a possible need to consult a metadata expert in this space.

Further, there is no notification when a new article is published to “Forthcoming”, and one is only notified when the Forthcoming Issue is published. The group began thinking about PKP adopting continuous publication and article notifications in OJS natively. 

Next Steps 

• Develop the capability for editor to be delivered to “article ordering view” when an article is assigned to Continuous Publishing to solve the random arrangement of articles 
• Refine the notification functionalities
• Publish documentation outlining solutions around continuous and forthcoming publications
• Answer an open question about whether publishing an article in Online First and it not disseminating to via the metadata harvesting protocol OAI is a problem or not

Thank you

We once again thank the Sprint sponsors, host institutions, and all participants for their valuable contributions to the PKP user community. Special thanks to University of Minnesota Libraries, Library Publishing Coalition, and Crossref for their support and partnerships.