Allow papers to be withdrawn without recording a rejected decision

[jmacgreg]

Update: 2020-08-04: It should be possible to withdraw a paper at any point during the editorial process without recording a rejected decision. Following the discussion below, it seems the preference is for the editor to have this control. The author can send a request to the editor.

Original description:

Authors should be able to withdraw papers at any time prior to final publication. Authors can currently only withdraw/delete papers that are incompletely submitted. Some questions:

• is there a specific cutoff for when an author can or cannot withdraw a paper without further intervention/steps taken - eg. after publication?
• what would the procedure be? A "Withdraw" button and an associated email to the editor responsible?

[asmecher]

Interested in @willinsky's thoughts on this.

[carzamora]

In the editorial process, you not should withdraw your paper at any time, make this part of the process so easy is not a good idea (I say this as editor and author), is important at the first part of the process but if this manuscript was reviewed and improved for publishing in that journal? withdraw the submission is anti-ethical and the reasons should be very justified.

[amandastevens]

What about if the author still has to contact the editor to request that the submissions be withdrawn but there is an option for the editor to record the decision as "withdrawn" rather than "rejected."

[alexxxmendonca]

I agree with @t4x0n and @amandastevens.

I don't think the authors should have full liberty to withdrawn their own submissions. They should be able to request it and the ones to actually do it should be the journal.

[carzamora]

I agree with you @alexxxmendonca but, if this will be implemented, when the author's making the request is important to obligate the author to say WHY they are requesting withdraw their submission, like an obligated text area. In my experience, withdraw a manuscript is not a common choice and normally it is accompanied by a problem with an editor or excessive delays in the review process, but is important explain that to the editor in chief, in some cases this is more like a warning and the editor in chief can make a move for accelerate the process and avoid the withdraw.

[alexxxmendonca]

I fully agree, @t4x0n.

[marcusrossberg]

Shouldn't the decision when an author is allowed to withdraw be left to the relevant editor? Not having the function available at all seems to me (speaking as an editor) to be a disadvantage.

[NateWr]

We've had a number of requests from the community for a withdrawn editorial decision that does not require recording a rejected decision. See the forum. I've applied the Community Priority label and adjusted the description to reflect the discussion above.

[carzamora]

Yes, I agree with the Update:

Update: 2020-08-04: It should be possible to withdraw a paper at any point during the editorial process without recording a rejected decision. Following the discussion below, it seems the preference is for the editor to have this control. The author can send a request to the editor

[willinsky]

On Withdrawal, Retraction, and Correction I agree with everyone that the editor alone should be able to withdraw or retract a paper. I would suggest that we structure it in the following way (as this would potentially add another element to the Journal Integrity Initiative that I have been promoting for OJS):

On the editorial workflow, we add another button in the Submission stage and underneath "Decline Submission" called "Withdraw Submission" (black font on gray background) that will turn to "Correction / Retraction" after publication, with this button remaining active with the submission in the archives.

OJS/OMP (a) Prior to publication, clicking "Withdraw Submission" would call a Withdrawal pop-up that will offer a space for the "Withdrawal Notice" with the caption "Explain the reason for and instigator of the withdrawal." The submission is then placed in the archives, where its status will be listed as “Withdrawn” and in the Submission stage will include the "Withdrawal Notice." This button button remains active, enabling the notice to be edited and updated.

(b) After publication, the Withdraw button becomes "Correction / Retraction" and remains part of the workflow. Clicking it would call up a Correction/ Retraction pop-up, for which the editor selects the appropriate option. For the correction of the article, there should a “Correction Notice” box with the caption: “Provide an explanation and description of the correction, identifying the instigator and whether the correction has been made to the article PDF and/or HTML." The Correction Notice appears on submission page and on the article landing page along with the date the correction is recorded. "Corrected:" is added to the article's title in the metadata. For the retraction of the article, the retraction of the submission is recorded in the submission page (which will remain in the archive) was initiated by the editor or the author, and the reasons given for the step (which will be included in the Submission stage), as well as a box for entering a "Retraction Notice," which is to be added to the article landing page (with the metadata, including abstract, retained). “Retracted” is added to the article's Table of Contents entry (without replacing the original title and authors). Editors should be instructed in the Retraction pop-up: "Add the Retraction Notice to the article's galleys, along with the indication RETRACTED on every page (e.g., using a watermark), as this is not something that OJS can currently do for the journal." The "Correction / Retraction" button remain active, enabling the notice to be edited and updated.

OPS There will only be the "Withdraw Submission" button for the moderators and managers and its use will call up a Withdrawal pop-up that will offer a space for the "Withdrawal Notice" with the caption "Explain the reason for and instigator of the withdrawal." Taking this step will remove the preprint from its landing page and the "Withdrawal Notice," with the date it was recorded, will replace the abstract. The submission will have "Withdrawn:" added to the front of the title of the preprint, and the "Withdrawal Notice" will replace the abstract on the Publication page. This button remains active, enabling the notice to be edited and updated.

[alexxxmendonca]

For OPS, ASAPBio has came up with a set of best practices and recommendations for handling with preprint withdrawal and removal at the Defining preprint withdrawal & removal section of this document: https://osf.io/8dn4w/

From what I could tell, it seems to be very similar to the journal approach, but I think it would be worth making sure that OPS is following these recommendations.

[willinsky]

Thanks @alexxxmendonca for the reference to the paper with the "withdrawal and removal" recommendations. My suggested principles above have been further edited, are now largely in accord with its recommendations and examples (they do say these are "not settled practices" but I went with what I found made the most sense and aligned with OJS.

[ajnyga]

Has someone discussed with Crossref on how withdrawal should affect the DOI or the metadata attached to the DOI?

Also, do we want the withdrawal to affect all versions of preprint by default? Can there be a situation where only the latest version of the preprint is withdrawn?

[asmecher]

@willinsky, I would be on-board with your proposal for OJS older than 3.2.x, but now that 3.2.x is introduced with versioning I'm not so sure we can rely on the Editorial Decision part of each workflow stage when the publishing action is elsewhere. The Publication area is now a separate tab from the Workflow and has publication status information:

I would expect retractions/withdrawals to happen here, rather than on the workflow tabs.

[NateWr]

Can I suggest that we separate out withdrawal (before publication/posting) and retraction (after publication/posting) into two separate issues/discussions? Retraction has a lot of implications that need to be handled carefully (notice on the landing page and galleys, update of metadata deposits and distribution, the ability to indicate a date and reason for retraction, etc), whereas withdrawal is comparatively straightforward.

This issue could focus on withdrawal and a new one could be created to discuss retraction.

[ajnyga]

Sounds like an important distinction which was mentioned above as well, but only realized it fully now.

Withdrawal would then be something you can do in OJS/OMP/OPS as long as the submission is not published/posted online. The button could be situated under the decline button. This I can implement fairly quickly to all three applications.

Retraction would the be something that happens to a published submission. The button should be under the Publication tab. Retraction would then affect the public landing page and metadata and basically create a tombstone? Would this be something that could be done to a single version of the submission? Do we have use cases for this feature?

[NateWr]

Withdrawal would then be something you can do in OJS/OMP/OPS as long as the submission is not published/posted online. The button could be situated under the decline button. This I can implement fairly quickly to all three applications.

Let's not tie this to a particular stage decision. Instead, I'd like to think about where this might sit outside of the workflow. (It will also better prepare us for retractions.)

For a while, I've been thinking about converting some of the buttons at the top into a dropdown menu. This will also give us an extensible pattern for other plugins to use as needed.

Clicking this button should open a modal to confirm the withdrawal and present an email for review, that would be sent to the author(s). The editor should have an opportunity to enter a reason for withdrawal (one-line text field).

When a paper is withdrawn, let's add a withdrawn badge at the top and hide the editorial decisions behind a prompt, similar to how we do with decisions that are completed on a stage.

Finally, the status will need to be reflected in the publications tab and the schedule for publication button should be removed.

We will need a new STATUS_WITHDRAWN for this. Editorial stats might get a little complicated (acceptance/rejection rates need to make sure that they are excluding withdrawals from the divisor). And we'll need to make sure that these submissions are moved to the archived lists, and review assignments are cancelled or otherwise updated.

Here's my list of things that I think would need to happen:

1. UI additions as described.
2. New email template for withdrawal notice for authors.
3. New email template for withdrawal notice to reviewers, that would be sent to assigned reviewers with a pending review assignment.
4. Pending review assignments should be unassigned. Completed review assignments can be left as-is.
5. On withdrawal, add an entry to the submission's activity log that includes the reason for withdrawal.
6. A new STATUS_WITHDRAWN constant and an API endpoint to PUT /submissions/{id}/withdraw (
7. Submission lists should load withdrawn submissions in the archive list.
8. When withdrawn, the "Withdraw Submission" button should change to "Revert Withdrawal". If a withdrawn decision is reverted, an event should be added to the activity log but no notifications sent to authors/reviewers. Editor will need to decide who to alert and whether to restart review assignments or make new assignments.

Now there are a number of more technical questions about how to perform this withdrawal action, and what impacts it has. I think that we should have a separate service method, PKPSubmissionService::withdraw(), that encapsulates all of the actions that need to happen when a withdrawal takes place.

Additionally, we will need some validation rules in place to prevent a withdrawal from happening outside of this service class. Probably a new API endpoint at PUT /submissions/{id}/withdraw. For example, it should not be possible to withdraw a submission when one or more publications are published or scheduled. The editor should be asked to unschedule the publication(s) before withdrawing.

The API endpoint handler for editing a submission, PUT /submissions/{id} should return an error if the user tries to edit the status to STATUS_WITHDRAW. The error message should instruct them to make the requerst to the withdraw endpoint. We will still allow this status change in the PKPSubmissionService::edit() method, but restricting the API provides some protections from accidental misuse of the API.

Retraction...

Let's talk about that in a separate issue. I think from a UI perspective, making a retraction decision could be similar to making a withdrawal decision. But all of the other details will need to be worked out separately.

[alexxxmendonca]

I am not that confident that withdawal should be restricted to pre-publication.

We've had cases of duplicate preprints being posted by accident (author confused and made a new submission instead of a new version). Both were posted but we needed to remove one of them. I am not sure this would be the case for a retraction. There is nothing ethically wrong for it to be "retracted".

[ajnyga]

Is that a case where the submission could be just deleted?

[alexxxmendonca]

It might have been accessed and linked and referenced so for consistency's sake, we need to keep the record but update the PDF.

This is what we did (check the PDF): https://preprints.scielo.org/index.php/scielo/preprint/view/547

[NateWr]

@alexxxmendonca you're right that withdrawal/retraction is going to be a different thing in OPS. Because there is little time between submission and publication, most withdrawals will need to occur after publication. And retraction isn't really a thing in preprints, is it?

From a technical perspective, withdrawing after posting a preprint in OPS will be very similar to a retraction in OJS/OMP. For this reason, I think that we should discuss and implement it in a separate issue that discusses retractions. Retractions (OJS/OMP) and after-posting withdrawals (OPS) are considerably more complicated because we must account for the fact that the item has been publicly distributed.

[willinsky]

Just to reinforce Nate’s point — and I’m happy to see withdrawal and retraction in separate issues -- the important point here is that we want to be clear that papers are not published in OPS, they are posted or shared or circulated. This has become increasingly important with Covid-19, in which the distinctions between a work that has been published (with peer review) and which circulated in advance of publication have become part of media take-up and public awareness.

As a result, to apply the general journal standards to this distinction, papers posted in OPS can be withdrawn (and thus “retraction” per se, does not apply). We are upping the game, with regard to the integrity, by asking that “withdrawal” be made public with an explanation.

Thanks John

On Oct 8, 2020, at 6:32 AM, Nate Wright notifications@github.com<mailto:notifications@github.com> wrote:

@alexxxmendoncahttps://github.com/alexxxmendonca you're right that withdrawal/retraction is going to be a different thing in OPS. Because there is little time between submission and publication, most withdrawals will need to occur after publication. And retraction isn't really a thing in preprints, is it?

From a technical perspective, withdrawing after posting a preprint in OPS will be very similar to a retraction in OJS/OMP. For this reason, I think that we should discuss and implement it in a separate issue that discusses retractions. Retractions (OJS/OMP) and after-posting withdrawals (OPS) are considerably more complicated because we must account for the fact that the item has been publicly distributed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/pkp/pkp-lib/issues/1813#issuecomment-705570483, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACO45XFSOYOYS7NHCSGOC6DSJW5NNANCNFSM4CPKROKQ.

[alexxxmendonca]

And retraction isn't really a thing in preprints, is it?

Retraction is more associated with peer-review, indeed.

I very much agree with @willinsky's comment.

While we are discussing this, I'd recommend checking the section Defining preprint withdrawal & removal of ASAPBIo's Building trust in preprints: recommendations for servers and other stakeholders report for suggestions on how we can deal with this.

They recommend "Withdrawn" and "Removal". "Removal" seems to be used in much more serious cases (Serious legal issues, erious risk to public health or potential public security concerns).

[NateWr]

Thanks @alexxxmendonca! That's precisely the information we need, and it even has examples! It's clear now that withdrawal/retraction/removal in OPS will be very different from OJS/OMP. I've created a new issue based on the recommendations in this document and we can continue discussion there: https://github.com/pkp/pkp-lib/issues/6271.

[willinsky]

Agreeing with Nate's "More" dropdown approach (as well as status indicators), which makes particular sense for withdrawal/retraction due to the rarity of the event and as the More dropdown remains in place throughout the workflow and after publication. I think that the two can be treated as a pair rather than separately. Here's one way it might be handled:

More /\

• Activity Log
• Library
• Remove item

"Remove item" leads to....

Remove Item

( ) Withdraw submission, which takes place prior to publication (and also applies to posted preprints).
( ) Retract publication, which takes place following publication.

Explain the reason for and instigator for this move, which for the withdrawal will be dated and added to the submission metadata under the title Withdrawn and the submission archived, or for the retraction will be dated and posted on the article landing page as a "Retraction Notice" with "Retracted" added to the Table of Contents (while the editors should add this notice and explanation to the publication itself).

[promedacademy]

I think authors have the right to request to withdraw their articles at any time before publication, this is because some journals cannot fulfill their promises and presence of withdrawal button increase the trust of the authors towards the journal and that it is not a predator journal the final decision to accept the withdrawal request might be assigned to different users roles from section editors , journal manager, or editor-in-chief

[suenugus]

I agree with promedacademy that authors should be able to withdrawn submissions. In any event the ability for someone to do this is essential for all sorts of reasons. I hope the priority tag on this will have this enabled soon.

[ajnyga]

This is how Withdrawal, Retraction and Removal is handled in OJS/OPS/OMP. Note that the central difference here is that Withdrawal means different things in preprints and articles as it has been shown in the discussion above.

Withdrawal in OJS and OMP happen before the publication. In OPS this will be called Cancellation. It means that the author decides that they do not want to post their preprint / article at all. In the system level the status for this will be STATUS_CANCELED (system level meaning that we will have a variable with this name, not visible for common users).

When the article is published / preprint posted it may be either Retracted (OJS/OMP) or Withdrawn (OPS). The difference here is that an unpublished Article in OJS is in fact the same status for the work as having a posted Preprint in OPS. This status is called in system level STATUS_RETRACTED.

A third new status is STATUS_REMOVED. Here the published Article / posted Preprint content is actually removed.

Both STATUS_RETRACTED and STATUS_REMOVED will cause implications to DOIs.

stage	system level	OJS label	OMP label	OPS label	DOI	Files	TOC/Catalogue
submitted	STATUS_CANCELED	Withdrawn	Withdrawn	Canceled	no registered DOI, no problems
published/posted	STATUS_RETRACTED	Retracted	Retracted	Withdrawn	Landing page with retraction note	Files still accessible?	Marked as retracted in TOC
published/posted	STATUS_REMOVED	Removed	Removed	Removed	Landing page with retraction note (we still need this for the DOI!)	Files not accessible	Not in TOC or search

STATUS_CANCELED is handled in this issue. STATUS_RETRACTED and STATUS_REMOVED will be handled in https://github.com/pkp/pkp-lib/issues/6271

[pmangahis]

+1 from another hosted clint that would be interested in this

[forgive38]

Hello, our journals need the STATUS_CANCELED too. Thank you in advance

[ajnyga]

ping @NateWr I will start working on this now.

Referring to table presented above https://github.com/pkp/pkp-lib/issues/1813#issuecomment-1053547856 only STATUS_CANCELED is handled in this issue. STATUS_RETRACTED and STATUS_REMOVED will be handled in #6271

This basically means that we will have a new decision (STATUS_CANCELED) in the system which will mean in:

• OJS: before the submission is ever published, it can be withdrawn at any stage
• OMP: before the submission is ever published, it can be withdrawn at any stage
• OPS: before the submission is ever posted, it can be canceled at any stage

Question 1: Who is able to do the decision?

• In my opinion ROLE_ID_SUB_EDITOR and ROLE_ID_MANAGER. Authors can request this simply by using the Discussion tool. This would be a simple model.

Question 2: When can this decision be made?

• In my opinion at any stage before the submission is submitted/posted. The Editorial History should point out the stage when the decision was made. If a journal does not want to allow Withdrawals after a specific stage, they can of course follow that policy. If the submission has been public even at some point, we should block it. This is because you might for example have a registered DOI at that point. #6271 will handle those cases.

Question 3: How do we present this in the Editorial History?

• Who made the decision and at which stage.

Question 4: Should we allow taking back the decision?

• Definitely, the less we have actions that can lead the editors to an dead end, the better. Unless you see a problem here.

Question 5: Where do we want to place the button for the Decision?

• Nate, I would like to hear your take on this!

Question 6: Do we send an email about the Decision?

• I would say yes, to all authors of the submission. Just noting that a STATUS_CANCELED decision was made and the submission is no longer processed.

Question 7: How do we present this in the Editorial Statistics / archive

• We need a new row "Submissions Withdrawn/Canceled". STATUS_CANCELED is not taken into account when looking at accept/reject figures. In the archive we will have a new group of submissions besided published and rejected.

Question 8: Is this colliding with some other decision?

• Based on the description, do we need to have this decision https://github.com/pkp/pkp-lib/issues/6982 separately if we add the one discussed in this issue (STATUS_CANCELED)?

Something else?

[NateWr]

Thanks @ajnyga, that's a really helpful summary. I agree with everything you posted. More comments:

If the submission has been public even at some point, we should block it.

Do you have something in mind to determine this? I can only think of checking the activity log for a SubmissionEventLogEntry::SUBMISSION_LOG_METADATA_PUBLISH entry. We should probably back this up with a check of the submission's status, which will be published if any publication is published.

Should we allow taking back the decision? Definitely...

We have a bit of a naming pattern you can follow with the Decline and RevertDecline decisions. When reverting the withdrawal, always change STATUS_CANCELLED to STATUS_QUEUED. If they want to publish or decline it after that, they can take another decision.

Where do we want to place the button for the Decision?

I think the More dropdown I described in this comment is my preference for now.

Do we send an email about the Decision? ... yes, to all authors of the submission...

I think we need a few emails:

1. To the assigned author.
2. A copy of the email to all contributors. (See DecisionNotifyOtherAuthors)
3. An email to all assigned editorial staff (managers, subeditors, assistants).

do we need to have this decision https://github.com/pkp/pkp-lib/issues/6982 separately

I don't think so? They seem different to me and can be implemented separately.

Something else?

A few more things to note:

1. Submissions in the archived list should show a withdrawn badge instead of declined or published.
2. Show "Withdrawn" at the top of the submission workflow page, where Scheduled and Published appear next to the title.
3. Currently, the status of a submission can be edited through the API. I'm planning to lock that down. But we should make sure that is in place when this work is completed, because we want to control who can change the status of a submission and when.
4. When you dig into the decisions, you'll find one hurdle is that every decision type has to declare what stage it appears in. You'll need a separate decision constant and class for withdrawal in each stage. Kind of an uncomfortable situation but just use a base class for now, and create a slim child class for each stage.

[ajnyga]

Do you have something in mind to determine this? I can only think of checking the activity log for a SubmissionEventLogEntry::SUBMISSION_LOG_METADATA_PUBLISH entry. We should probably back this up with a check of the submission's status, which will be published if any publication is published.

The activity log entries are what I was thinking of. I think we discussed using those in some other issue at some point. But I can see no problem if we check both the activity log and current status. Or do you think that we would want that data saved in a more easily accessible way? I mean some marker in publication_settings or elsewhere saying that this publication has been published at some point? That might be useful also when looking at things like tombstones, retraction etc.

I don't think so? They seem different to me and can be implemented separately.

Ok, I was thinking about this from the perspective of limiting the amount of decisions we have. But it could be that my thinking is influenced by the fact that adding new decisions used to be quite difficult. I was thinking that for an editor the most important thing is not to confuse these with actual rejected submissions. Not sure if many would like to see a difference between Withdrawn and just moved to archive for another reason. But of course in the long run better to have a status like STATUS_DELETED if that is what we are going for in that issue.

When you dig into the decisions, you'll find one hurdle is that every decision type has to declare what stage it appears in. You'll need a separate decision constant and class for withdrawal in each stage. Kind of an uncomfortable situation but just use a base class for now, and create a slim child class for each stage.

Ok, good to know!

[NateWr]

Or do you think that we would want that data saved in a more easily accessible way? I mean some marker in publication_settings or elsewhere saying that this publication has been published at some point?

No, I don't think we should add anything in here just yet.