[SciPy-dev] Online SciPy Journal

[Travis Oliphant]

> 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