Unsubmitting incomplete submissions (return to authors)

[robinhood1362]

Hi there,

When you get submissions that do not adhere to the author guidelines of the journal, you want authors to correct them.

1- One way is to "archive submission" and ask authors to submit revised content as a new submission. This can be frustrating if an author keeps missing one little thing again, and you keep archiving each submission until they get it right.
2- Another way is to ask them to correct the original submission, using edit supplementary files, or edit metadata, and so on. However, it's not possible to edit the original submission file for the moment (Dec 2012), and if you receive a high number of submissions daily, and say, you've asked authors to submit blinded versions of their manuscripts, and they do not, it would create an unnecessary chore for the editor to replace the file with a blinded "review version" on behalf of the author.
3- A third option (not available in OJS as of December 2012) is to unsubmit a submission, that is to say, return the submission to the state before hitting the submit button. This feature would return the submission to the author dashboard allowing it to be edited by the author as per instructions given in an email, and would not allow the editor's dashboard to be cluttered by submissions that still need minor corrections before peer review.

Anyone thinking of a similar situation?

Can someone think of a way to add something like a "unsubmit" link next to the "archive submisson" link in the submission page?

Best,
Sina

[ramon]

Hello sina,

OTOH, after the submission process is completed, the Author has the option to upload new versions of the document at any point within the editorial process.
All that is required is for him to upload a revised version and notify the editor. Then, the editor chooses the latest version (can download it and revise it, as well as submit a new Editor version for control and send it to review/copyediting/etc...)
Isn't this enough?

If you want to be picky, you can always reject submissions and notify the author the reason the submission has been rejected (not compliant with journal standards, for example). I usually recommend this to JM and Editors, but there are always exceptions...

I usually suggest that JM provide a link to an article template, which will then "force" authors to submit the article close to the standards.
This "template" can be added within the submission checklist and/or the submission guidelines pages (and anywhere else you wish to submit it - you could add templates for each section, for example). With the Public Folder Browser plugin, uploading the templates is easier (you should create a template for every text editor you accept submissions from).

PS: I have suggested that OxS allows the author to write the article within the technology, without the need to upload a text file for revision. This way, indexing, reviewing and revision control would be all within the system (an XML, or other structured document micro/format). This could be added as a plugin or optional process. Once the article is ready for submission, it could be sent to review. However, the review process is still highly "manual", at least from our experience in Brazil (I digress here...)

_______________________________
Ramón Martins Sodoma da Fonseca
Analista em C&T
Coordenação de Tecnologias de Informação
Instituto Brasileiro de Informação em Ciência e Tecnologia - IBICT
Ministério da Ciência e Tecnologia - MCT

[robinhood1362]

Thank you for your reply Ramon. As I said earlier, technically speaking, there are many ways in OJS to receive corrected versions of manuscript from authors. However, none can change the submission date, except for an option where we unsubmit a manuscript (temporarily) and ask authors to correct their submission. The 'received' date of a published article is particularly important for assessing the time taken for the manuscript processing by a given journal, and it also has implications regarding the priority of an original work or idea compared to similar works, though less important.

When journals unsubmit a manuscript in the online world, they literally return it to the author (again temporarily) for corrections. When author submits the corrected manuscript again, the 'received' date will be a new date. If the author decides not to resubmit their unsubmitted content, so be it, as we're not waiting for receiving a revised version from the author, looking at a clutter unassigned list of manuscripts. This way, the remaining items on the unassigned list will show only those submissions that need editor's action, not patience!

I suggest an 'Unsubmit submission' link next to 'Archive submission' link in OJS, leading to an email template titled 'Submission temporarily unsubmitted'. This returns the submission to the author's dashboard to the state before hitting the submit button, and clears it from the unassigned list of the journal manager / editor.

5 stars to your PS regarding XML submission input! I think it's the future of online submission systems, but still an unsubmit option would be necessary! Also, automatic parsing of submission files may eliminate the need for individual back and forth interacting with authors, as the software will notify the authors, before submitting content, of incomplete or incompetent items (even the proportion of different sections of an article, the accuracy of the cited bibliography list, plagiarized text, the quality of images, missing headings in tables, abbreviations for which a full form has not been given, etc) and we may well be able to concentrate on scientific evaluation rather than struggling to receive submissions that merely adhere to the author guidelines, or are only technically sufficient!

Sina

[ramon]

Hello Sina,

Thanks for the clarification!!
In my opinion, a very valid use case!!!

Maybe adding a new option to the editor's decision list could be a way to modify OJS easily, requesting the author to resubmit the article, returning it to the "incomplete"/"resubmit submission list.
This may be easier to develop than anything more complex, and still does much of what you'd like to see, reusing much of the code.
Hopefully PKP team is reading this, or you can register at Bugzilla and request the feature (or I can do it for you, if you'd like).

Have you tried the "resubmit for review" option? I know it's a step ahead of the process from your point of view, but the flexibility it provides can be used for may purposes. For example, you could use the first round of review for verifying document integrity. Register someone responsible for that process, add a custom form and only move to the next round of review once the article has been approved. You'll have to check if this helps, as it may be inconvenient to see lots of articles "in review". I can't remember how the list is displayed. Nonetheless, it could help you while the feature is not available (if ever). We usually suggest using the review process in creative ways (for translation and copyediting as well). Heck, you could use it as type of collaboration system, where the articles start to be created there, with the form being textarea fields for "reviewers" to write the article's content, edited and new compiled version being uploaded.

PKP has also been keen in working with online submission conversion and control, but some of the editorial processes are still highly manual (mainly review and copyediting, the latter needing/loving to actually print and make handwritten notes on paper). The people in these types of roles are reluctant to work in any other way. Until there is a cultural change, it will be difficult to force people to change their processes. The majority needs to request this, because the article HAS to start intelligent (already marked-up), instead of processing it to become smart. Otherwise, we'll build technology that soon will be outdated, difficult to maintain, and so on.

PS:: The following is just a "rant", no real need to read past this...

There are many projects today trying to empower content managers to be able to work and edit content faster and better.
I haven't read through much of this yet, but the Aloha Project seems interesting.

Giving roles the option to work in multiple ways is good, but there will be a time when a decision needs to be made.
How that decision affects online publishing will remain to be seen. I think there is a lot going on, a raging war between Operation Systems and the Web, as almost everything today IS on the Web.
I mean, our electronic devices (laptops, desktops, smartphones, tablets) change and get obsolete very quickly. Maintaining and upgrading technology is an issue and this in turn, impacts any business or working process that requires technology.
For example, Window(s) 8 has changed drastically, pushing way desktop users (or forcing them to keep "obsolete" operating systems and software). How do we cope with that?

Soon, everyone WILL HAVE to start producing (at least saving) their work online, as keeping multiple backups is a hassle - you never really know which one is the latest version, until you loose it and need to restore a REALLY old version.
In my opinion, the advantages of fully working online, even today, without all the possible desktop software features, outweigh the cons. Online asynchronous collaboration, commenting, review and versioning (Google Docs and ZOHO suite, for example) strike out as excellent features. But the current tools are difficult to integrate with all the other software we need to work with (always need to export, download, login, upload - highly bureaucratic processes). AND you depend on infrastructure: a good, reliable Internet connection... not always available.

Also, we build a software dependent of other software, and there is a limit to how much you can depend on others...

Thank you for reading this far...

_______________________________
Ramón Martins Sodoma da Fonseca
Analista em C&T
Coordenação de Tecnologias de Informação
Instituto Brasileiro de Informação em Ciência e Tecnologia - IBICT
Ministério da Ciência e Tecnologia - MCT

[robinhood1362]

Thank you Ramon for your input. I think this conversation is turning from a simple feature request into a fruitful debate on journal publication processes.

We are on the same page and I think many share this problem regarding the use of different review rounds and editor decisions like 'resubmit for review' for the purpose of initial evaluation and processes like copyediting and translation apart from the peer review itself.

I think the development of OJS into the system that exists now, with special purpose pages like summary of submission, review, editing, and history, suits a typical 'in format' submission, with editor sending it for peer review which takes a couple of rounds and then to the editing when the manuscript gets a minor copyediting treatment leading to the galley and proofing and finally publication. This sectioning is also helpful for beginners who have just started managing editorial processes.

What happens in real world even in highly esteemed journals is rather customized for all or at least a percent of submissions. What I'd like to see in a submission management and journal publication platform is a simplified log-like approach, probably one like the history page of submission in current OJS versions, where all events regarding any submission is recorded in rows on the 'submission page' in the chronological order with the relevant versions of files next to each event. This would simplify the process while making it highly customizable, and one could get a sense of what has happened by going through the log. Different roles (authors, reviewers, editors, copyeditors, etc) will see only those events and files that they are entitled to see and have access to.

This is how I see it. I don't like to name it review or copyedit page, and then do other work there. I'd like to know other people's views on this.

Best,
Sina