Create 'managing production inbox' page

[eLifeProduction]

• [x] Import previous guidance into gitbook
• [x] Update as necessary
• [x] Team approved
• [x] Share with prepress
• [x] Revise based on feedback

[JGilbert-eLife]

Probably worth stating "The email will then be tagged with that user’s name and moved to their inbox."

[JGilbert-eLife]

"‘Pending’ status can be used for emails that you want to come back to later, or to keep an eye on."

Is it worth making it clear that this moves them to a separate section in Hiver that will need to be checked?

[naushinthomson]

https://app.gitbook.com/@elifesciences/s/schematron/toolkit/managing-the-production-inbox

Here's the page for managing the production inbox - please let me know if there's anything else that needs to be covered or if anything is incorrect!

[Melissa37]

The email will then be tagged with that user’s name and moved to their inbox.

Suggest adding some screenshots of what that does or what their inbox is

ie

[Melissa37]

You can view an email’s history, and any notes that have been added to it (as well as adding your own) in the activity bar beneath this:

How do you get to that?

Maybe add this set of screenshots? To view click on the icon in the tool bar at the top: This will open:

[bcollins14]

"..that everyone in the department has access to."

Can we maybe change this to team? Department makes me think grander than our little wholesome posse.

[Melissa37]

Author Correspondence - for any and all emails from authors

Maybe note this does not include an automated email being delivered to the author from Kriya, just if they respond to is

IGNORE - covered later :-)

[bcollins14]

Is it worth noting that even though the email is moved to our inbox, the rest of the team can still search/see this email?

[Melissa37]

Similarly, authors receive another email when their proof is overdue, one at 2 days, and one at 4 days. These can be closed.

Maybe add a statement about why we receive them (ie what's the point in getting them if we just close them!)

[Melissa37]

Every time an article with videos is sent to Continuum, we receive a processing report from Glencoe, our video hosting site. If all videos are listed underneath the ‘succeeded’ heading, this email can be closed. If any are listed under ‘failed’ then action is needed.

Explain what the action is

[bcollins14]

Also, I'm not sure if you have mentioned that when we send an email, we can choose to send it and it will automatically close or be set to pending.

[Melissa37]

This is an automatic email that notifies us when the post-acceptance check has been completed by Editorial Office. This can be closed.

@JGilbert-eLife please remind me why we want this email and we should add why to the gitlab page :-)

[Melissa37]

If the decision letter has loaded, this email can be closed. If the article is not yet in Kriya, this email should be left open until it is, and the decision letter will then need to be re-loaded at that point.

Is there still a delay? ie how long do we wait to see it's loaded before we contact Exeter and what's the procedure for contacting Exeter?

[fred-atherden]

I think we need to include what to do when we receive an email for Decision letter loading failures.

[Melissa37]

Digest

What do we do if it's not loaded and how long do we wait before our next action if it's not loaded?

[fred-atherden]

Same (as above) for digest loading emails.

[bcollins14]

Under Striking images, I think it is worth noting that authors can also word these as promotional images, graphical abstracts etc

[Melissa37]

Our Features team regularly send us a list of the latest articles that are not getting digests. They will have already marked them as ‘no-digest’ articles in Kriya, however we need to check all of them to ensure that the labels have stuck.

Is it worth expanding on "stuck"? Are there common instances of why it might not stick?

[fred-atherden]

The No-digest email process is longer than has been added here (adding no digest to the editorial sheet as well). Unsure if this needs expanding on this page though (so I understand that's why you might not have included it!)...

[bcollins14]

Under Press emails, it may be good to also remind the reader that press tags should also be added to these.

[fred-atherden]

Emily will also cc us in if she asks Sue at Editorial Office to put any recently accepted papers on hold, whilst she looks into potential press for them. There is no action needed for these emails, except to read them and check that there aren’t any issues.

What about when she asks Sue to schedule PoA publication, and we need to add it to the prod team actions sheet, and check where the VoR currently is in the Production pipeline.

[Melissa37]

Add to Glossary: PoA (I like PoA and not POA :-)) Digest bot PMC PubMed Crossref

[Melissa37]

Will the links to Googledocs be swapped out for Gitbook pages?

[fred-atherden]

Our tags:

Please also include new versions, and when to use it (PoA and VoR).

[fred-atherden]

Is it worth including details about how emails from GitLab/GitHub issues should be dealt with?

[fred-atherden]

We regularly receive Crossref maintenance emails. Is it worth covering these too?

[fred-atherden]

Is it worth covering the scenario in which we receive an automated OOO type response from a corresponding author from a proofing email? Or is that too niche for this page?

[fred-atherden]

We also receive 'PublishFinalPOA Success!' emails. Should this be alluded to somewhere?

[JGilbert-eLife]

"Author Correspondence: This is for author emails we forward on to Exeter which contain changes that they should make during the Post-author validation stage."

This does NOT correspond to a tag - we should not be tagging the emails that we forward to Exeter with the Author Correspondence label as that is intended to record messages coming from the author.

Not sure it's correct to say that there's any equivalence with any of them, actually - the subject line prefixes as specifically to help Exeter sort their emails whereas the Hiver labels are for us to sort and track emails on our side. It's probably better to treat them as separate things.

[JGilbert-eLife]

Think I mentioned this elsewhere but it would be great if the Email types could be alphabetically ordered.

[JGilbert-eLife]

"If the proof is still not submitted, we will receive an email asking us to chase the authors manually."

I think we should mention that chasing should be escalated to copy in other corresponding author/first author(s).

[JGilbert-eLife]

"Manuscript processing"

Video processing?

[JGilbert-eLife]

"XML notification emails"

Please could you include screenshots of both PoA and VoR versions?

[JGilbert-eLife]

"Check the decision letter has loaded on the Kriya dashboard."

Including a no-digest tagged example as the after shot could be confusing?

[JGilbert-eLife]

"No-digest emails"

This needs to cover updating https://docs.google.com/spreadsheets/d/1oy8TIwsedSYdy6n3_SFuqUcJ4Ljeg7tXnTS6q2CsNI8/edit?ts=57fe457c#gid=0

[JGilbert-eLife]

"PMC failures"

I think it would be better to cover the daily summaries e.g. "DTS: Daily Summary for eLife Sciences Publications, Ltd - Jun 23, 2020", so that we proactively trace errors without waiting for PubMed to chase us. Also, please remove reference to Tori in particular - our contact at PMC has changed before and could again.

[naushinthomson]

• [x] Review 'New versions' tag description
• [x] What do we do if digests aren't loaded and how long do we wait before our next action if it's not loaded? Why might a 'no digest' not stick?
• [x] How long does it take for a decision letter to be loaded? - (within 1 week of acceptance)
• [x] Should we add responses to OOO emails (yes), Crossref maintenance emails (close maintenance ones, keep ones about the server being down open), GitLab/GitHub issues (raise at the huddle)
• [x] Review chasing protocol (copy in all corresponding authors in the first manual chaser and then start adding first authors)
• [x] Review no-digest section
• [x] Review Pubmed loader section (split out PMC and PubMed sections)
• [x] Review XML section

[naushinthomson]

@FAtherden-eLife Just assigning you to add the info about PMC failures! :)

[fred-atherden]

I've added the PMC failure content - please review.