OJS Implementation: Checklist Before Launching a Journal

Review what an OJS implementation should include: roles, email, policies, testing and documented handover before you launch your university journal.

An OJS implementation should be handed over with a tested workflow and documented responsibilities, not just a web address that loads. If you have to approve the handover for a university journal, we recommend checking what each participant can do, how submissions are received, and who will resolve pending items after closing.

OJS is open-source software from PKP that covers the journal website and the submission, review, editing and publication process.[8] That breadth is a reason to agree on a concrete scope: having the platform available and being ready to publish are different checks.

Agree on which service is being received

It helps to separate a one-off implementation from other work before reviewing any screens. As a contracting criterion, we recommend putting these differences in writing:

The implementation delivers an agreed initial configuration and evidence of its testing.
An upgrade changes an existing installation and needs its own scope.
Recurring operation defines who will handle technical continuity after the handover.
Article production covers the files intended for publication and should be agreed separately.

Scientific decisions remain the journal's. We recommend that its editorial leadership approve the policies, the review criteria and the decisions on manuscripts; the provider configures what has been defined, without replacing that responsibility.

A short document can list deliverables, exclusions, institutional dependencies and acceptance criteria. If the university has not yet provided an email account, for example, it is better to record that dependency than to mark the test as complete.

Review identity, policies and permissions

We recommend checking the configuration against a sheet approved by the journal: name, description, editorial contact, working languages and responsible persons. Presentation texts and policies should have a person who validates them, even if someone else enters them into the system.

It is worth reviewing the author guidelines, the description of the review process, the publication conditions and the statements requested during submission. This article does not set their content: we recommend that the journal decide it according to its editorial and institutional decisions.

Test with the role each person will use

OJS distinguishes access levels: the journal manager can access the workflow and the settings; the section editor works in the workflow without that access to settings, and reviewers access the submissions assigned to them.[7]

For that reason we recommend receiving a simple matrix of people, roles and authorized tasks. The test should be run from those accounts, not only from an account with broad permissions. It is also worth identifying who will manage new accounts, replacements and removals, and delivering credentials through an agreed channel, outside the public record.

Check email delivery and the editorial workflow

We recommend running a complete test submission before opening real intake. It should use fictitious identities and documents, clearly labeled, so that acceptance of the service is not mixed with confidential manuscripts.

The evidence can record the arrival of the submission, its assignment, a simulated review, a test decision and the preparation of a publication in a non-public environment. At each stage, note the account used, the expected result and what was observed.

For email, we recommend checking the sender, the reply address and actual delivery to the agreed test mailboxes. A notification appearing on screen is not enough as a delivery criterion. If a message does not arrive, the record should distinguish the observed problem from its cause, which may require technical review.

Hypothetical handover example

A library receives a new journal. The home page is ready, but during the fictitious submission the editor does not receive the expected notice. We recommend recording that point as pending and repeating the test after fixing it. The example does not describe a real client or assume that all email problems have the same solution.

Validate metadata and give DOIs an explicit status

It is worth agreeing on a fictitious sample to review titles, authorship, affiliations, abstracts, languages and publication files. We recommend comparing what was entered with what the reader will see and confirming who will carry out that review on the real content.

If the project includes DOIs, we recommend documenting the relevant agency, the institutional responsibility, the available credentials and the contracted scope for configuration and testing. Keys should be exchanged through a secure channel, not included in the record.

As an acceptance criterion, distinguish between a prepared configuration and a verified operation. We do not recommend accepting the expression "DOI ready" without specifying what was verified. Nor should automatic assignment or registration be assumed: any planned automation needs a specific check within the agreed scope.

Acceptance checklist

We recommend using this list as the basis of a joint review. Each item should end up accepted, pending or out of scope, with evidence where applicable:

The journal approved its identity, contacts, languages and editorial texts.
The responsible persons tested their roles with their own accounts.
The fictitious submission went through the agreed stages without publishing test material.
The expected messages arrived at the mailboxes used in the test.
The metadata and file sample was reviewed by the journal.
The status of the DOI configuration and its dependencies is explicit.
Access and documentation were delivered through the agreed channels.
Pending items have an owner and a closing condition.
Technical continuity was assigned, including backup management and recovery.

Close the handover without leaving continuity empty

We recommend that the record identify who receives the service, which evidence was reviewed and which conditions still prevent opening submissions or publishing. An isolated screenshot should not replace verification of the agreed path.

PKP notes that running OJS as a web service requires a competent system administrator.[8] That is why it is worth agreeing who will take charge of the server, backups, upgrades and incident response after implementation. We do not recommend assuming those tasks will fall to the editor.

OJS ONE describes implementation, operation, support, backup and tested upgrade services.[11] You can review the general scope at OJS ONE OJS services. To assess a specific implementation, contact OJS ONE with the status of your journal and the deliverables you need to validate. The applicable scope must be set out in the agreed proposal.

Frequently asked questions

What should an OJS implementation include before a journal launches?

It should include a configuration approved by the journal (identity, policies and languages), roles tested with each person's own account, a complete fictitious submission, verified email, a reviewed metadata sample and an explicit DOI status. Everything should be recorded in an acceptance document with pending items and owners.

What is the difference between implementing, upgrading and operating OJS?

An implementation delivers an agreed initial configuration with evidence of testing; an upgrade changes an existing installation and needs its own scope; recurring operation defines who handles technical continuity (server, backups and incidents) after the handover. It is worth putting these differences in writing.

How do you check that OJS email and roles work?

With a complete test submission that uses fictitious identities and documents, and with each role's real accounts rather than an account with broad permissions. For email, check the sender, the reply address and actual delivery to test mailboxes; a notification appearing on screen is not enough.