Getting ready for submissions about journal_information HOT 17 CLOSED

Addressed in PR #65

from journal_information.

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

from journal_information.

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.

from journal_information.

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?

from journal_information.

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.

from journal_information.

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

from journal_information.

livecomsjournal/livecomsjournal.github.io#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?

from journal_information.

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.

from journal_information.

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!

from journal_information.

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.

from journal_information.

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

from journal_information.

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

from journal_information.

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

from journal_information.

from journal_information.

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.

from journal_information.

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

from journal_information.

Agree we should close.

from journal_information.