Thoughts on software papers post

[sckott]

Thoughts on your draft post here

Nice work. It's great to talk about these things to get people familiar with good practice. A few other things

• Case: camelcase vs. all lowercase, etc. I totally agree with Hadley that you should avoid camelcase as it's nearly impossible to remember all function names - having to remember case as well is annoying (though Google R style guide recommends camelcase instead of function_name as Hadley likes). What's your position on this?
• Testing: Perhaps mention that using a package like testthat could make testing relatively easy. Going beyond "tests" in the examples of function docs is not that hard with testthat. Perhaps mention some of the convenience functions in devtools to run all examples, all tests, etc.
• Documentation: Recommend definitely using roxygen2 - it seems rather silly not to. Makes it easier for maintainer to do good documentation and others to contribute code and docs.
• In the paper: Need strong motivation for why people should care about the software
• A series of use cases for the software in the paper is nice as it gives a people a variety of things you can do with it.

[cboettig]

Thanks! Made a few edits and posted now. difficult to decide what is "best practice" (e.g. minor revisions) vs "absolute necessity" (e.g. reject and resubmit). So as not to steal your ideas, I didn't put these in directly, but it would be great if you brought these up in the comments... http://carlboettiger.info/2013/06/13/what-I-look-for-in-software-papers.html

[sckott]

okay, will do