Getting ready for submissions

[mrshirts]

At least two people have their papers ready for submission, so we need to make sure the process is set up.

I did a beta test of the submission process to get ready for submissions (at https://app.scholasticahq.com/journals/livecoms/manuscripts/new). I will submit an issue later today with specific changes to the text later today, but might get pulled away to tend kids / do yardwork before I finish, so you can provide preliminary comments to the issues.

As far as I can tell (I have a question in with the Scholastica team, but it might not get answered over the weekend), you can't really customize the submission forms themselves; if we want to provide extra guidance, it needs to be on the http://www.livecomsjournal.org/for-authors page, which is linked back from the submission page. We should provide specific guidance for this on the for-authors page. I suggest that instructions about the SUBMISSION FORM should be on the journal web page, where it can be easily references, but detailed instructions about he content of the paper can be on the

Things submissions asks for (all required unless noted)

• Import from arXiv yes/no (we want no for now).
• Title
• Abstract
• Keywords
• Primary Manuscript File
• Supporting files (optional) *Author details (First name, last name, email, Institution, Department ORCID iD - only last and first name are requried)
  • Add additional authors. (There is no way to indicate equal contributions: we should probably do it though required acknowledgements sections).
  • Review information: open form text field for suggested reviewers, and reviewers to avoid, with instructions to list names and institutions. (optional)

Guidance that we should add:

• A request to upload as a supporting file a picture (at least 300 x 200) that will appear on the articles front page (letting them know that it will appear whenever the article is shared). We suggest something evocative of the research, but containing less scientific detail than a table of contents page at, say, and ACS journal. POSTING the article requires a picture, so we might as well ask for it at submission.

• Word limit on the abstract (300 words?) Should it include the address of the github site?

• Guidance for keywords. Not really sure what to tell them. The only keywords we really need is what topic it is, but that should be clear from the presubmission letter. Keywords are required, so we could have them submit the article section (we provide the list for the right phrasing), and five others of their choice?

• Naming convention for supporting files and which files to include I imagine in general there wouldn't be any supporting information text (should probably all be in the main file?), but they might want to provide supporting information input files. Those should probably be in a archive. Right now, the files can only be .aac, .avi, .csv, .doc, .docx, .flac, .gif, .html , .jpeg, .jpg, .key, .m4a, .md, .mov, .mp3, .mp4, .mpeg, .mpg, .odt, .pdf, .png, .pps, .ppt, .tex, .tif, .tiff, .txt, .xls, .xml, .zip. So we can give instructions for making a .zip of input files with a README, etc. I would imagine movies are fine as well. Any other instructions you can think of for supporting information?

• Obviously, primary file would only be .pdf.

[mrshirts]

Addressed in PR #65

[mrshirts]

Leaving open for discussion of issues relating to the first couple of submissions.

[davidlmobley]

Add additional authors. (There is no way to indicate equal contributions: we should probably do it though required acknowledgements sections).

I thought we had an author contribution section. So I don't think it's important to have this on the submission forms.

A request to upload as a supporting file a picture (at least 300 x 200) that will appear on the articles front page (letting them know that it will appear whenever the article is shared). We suggest something evocative of the research, but containing less scientific detail than a table of contents page at, say, and ACS journal. POSTING the article requires a picture, so we might as well ask for it at submission.

Agree, yes.

Word limit on the abstract (300 words?) Should it include the address of the github site?

I would say no; I'd prefer to have abstract length addressed (if needed) in peer review/editorial process, e.g. if the article NEEDS a really long abstract for some reason why not let it have it? I always find the "no more than 250 words" rules to be annoying as then I end up having to count words and play games where I substitute a single long word for two short words, etc., to get to the right word count. I'd rather an easily-readable abstract of 350 words than a dense, highly technical abstract of 300 words. :)

Guidance for keywords

Article section plus a couple key words seems reasonable

Naming convention for supporting files and which files to include I imagine in general there wouldn't be any supporting information text (should probably all be in the main file?), but they might want to provide supporting information input files.

I would strongly encourage them to put all supporting files in the GitHub repo. But if there are restrictions as to what can be uploaded we would need to make sure they can find that out.

[mrshirts]

I thought we had an author contribution section. So I don't think it's important to have this on the submission forms.

A Scholastical-required part of the form is giving the authors. We don't control this.

abstract length . . . I would say no;

To some extent, this is just in case people ASK so we don't have to keep asking. But could say explicitly "No limit, but keep it brief and to the point".

I would strongly encourage them to put all supporting files in the GitHub repo. But if there are restrictions as to what can be uploaded we would need to make sure they can find that out.

Hmm, good point. I guess there's a question if we want to have a permanent version, in case they get deleted or the repository gets deleted in some point in the future. What are the cases in which we might not want to "snapshot" the files?

[davidlmobley]

But could say explicitly "No limit, but keep it brief and to the point".

That would be my vote.

I guess there's a question if we want to have a permanent version, in case they get deleted or the repository gets deleted in some point in the future. What are the cases in which we might not want to "snapshot" the files?

Ah, OK. If that's the intent then we should just tell them to (a) upload a zip of their GitHub, and (b) that most supporting files should simply be deposited in their GitHub, but if they want to request an exception they can upload files of types (a, b, c) additionally.

[dmzuckerman]

I'm ok with all that. Uploading snapshot zip sounds like a good idea.

[mrshirts]

https://github.com/livecomsjournal/livecomsjournal.github.io/pull/143

Following up on this. Do we want a zip of the entire Git repository? Seems like that could be really big and have extraneous stuff? Thoughts?

[mrshirts]

It seems like if there's a '.zip', it should be uploaded on journal acceptance, not on submission. And if there are supporting data, somebody should have to comb through git to get to them.

[dmzuckerman]

We can take a pragmatic approach and set a maximum file size based on what Scholastica is handling for us. Beyond that we could ask authors to pledge to maintain 'raw data' or whatever on github or pursue another archiving solution. I don't think we can get into the archiving business!

[davidlmobley]

Agree re pragmatic approach.

I also like the idea of allowing zip files as large as Scholastica will allow as long as it doesn't cost us extra for hosting. I have things lined up with the library here so they can make backups of our issues for us, so that would presumably include backups of these zip files. This will do a lot to help ensure things are around for the long haul -- GitHub may not be around forever, but the library should be able to maintain a zip file "forever".

I agree we do not want to be in the archiving business, but having them submit a zip file (at least as large as we can easily handle) actually seems to me like it will be a good way to AVOID having to do leg-work to ensure articles stick around.

[davidlmobley]

(And I agree that a zip on acceptance, not submission, is better).

[davidlmobley]

@mrshirts - are there action items we need to take on this or was this just for discussion? Can it be closed?

[davidlmobley]

Also @mrshirts - do we know what format is allowed for the representative image? I'd like to add this to the relevant author instructions.

[mrshirts]

Any standard image file should be OK. I suppose we could add requirements, but I don't know that it's worth it for now (if we discover things don't work so well, we can deal with it).

On Wed, Jun 20, 2018 at 5:19 PM, David L. Mobley notifications@github.com wrote:

Also @mrshirts https://github.com/mrshirts - do we know what format is allowed for the representative image? I'd like to add this to the relevant author instructions.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/livecomsjournal/journal_information/issues/64#issuecomment-398927458, or mute the thread https://github.com/notifications/unsubscribe-auth/AEE31C0hidM0UlFdiyGr4s8PwOXDkfl1ks5t-tiVgaJpZM4UhXbU .

[mrshirts]

A zip of the entire archive could be a problem; if somebody uploaded a random file and then deleted it. It seems like there are a number of failure cases.

[dwsideriusNIST]

Candidate for immediate closure. I thought we resolved the issue with ZIP files by requiring releases.

[dmzuckerman]

Agree we should close.