11–20 of 20 posts
For instance: When I was in school, I wrote a MATLAB program to simulate grid cells in a rat hippocampus. Is that acceptable? I've also written numerous packages for Django - are those? And so on..
This seems like a great idea, but I think it could be vastly helped by some examples about the format should be, what kind of software is acceptable, etc. For instance: When I was in school, I wrote a MATLAB program to simulate grid cells in a rat hippocampus. Is that acceptable? I've also written numerous packages for Django - are those? And so on..
For your particular examples, I would say the rat hippocampus simulation almost certainly fits their guidelines, and the Django packages probably don't, unless they're doing some sort of scientific computation or data visualization.
Since writing the paper is expected to take no more than an hour, given the software is already written, I wonder if they're worried about receiving a flood of submissions. Perhaps it's less of a problem since reviewing a paper should take much less time given their length?
>Authors are strongly encouraged to include an automated test suite covering the core functionality of their software.
> OK: Documented manual steps that can be followed to check the expected functionality of the software (e.g. a sample input file to assert behaviour)
You can see the checklist reviewers go through in any of the issues here:
Since writing the paper is expected to take no more than an hour, given the software is already written, I wonder if they're worried about receiving a flood of submissions. Perhaps it's less of a problem since reviewing a paper should take much less time given their length?
Most scientific software probably doesn't already have all these components in place. It would be a great problem to have, to have a flood of submissions!
If the only point of this is for credits and reputation, than I find it useless as there are a variety of ways for one to get credit. The number of citations means nothing compared to how many users are actually using the software everyday. Also, a paper is inherently different from a piece of open source software - a paper is set to present facts about something observed in nature; software on the other hand is used…
This is designed specifically for researchers in academic institutions that have quite narrowly-defined mechanisms for 'getting credit' that can be formally applied towards career advancement, tenure review, etc., where by definition there are not 'a variety of ways for one to get credit'. Changing those evaluation mechanisms to better support recognizing software development for its "inherent" or naive value would b…
There are a ton of 2nd tier and 3rd tier journals out there that are legitimately peer reviewed but won't help you get tenure / get academic positions, etc. This is a new journal so nobody will have heard of it (and therefore almost all will assume it's a 3rd tier venue). And I don't see that changing for a journal that is so narrowly focused on just publishing papers about open source software.
Earlier quoted context omitted.
This is designed specifically for researchers in academic institutions that have quite narrowly-defined mechanisms for 'getting credit' that can be formally applied towards career advancement, tenure review, etc., where by definition there are not 'a variety of ways for one to get credit'. Changing those evaluation mechanisms to better support recognizing software development for its "inherent" or naive value would b…
The problem with being so openly self-described as a merely a way to get credit is: you're not evaluated on how many publications you get. You're evaluated on how many top publications you get. There are a ton of 2nd tier and 3rd tier journals out there that are legitimately peer reviewed but won't help you get tenure / get academic positions, etc. This is a new journal so nobody will have heard of it (and therefore…
This journal also is also encouraging and rewarding good software development practices, such as documentation, licensing, having the code in version control and testing. These practices are sadly not common in scientific software, partly because there is little academic reward.