We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.

Bug 3799 - Editors In Review queue enhancements
Editors In Review queue enhancements
Product: OJS
Classification: Unclassified
Component: User Interface
To be determined
PC Mac OS X 10.0
: P1 enhancement
Assigned To: PKP Support
Depends on:
  Show dependency treegraph
Reported: 2008-10-03 16:52 PDT by James MacGregor
Modified: 2013-05-29 15:20 PDT (History)
2 users (show)

See Also:
Version Reported In:
Also Affects:

Mockup of proposed notifications in Editor's Review Queue (86.63 KB, image/png)
2008-10-03 17:10 PDT, James MacGregor

Note You need to log in before you can comment on or make changes to this bug.
Description James MacGregor 2008-10-03 16:52:28 PDT
Two main enhancements: 

1. If a reviewer declines to undertake a review, this should be clearly marked in the Editor's Submissions in Review queue. Perhaps the ruling itself (if the reviewer makes a ruling, that is) should also be listed. 

2. Optionally, it would be nice to see at a glance which reviewers are assigned to a given review. I'm not sure whether there are security/accessibility issues with putting reviewer user names on this page or not.
Comment 1 James MacGregor 2008-10-03 17:10:33 PDT
Created attachment 1008 [details]
Mockup of proposed notifications in Editor's Review Queue

A couple of notes wrt this mockup: 

-- I am unclear on the current difference between 'Done' and 'Ruling', as currently they are both dates; it would be nice to actually list the ruling itself, along with the 'unable' flag as seen here.  

-- Although I haven't made this modification, it might be worthwhile to extend the "Notes" field to further explain the columns. 

-- I didn't spend a whole lot of time on aesthetics - the right-hand info shouldn't be so bunched together.
Comment 2 John Willinsky 2008-10-03 17:43:34 PDT
Done refers to the Reviewer having done the review. It could include the actual ruling in abbreviated form to handle (accept with revisions vs accept, as AWR vs A). Yet providing dates does provide perhaps as important information about discrepancies between one review being completed some time ago while another is still pending, which suggests action needs to be taken, as opposed to a review just completed and one pending.

Ruling is the editors decision. And here, the only reason it would still be sitting in this queue is "pending revisions" or "re-submit for review" so again, the date would be as important as 

We really need graphic design coloring to group the peer review and the editor ruling sections, but that will come with time (and the appointment of a designer). The name is helpful and once assigned we don't need ask just due date, once they accept, and left blank until they accept, with decline going under Done until the reviewer is replaced. 

So here's what I would recommend, although this will not be lined up properly. It would involve short forms for reviewers recommendations which would need to be added in setup if they are customized...

Peer Review                            Editor JMW
Invite    Due     Done        Advice   Ruling             

Name      12-12   2008-12-12  A        Pending
Name      12-12   2008-12-12  AWR      2008-12-30
Name              Declined
Comment 3 John Willinsky 2008-10-03 17:57:03 PDT
For pending revisions followed by resubmission by the author, the second submission should appear as a date under original. When the editor rules pending revisions, the highlighting disappears until the author resubmits. The instructions to authors for resubmitting (and not starting a new submission with that resubmission, could be strengthened). And the Submit date should go to year-mm-dd, as I have seen them drag out forever. 

ID  Submit
4   2008-10-12
Comment 4 Alec Smecher 2009-02-11 16:11:04 PST
IMO we should defer this until we've had a chance to consider the UI overhaul further.
Comment 5 James MacGregor 2009-11-03 10:11:40 PST
Courtesy of http://pkp.sfu.ca/support/forum/viewtopic.php?f=2&t=5230&p=20163#p20163 and listing here as it seems to be the best place: 

There should also be some sort of visual notification that a revised version has been uploaded by the author.
Comment 6 im 2009-12-04 09:08:07 PST
I have been asked by a number of editors why they are not notified when a revised MS is submitted. It seems an absolute fundamental requirement, especially for Editors handling fewer submissions who may need a prompt to visit OJS! 

So I think an automated e-mail to the Section Editor whenever a revised MS is uploaded, and whenever a reviewer adds comments or otherwise submits a review, is very important.
Comment 7 Alec Smecher 2009-12-04 09:25:13 PST
im@impub.co.uk, could you file a new bug entry with your request?
Comment 8 Alec Smecher 2013-05-29 15:20:40 PDT
Zombie entry; superseded by 3.0 UI/UX work.