Comments (17)
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.
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.
Related Issues (20)
- Send URL to Library of Congress when first issue is published HOT 2
- Update editorial board page with contact info
- Get all editorial board's approval on the way their name appears on website. HOT 4
- Tweaks to names as appearing on editorial board web page HOT 3
- Link to bylaws from information on website HOT 1
- link to https://github.com/mobleylab/benchmarksets in why_livecoms not working
- Add submission fee HOT 5
- Typo in Zukerman affiliation (superscript 3 but not listed below) HOT 4
- Polishing review form HOT 16
- Where to put reviewer information on the GitHub site. HOT 3
- Apply for Directory of Open Access Journals HOT 1
- Apply for PMC inclusion HOT 1
- Apply for Science Citation Index Expanded HOT 1
- Creating a graphic theme for the journal HOT 1
- Suggestions to pass along to Scholastica for the web site - main page HOT 1
- Suggestions to pass along to Scholastica for the web site - articles
- Updating the first editorial for the first issue. HOT 13
- List of things to ask about customizing the new website HOT 3
- Provide design suggestions for LiveCoMS web site HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from journal_information.