Instructions for Editors

This page provides instructions to editors handling manuscripts for LiveCoMS.

Ethics Policies for Editors

Ethics policies for editors are listed on the LiveCoMS ethics policy page. We encourage reviewers to acquaint themselves with these policies.

Workflow overview

Authors contact LiveCoMS (specifically, the Section Lead Editor reponsible for the corresponding article type) with a presubmission letter, proposing an article in a particular topic area. The Section Lead Editor assigns this presubmission letter to an Associate Editor, who works with the authors to revise the article plans to be suitable for LivCoMS, and the Section Lead Editor signs off on the final plans. Once the presubmission letter is approved, the author proceeds with article preparation and ultimately submits the article to LiveCoMS. The Lead Editor then checks that the article is consistent with what was proposed in the presubmission letter, and assigns it to an appropriate Associate Editor who manages the review process and makes a final decision on the manuscript, reporting the final decision to the authors. Usually this Associate Editor will be the same one that handled the original presubmission letters.

Pre-submission letters

Assuming the subject matter proposed in the presubmission letter is within the scope of LiveCoMS and is otherwise acceptable, the Section Lead Editor assigns this presubmission letter to an Associate Editor. Reasons for the letter not being acceptable include, for example, ignoring key required elements of the presubmission letter or being too similar to existing LiveCoMS articles. The Section Lead Editor signs off on the final presubmission letter, and the Associate Editor notifies the author that the letter is approved. Instructions for the presubmission letter are found here.

Pre-review processing

Lead Editor

A Managing Editor assigns the paper to the correct section lead editor in OJS, adds the corresponding Section Editor, and adds the Section Editor to the “Comments to the Author” discussion so they can see the suggested authors. They should also check that 1) the GitHub repository is working, that 2) the presubmission letter with approval description of deviations from plan is present. The Section Lead Editor:

  • Assigns an appropriate Associate Editor to manage the review process (unless he or she decides to manage the review process directly). Usually, this will be the Associate Editor who handled the presubmission letter; if not, the Section Lead editor also will communicate the approved presubmission letter. This is done in OJS by going to “assign participant”, changing the left hand tab from “Journal Editor” to “Section Editor”, and pressing “Search”, which will bring up the appropriate section editors.
  • Usually will delegate the final decision to the Associate Editor. If the Section Lead Editor anticipates their input may be necessary, they will notify the Associate Editor at the time of them anuscript submission, or if not, as soon as they become aware additional input may be necessary. They may overrule the Associate Editor after acceptance, but this should only be done in exceptional cases, for example, fraud or plagarism. If there are important scientific changes that need to be made in the article that were not caught by Associate Editors previous to acceptance, these can be handled by an unofficial request for revision before the paper is officially posted.

Associate Editor

Before assigning manuscripts for review, editors have several main tasks:

  • Associate Editors should review the instructions for using the Open Journal Interface interface for review periodically to remind themselves how to work with the interface for inviting reviewers and manage manuscripts. In particular, in order to move the actual manuscript to make it visible in review, the editor should “upload/select files” and make sure the box is checked to “Show files from all accessible workflow stages.” That will allow you to make only the files that are relevant to the reviewer available to them.
  • Confirms that the article is consistent with the presubmission letter.
  • Ensure they do not have a conflict of interest with respect to the work they are to analyze; if they do, dealing with it as dictated by editorial policy.
  • Ensure that if any editors are authors on the paper, they are prevented from seeing the manuscript.
  • Check to ensure that the manuscript has appropriate style, grammar, layout, and figure quality to be ready for editing, as in the instructions for authors. Remember, the journal will not be editing the manuscript, so you need to make a judgment call as to whether the manuscript is well-edited enough to proceed to review, or whether it will need revision for grammar or style before sending it for review to avoid wasting the time of the reviewers.
  • Identify suitable reviewers, who may include experts suggested by the authors, others in the field you already know of, or authors cited frequently in the article. LiveCoMS generally requires at least two standard reviewers in addition to a student reviewer, though exceptional circumstances (such as extensive community feedback via GitHub) may warrant deviations from this policy. The requirement for a student reviewer for every submission is a unique strength of LiveCoMS that enhances the pedagogical value of every accepted paper.
  • The Associate Editor should also notify get the Section Lead Editor if there is any controversy expected (e.g. the reviewers disagree significantly on the merits of the paper, any plagarism potentially evident).

Review handling

Once an editor has handled the pre-review steps described above, the review process is largely similar to typical journals. The editor:

  • Contacts suitable reviewers to request reviews, including a student reviewer, noting our conflict of interest policy. Timing and policy details will be automatically provided to reviewers via the form-letter requests. Reviews will be due in 15 days, though requests for extension will be routinely granted, for an additional 7-10 days. In the event a reviewer misses an extended deadline, the editor should request an additional reviewer. Note that there are specific e-mail templates that will automatically be created; you do not need to write your own. These templates will automatically fill in your name, the manuscript name, the abstract, and the reviewer name.
  • Potential reviewers who are not already registered must be added in the system. You should first search to see if a potential reviewer is in the system (often not likely this time), and if not, add their names. You will need to generate a username for them (this is not ideal); for consistency, use the “suggest” button next this entry and have the database generate the name.
  • Begins the process of conveying reviews to authors once two have been received, unless the need for additional expertise requires a third review. In addition to the two required peer reviews, a student review must also be obtained. A student reivew may be edited to ensure anonymity and proper tone, but not for substance.
  • Handles any potential conflict of interests disclosed by reviewers consistent with editorial policy.
  • Makes reviewers aware of the review criteria, including category-specific review criteria.
  • Performs a check that the GitHub repository contains all of the files in the submission.
  • Ensures reviews are submitted and analyzed in a timely manner (all reviews should be submitted in no more than about 25 days), reaching out to remind reviewers as needed and solicit additional reviews if reviewers are too slow or their analysis conflicts.
  • Potentially helps ensure reviewer feedback is fair.
  • Helps preserve anonymity of the reviewers, especially the student reviewer, by editing the reviews if necessary. Note that the reviewers may choose to waive anonymity by specifically referring to GitHub issues they have filed or otherwise explicitly making it clear they intend to identify themselves.
  • Decides to accept, accept with revision, or reject (keeping in mind the content of the presubmission letter), and communicates this to the Manging Editors. In some cases, the Section editor may have been involved throughout the process, and they should be consulted if that is the case; this is especially the case if someone other than the editor handled the presubmisson letter.
  • If the decision is that the authors must revise, provides appropriate direction about which comments to address, and add any additional comments they wish.

Following acceptance, the editor’s responsibilties are:

  • The editor verifies that the metadata is complete in the submission (including institution, ORCID, abstract), and follow up with the authors for missing information. The metadata should also be consistent with what appears in the PDF.
  • The editor notifies the managing editors (managing@livecomsjournal.org) that the article is accepted, so that the managing editors can obtain a DOI for the article. The correct metadata is needed for the DOI. The managing editors will take the metadata directly from OJS system; it does not need to be passed to them independently.
  • Note: to obtain a DOI (which the managing editors will do upon notification from the editors that the paper is accepted, this is not an associate editor task), email cuscholaradmin@colorado.edu whenever a new article (and/or issue) is up. Library staff at CU at that address will generate and register the DOIs and forward the confirmation emails to managing@livecomsjournal.org. The email should say:

    We are requesting a DOI for an new article in LiveCoMS (below is a specific example).

    • Proposed DOI: 10.33011/livecoms.4.1.5067
    • URL is: https://www.livecomsjournal.org/index.php/livecoms/article/view/v4i1e5067
    • Title: Best Practices for Doing a Cool Thing in Molecular Simulations [Article v1.0]
    • Author 1: John Q. Public, ORCID 0000-0004-4338-2186
    • Author 2: Jane W. Public, ORCID 0000-0002-4339-2187
    • Online Publication Date: 2022
  • In the above email:
    • The article URL is generated by the volume (v4), the issue (i1), and the electronic id number (e5067). This number is the number that the article gains in the system upon submission (i.e. the webpage will look like https://livecomsjournal.org/index.php/livecoms/workflow/index/5067/3. It does mean that our numbering is based on order of receipt, not publication, but it’s much easier to just have a single electronic identifier.
    • The proposed DOI is of the form 10.33011/livecoms.(volume #).(issue #).(article ID #),
    • List all authors (not just the first two).
    • The initial date can just be the year (that field is required for initial request), as it will be updated to be the final date when the issue is published.
  • The managing editors will provide the obtained DOI, issue and volume number to the author so they can include it in the ASAP version.
  • The editor ensures that the author goes through the instructions for article preparation post acceptance.
  • The editor verifies that the articles are properly named and in the releases/ folder as described in the author instructions.
  • The managing editor posts the PDF, and checks with the authors that the posting is correct.
  • The managing editor team publicizes the article.
  • At the publication of the issue, the managing editors send the publication date to cuscholaradmin@colorado.edu with the DOI and the updated date.

Practical tips for managing a paper

When you receive a paper to manage through the editorial process, the key is to stay organized. Most of the steps can be quickly done, and should not be delayed. Proceed as follows:

  • Immediately invite 3-5 reviewers and follow up in a couple days and set a reminder to check in no more than a week later. We need at least three reviewers (one trainee and two others) and typically some reviewers will either decline or miss invitations. If you haven’t received a response in a couple of days, perhaps send a personal e-mail to follow up (sometimes the system’s e-mails go to spam or get filtered out) and/or invite someone else.
  • Reviews are due in 15 days; remind reviewers just prior and just after their due date. Many reviewers will run late and/or assume timing is unimportant unless they are reminded. So remind them, and if they go unresponsive, promptly get another reviewer if you need one.
  • When reviews are in, promptly make a decision. This does not require you serving as an additional reviewer. Usually you can read the reviews, use them to determine whether there is controversy and anything you need to check in the paper itself, and then promptly make a decision.
  • If revisions have been made, use the response letter to decide whether re-review is needed. In many cases, authors respond well to feedback provided and make a good-faith effort to ensure all issues are resolved. If from the response letter (and revisions) you can clearly tell the authors have resolved any issues the reviewers, raised, there is no need to send the paper out for re-review. Or if you need someone who read the paper previously to help you, you could select a single reviewer to assist you. It’s only necessary to send the paper for a full re-review if changes are too extensive for you to evaluate, controversial, or the reviewers recommended a full re-review.
  • Communicate with the authors about updates on the process: Don’t wait for them to reach out to you, which is a sign of frustration. If there are delays, snags, etc., let them know and ensure they know when to follow up with you if they haven’t heard, etc. Authors have a lot more tolerance for bumps in the road when they know about them and are kept informed about your efforts on their behalf.