Updated instructions for DOI.

[mrshirts]

One issue to look at here is the fact that we need a URL to assign a DOI, which means we need to publish the paper, which means we need a pdf. So after the DOI is assigned, the paper will have to be immediately updated. Not sure there is an easy way around this.

[davidlmobley]

Is there a way to create the URL but not have it publicly exposed yet until the DOI is assigned? "Normal" journals will often issue a DOI before the article is actually active.

Otherwise we probably post without the DOI and then quickly update once assigned, as you say. But that sounds like a bit of a nuisance. It should probably be the editor's job as I'm getting a little worried that we're going to end up with the authors having to jump through a long series of oddball hurdles; normally there's just a couple of steps between "congrats, your paper is accepted" and "congrats, your paper is now available". We've already got several new intermediate steps, such as editing it again, adding footer info, sending a graphic and a PDF, doing stuff with the DOI, ...

Maybe this is a topic to discuss with the editorial board, or with Scholastica.

[mrshirts]

Is there a way to create the URL but not have it publicly exposed yet until the DOI is assigned?

Good question. It looks like it can be created and then unpublished, then edited. So we can create it long enough to generate a the URL, and get all of the information. The question is if the article number changes when upublishing then republishing, which I can ask, but I assume not.

We've already got several new intermediate steps, such as editing it again, adding footer info, sending a graphic and a PDF, doing stuff with the DOI, ...

PROBABLY the graphic/lede should be there at the BEGINNING of the process, rather than at the end. Plus then there's a chance for editing.

In theory, the footers stuff could be done by the managing editors via PR. I don't think there's a way to get away from the editing step - that replaced copy editing.

[davidlmobley]

Yes. It's more that I wanted to avoiding adding ADDITIONAL "weird" steps like having to generate a PDF without the DOI, send it in, then immediately generate a new PDF with the DOI and send it in again...

[dmzuckerman]

Also, as with almost everything logistically complicated that we debate, Scholastica probably has a genuine interest in journals that want to use DOIs!! So let's try to lean on them for technical support.

[dwsideriusNIST]

I'm with @dmzuckerman in that Scholastica must have something in their infrastructure to handle this... Every reputable publisher issues DOIs before release - in fact, if you ask the ACS (as one example) after acceptance but before proofs, they'll send you the DOI and so that it can be reference it in the proofs. [We use this with a NIST database, since it uses DOI as the reference ID in our API. Asking the right questions allows us to publish data concurrently with the source article and include a link in the supplementary information section.]

[mrshirts]

I think our current issue (which is our/my fault mostly) is that our DOI includes the LiveCoMS ID, which is generated by scholastica on pushing the "publish" button. If it didn't include the ID, we could do it before. Now, we can immediately push the "unpublish", and then edit the paper, which is nonideal, but workable.

[dmzuckerman]

Should we consider changing what we do? Perhaps a little hassle now will prevent bigger/more hassles down the road.

[mrshirts]

I've played around a little with this before, and it looks like as soon as you save the article (before publishing) it generates the ID. So publishing is not required, just importing the accepted manuscript and uploading stub files.

[mrshirts]

So, it turns out that we can change the DOI after, and initially, it only needs to include a year. It's straightforward, we just need to send another email to the CU account administrator. So I think we're good here. I updated a bit more.

[mrshirts]

Posting three questions here, since they got lost in the commit message:

Three questions:

• Should notification that "we're getting ready for an issue release" be a notification that comes a) from the managing editors to the editors to the authors, or b) from the managing editors to the authors directly? Advantage of a) is that the authors don't have to look back to figure out who the editors are. Advantage of b) is that the editors don't really need to get involved.
• We probably looked at this before, but I'm not finding it - should we a) just fill in the volume/issue when the ASAP version is created or b) leave it as an ASAP document, to mark it as such? Advantage of a) is that it minimizes number of times the author needs to follow instructions. Advantage of b) is that it's clear it's not the final version.
• Should the pdfs created for the final issue a) overwrite the ASAP pdfs in the releases folder, or b) be separate documents (i.e. releases/LiveCoMS_ArticleVX_final.pdf? The 2nd preserves history a bit more (though because of Git, the history is preserved, just a bit harder to get to). Probably both versions should at least have separate tags.

[mrshirts]

One final thing I noted - in the final article submission, there is a place to put a URL or Twitter handle that is linked to a "Learn more about {{AUTHOR-NAME}}" (click on one of the authors on the editoral to see what it looks like) However, there isn't a place to put this in the initial submission, like there is the other things. We need a way to get this, which I guess will just go in to the authors instructions. It would be better if it was in the original article submission, though, and could be directly imported. I'll ask scholastica.

[dwsideriusNIST]

So, it turns out that we can change the DOI after, and initially, it only needs to include a year. It's straightforward, we just need to send another email to the CU account administrator. So I think we're good here. I updated a bit more.

Michael, can you clarify what you mean by "change the DOI after"? I thought the point of a DOI was that it didn't change.

[dwsideriusNIST]

Posting three questions here, since they got lost in the commit message:

Three questions:

• Should notification that "we're getting ready for an issue release" be a notification that comes a) from the managing editors to the editors to the authors, or b) from the managing editors to the authors directly? Advantage of a) is that the authors don't have to look back to figure out who the editors are. Advantage of b) is that the editors don't really need to get involved.

Option a) just seems to increase email volume, so I would suggest b)

• We probably looked at this before, but I'm not finding it - should we a) just fill in the volume/issue when the ASAP version is created or b) leave it as an ASAP document, to mark it as such? Advantage of a) is that it minimizes number of times the author needs to follow instructions. Advantage of b) is that it's clear it's not the final version.

If the volume/issue is known, then let's just include it as early in the publication process as possible. Our volumes/issues are, for all intents and purposes, virtual anyway.

• Should the pdfs created for the final issue a) overwrite the ASAP pdfs in the releases folder, or b) be separate documents (i.e. releases/LiveCoMS_ArticleVX_final.pdf? The 2nd preserves history a bit more (though because of Git, the history is preserved, just a bit harder to get to). Probably both versions should at least have separate tags.

If there is a physically different PDF, then preserve the "ASAP" and final. More history is good...

[dmzuckerman]

I agree with three responses of @dwsideriusNIST

[davidlmobley]

I agree as well.

[mrshirts]

Michael, can you clarify what you mean by "change the DOI after"? I thought the point of a DOI was that it didn't change.

Sorry I meant, we can change the METADATA associated with the DOI after.

[dwsideriusNIST]

Michael, can you clarify what you mean by "change the DOI after"? I thought the point of a DOI was that it didn't change.

Sorry I meant, we can change the METADATA associated with the DOI after.

Thanks! That is what I hoped you meant. Sounds like an acceptable solution provided the workflow is not onerous.

[mrshirts]

OK, I think the current state actually resolves everything in the thread. I will need to change the author instructions so that the ASAP and the first issue version have different names, but not the editor instructions. So if someone can review and/or merge, that would be great.

[mrshirts]

Any objections to merging now, then, @davidlmobley @dmzuckerman

[mrshirts]

Just pinging for response @davidlmobley @dmzuckerman so we can roll these changes out. There were enough that I wanted to check back in before launching.

[mrshirts]

New changes to address @dmzuckerman 's comments about making it clearer who does what.