For comparison, here are excerpts from the JStatSoft submission instructions.
http://www.jstatsoft.org/instructions.php
"""JSS will publish
1. Manuals, user's guides, and other forms of description of statistical software, together with the actual software in human-readable form (peer-reviewed) 2. Code snippets -- small code projects, any language (section editors Hornik and Koenker, peer-reviewed). 3. Special issues on topics in statistical computing (guest editors, peer-reviewed, by invitation only, suggestions welcome). 4. A yearly special issue documenting progress of major statistical software projects (section editor Rossini, by invitation only, suggestions welcome) . 5. Reviews of Books on statistical computing and software. (section editor Gentleman, by invitation only, suggestions welcome) . 6. Reviews and comparisons of statistical software (section editors Unwin and Hartman, by invitation only, suggestions welcome).
The typical JSS paper will have a section explaining the statistical technique, a section explaining the code, a section with the actual code, and a section with examples. All sections will be made browsable as well as downloadable. The papers and code should be accessible to a broad community of practitioners, teachers, and researchers in the field of statistics. """
However:
"""If code does something standard (for instance compute an incomplete beta in Fortran) it is only acceptable if it is better than the alternatives. On the other hand, if it does an incomplete non-central beta in Xlisp-Stat, then it merely has to show that it works well. """
I think these are good ideas that we can glean from. It is really nice that www.jstatsoft.org is already out there. There is enough interest that we should try to push this forward. I like the idea of volumes tracked by year and issues (or numbers) simply tracked by article. Let's go with that. We need to come up with guidelines for what can be published. There is a lot to discuss here. We don't have to nail it down exactly, but we should have a general idea of what we consider "publishable". Given the existence of other journals that are more "general-purpose," I'd really like to have a journal that focuses on code written for Python. Is that feasible? I don't see why not. I think that Python makes an excellent language to express scientific algorithms in. I think it should be a requirement that the contribution have some relevance to computing with Python. I definitely think there will be different "tiers" of contributions. These should be recognized as such by the existence of two "types of contributions". My preferred approach is to have this divided into two Journals (call them A and B for now) which clarify the difference in novelty. The "A" journal would discuss contributions where a novel algorithm, implementation, or idea is expressed while the "B" contributions are module-style Python implementations of previously-known algorithms. Another candidate for the "A" journal might be documentation and "packaging" of several "B" contributions into something that could be a SciPy sub-package. I could see a typical publication needing two parts code and write-up. Code: 1) working code 2) unit-tests 3) docstring-style docs Write-up 1) Description of how the algorithm fits into the world at a "reasonably" high level. 2) Discussion of how the algorithm was implemented and the design decisions behind the interface, some references to other implementations would also be useful here (whether in Python or not). 3) Technical description. I think there are some "ready-made" publications already sitting in the SciPy SVN tree. Getting the raw code "published" would be the "review" process that Robert is pushing for and could be under-taken by people who are not the original author. I think we should tag code that has been "published" in some way in the SciPy tree so that 1) It is searchable (remember the discussion about adding code-category-tags to SciPy). 2) You can know whether or not an algorithm has had that review. Just to clarify my views, I don't think we need to make it a requirement that the code "go in to SciPy" to be published. In other-words, people shouldn't feel like they have to "give-up" their code. I only want to require that it works with Python. Other modules that are separately installed could still be "published" as long as the code was provided. What should the title be? How about Journal of Scientific Computing with Python for boring??? Anxious to hear your ideas. My time-frame for this is that I'd like to get an issue out by January of next year (remember an issue is just a single publication). -Travis