Update Managing the inbox/interacting with authors page

[naushinthomson]

• [x] Add updates to page about managing the inbox/prioritising author correspondence
• [x] Becky approved page
• [x] Melissa approved page
• [x] Fred approved page
• [x] James approved page
• [x] Naushin approved page

Definition of done

• [x] Team reviewed and approved page?
• [x] Add changelog to page

[naushinthomson]

Hi team, just a small update to this page for review! @JGilbert-eLife @bcollins14 @FAtherden-eLife @Melissa37

Added the following:

• Production queries section
• Under Adding notes to emails: If there are particular points to be aware of in relation to an article, it is useful to add and pin this note to help the team see this at a glance.

Propose changing the title of the page to 'Managing production queries' or if someone can think of another idea, happy to go with that!

[Melissa37]

Could we change

including the external typesetters, other eLife teams, and authors

to

including external vendors, other eLife teams, and authors

Includes Ed Office, Glencoe, PMC etc? Also, I don't like using the word typesetter if we can :-)

[Melissa37]

Could we change

Author queries arrive as emails, but we also use Slack for liaising with other eLife teams and our typesetter

to

Author queries arrive as emails, but we receive emails and use Slack for liaising with other eLife teams and some vendors (eg Exeter and Editorial Office)

[Melissa37]

Could we change:

Production assistants and editors are responsible for keeping on top of the inbox and the Slack channels we have with the typesetter.

To

Production staff are responsible for responding to these messages throughout the day, but as soon as possible without breaking the flow of other tasks being performed.

?

[Melissa37]

Coud we change:

Slack queries from our typesetters should be replied to within the same day to prevent holding up articles.

To

Slack queries from our typesetters should be replied to as quickly as possible within the same day to prevent holding up articles.

[Melissa37]

When tags are added, they appear in the inbox attached to the email.

Could we change this to something like:

When tags are added, they appear at the top of the email and also in the quick view

Don't want it tied to the inbox - they appear when not in the inbox too

[Melissa37]

Huddle - for flagging any emails that you want to discuss in the daily huddle meeting

Could this be changed to:

Huddle - for flagging any emails that you want to discuss in the daily huddle meeting. There is an influx of emails overnight and these are addressed/assessed first thing. If you are doing this task and you cannot respond without discussion with the team, use this tag. The daily team huddle is at 10.30am. If emails arrive later in the day you are not sure how to deal with use Slack to discuss with your colleagues rather than tagging for the Huddle the following day

[fred-atherden]

Would it be worth adding that Prod staff should add a note in Hiver saying 'Read' to emails sent to the prod inbox which are just for information, so that we can know if everyone has read them and when they can be closed.

[fred-atherden]

There's info about how quickly we should respond, but I don't see anything about priority - i.e. should responding to an author email be prioritised above other emails (and tasks)?

There is obviously nuance about when to tackle the inbox as opposed to tackling prod content (as we've discussed at length), but it would be good outline how we see each of these emails by importance and, where possible, in relation to other Production responsibilities.

[JGilbert-eLife]

It's probably a good idea to mention that Hiver is a Google Chrome plugin and needs to be installed in the browser before it can be used (Hiver's website is https://hiverhq.com/ if you want to link to that too).

[JGilbert-eLife]

Maybe say "For example, if editorial have CCd us into a request for data or code, these emails can be marked as pending until the author has responded or the article is published."

[JGilbert-eLife]

I'd suggest listing the prefixes in all caps so they can be copied and pasted if necessary.

[JGilbert-eLife]

"(for example, if they ask us to provide a file)" - why wouldn't we just send it via slack?

[JGilbert-eLife]

Crossref warnings don't necessarily need action - in fact, I think usually they don't.

[JGilbert-eLife]

"Similarly, we receive emails when a digest is uploaded to an article by the Features team."?

[JGilbert-eLife]

". . . the digest will need to be re-uploaded to the AWS bucket." - we should probably explain who has responsibility for doing this.

[JGilbert-eLife]

I think we could just change 'No digest, please prioritise' to 'No digest', couldn't we?

[JGilbert-eLife]

"Occasionally our contact at PMC . . ." - shouldn't this lead with the errors in the daily notifications rather than expecting Tori to reach out to us?

[JGilbert-eLife]

"We will also receive a 'PublishFinalPOA Success!' email when the PoAs have been published." - it's not when they are published, it's when they are loaded to Continuum.

[JGilbert-eLife]

Press emails - I tend to leave these open until Sue has confirmed the hold/pub date/hold release, just to make sure that's gone through OK.

[JGilbert-eLife]

PubMed loader report - I don't know if it's worth mentioning these list rejected articles but that notifications about these will be received separately too.

[JGilbert-eLife]

XML notification emails - should we expand this to cover the new third XML notification type too?

[JGilbert-eLife]

Thanks for doing this @naushinthomson !

[bcollins14]

Thanks for updating the page. Can you add to the notes section about pinning and colour coding as we discussed last week? Other than that, I have nothing more to add :octocat: 🐎

[naushinthomson]

In terms of Exeter prefixes, do we use the praise and elife query prefixes? I haven't done so in my time here so far - should these just be deleted?

[naushinthomson]

Crossref warnings don't necessarily need action - in fact, I think usually they don't.

@JGilbert-eLife can you or @FAtherden-eLife think of any instances where they shouldn't be ignored?

[naushinthomson]

". . . the digest will need to be re-uploaded to the AWS bucket." - we should probably explain who has responsibility for doing this.

@JGilbert-eLife Would that be the Features team?

[naushinthomson]

Press emails - I tend to leave these open until Sue has confirmed the hold/pub date/hold release, just to make sure that's gone through OK.

@JGilbert-eLife I've added the workflow I follow for this in a bit more detail, hope that looks ok now!

[naushinthomson]

There's info about how quickly we should respond, but I don't see anything about priority - i.e. should responding to an author email be prioritised above other emails (and tasks)?

There is obviously nuance about when to tackle the inbox as opposed to tackling prod content (as we've discussed at length), but it would be good outline how we see each of these emails by importance and, where possible, in relation to other Production responsibilities.

I've added the following sentence under the Production queries section:

Pre-publication author correspondence emails should be prioritised above other emails and production tasks.

Is this enough to pull out or do we want to list more types of emails and how we should prioritise these?

[naushinthomson]

PubMed loader report - I don't know if it's worth mentioning these list rejected articles but that notifications about these will be received separately too.

@JGilbert-eLife I'm not sure whether this is already covered in the rejected articles screenshot and explanation. Do you mean the usual pubmed loader report also lists rejected articles?

[naushinthomson]

XML notification emails - should we expand this to cover the new third XML notification type too?

@JGilbert-eLife What is the third type again?

[JGilbert-eLife]

XML notification emails - should we expand this to cover the new third XML notification type too?

@JGilbert-eLife What is the third type again?

Don't worry about it - they've been moved to Fred's account so we're not seeing them any more.

[JGilbert-eLife]

". . . the digest will need to be re-uploaded to the AWS bucket." - we should probably explain who has responsibility for doing this.

@JGilbert-eLife Would that be the Features team?

Yes, Features.

Crossref warnings don't necessarily need action - in fact, I think usually they don't.

@JGilbert-eLife can you or @FAtherden-eLife think of any instances where they shouldn't be ignored?

Not really, actually. They are generally around funding DOIs and so on and I think mostly occur on PoA only to get sorted out at VoR. Not sure how we'd track down exceptions, if they exist.

In terms of Exeter prefixes, do we use the praise and elife query prefixes? I haven't done so in my time here so far - should these just be deleted?

I think the eLife query one can be. I don't think we'd ever need to use that one and they don't. Praise is supposed to be, well, for exactly what you'd think. And so I don't know if we should drop that or not!

PubMed loader report - I don't know if it's worth mentioning these list rejected articles but that notifications about these will be received separately too.

@JGilbert-eLife I'm not sure whether this is already covered in the rejected articles screenshot and explanation. Do you mean the usual pubmed loader report also lists rejected articles?

Yes, I do. It has sections for passes and failures. It may be worth mentioning that both are included, for completeness and to avoid confusion if anyone happens to read a loader report and sees failures in it.

[Melissa37]

In terms of Exeter prefixes, do we use the praise and elife query prefixes? I haven't done so in my time here so far - should these just be deleted?

I think the eLife query one can be. I don't think we'd ever need to use that one and they don't. Praise is supposed to be, well, for exactly what you'd think. And so I don't know if we should drop that or not!

I vote for keeping Praise and trying to use it some more - everyone needs a pat on the back and I know Bala's team really appreciates it when we do it!