Skip to content
Please note that GitHub no longer supports your web browser.

We recommend upgrading to the latest Google Chrome or Firefox.

Learn more
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show EiC information on pre-review issue #669

Open
wants to merge 1 commit into
base: master
from

Conversation

@arfon
Copy link
Member

arfon commented Jan 18, 2020

This is a small change to pre-review issues. Currently they don't show the identity of the EiC that created the pre-review issue on GitHub. With this change, we're adding an extra field to the metadata at the top of the pre-review issue to make it clear who moved the submission from the incoming dashboard to GitHub:

Screen_Shot_2020-01-18_at_12_27_11_PM

Fixes #527

/ cc @openjournals/joss-eics

@arfon arfon force-pushed the display-eic-information-on-pre-review branch from e9c70dd to 34a9680 Jan 18, 2020
@labarba

This comment has been minimized.

Copy link
Member

labarba commented Jan 18, 2020

This could help us evolve to a new AEiC workflow, where the managing EiC of a paper stays with that paper until publication. Such a change could help us distribute the workload better over time, and prevent burnout weeks for AEiCs.

@danielskatz

This comment has been minimized.

Copy link
Collaborator

danielskatz commented Jan 18, 2020

I feel like the danger here is that it could increase burnout, by making AEiCs continuously responsible for a set of papers, rather than just responsible for starting them and then for those that need action during the week that they are on duty. I'm ok with showing this info, but I don't think it should mean that this AEIC should always be responsible for everything related to that submission

@labarba

This comment has been minimized.

Copy link
Member

labarba commented Jan 18, 2020

Well, after the pre-review was initiated and a handling editor assigned, the AEiC would come back only at the final stage, when the handling editor has received a recommendation from the reviewers and has completed the final checks. It's not a great load of work for one paper.

As it works now, we sometimes have quiet weeks that are a breeze for the AEiC, and sometimes have weeks that completely slam you from day one. (You and I both had a week like that recently.) And if your week happens to fall when you have travel, or some other irregular event, it can get scary when suddenly you need to read and publish half a dozen papers in one day. Unfortunately, once a handling editor pings EICs for final acceptance, everyone expects us to jump in and complete the publication on the same day. I confess to feeling overwhelmed sometimes on my rotation.

@danielskatz

This comment has been minimized.

Copy link
Collaborator

danielskatz commented Jan 18, 2020

I guess this is a just a preference issue - I would much rather know in advance that I will have a week where I have a number of things to do, and then 4 weeks without AEiC duties, than to have some of them during those other 4 weeks. And in the case of travel, for example, I think we can swap weeks when needed. My busy week at the start of the year wasn't busy because of lots of new things that week, but rather because of things that weren't done during the preceding week, but we worked through it all and were back to on schedule by the end of the week

@arfon

This comment has been minimized.

Copy link
Member Author

arfon commented Jan 18, 2020

I agree with you both here - this change has both the potential to allow a different editorial management flow for EiCs but also increase the likelihood of burnout for EiCs if using this feature meant that the EiC who opened the issue was responsible for sticking with the paper through the whole process.

My suggestion is that I modify this pull request for now to simply denote the name of the EiC that opened the issue (rather than @mentioning them and assigning them too). This solves the original request in #527 but doesn't change anything else about our editorial flow. Separately I think we should have a discussion as the EiC about how we might want to evolve our editorial processes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.