[Scipy-organizers] Publication and review in SciPy

[Jacob Barhak]

Hi Sheila,

Since you are the major contributor to this thread and have contacts to volunteers, I will assume that you are leading this effort and I will try to form a core consensus with you. 

I also suggest that to speed this planning process and also communicate by phone/video conference. I would first like to ask who will be interested to be a party in such a remote conference? Interested people, please respond to this thread. I suggest we see who responds in a week or so and try to figure out best communication method and time. 

Perhaps we can start a wiki somewhere to help facilitate this better since this mailing list is limited in size of post and may not be the best tool for design. 

Here are a few issues you raised and some responses:

You mention the need to write code regardless if platform - I suggest minimizing the code. Many things are already in place, let us not reinvent the wheel here and only invest time in critical issues. 

I agree volunteer time is pervious, let us simplify things as much as possible and get a simple design out quickly so we can test it and allow other activities to happen. 


I agree that we need to work with a  simple format. Let me suggest RST as the format of choice. I have little experience with it - I only had to write one paper with it for SciPy in 2012, yet it was easy and quite painless to learn and use and it allows incorporating figures and other elements that may be useful that github displays as HTML once uploaded. I suggest disregarding the latex or any conversion to PDF that was used in 2012 to make things simpler - this was hard on coding and some things did not work intuitively there. And in any case, further processing of RST can be done after the conference.

I also suggest that the name of the repository would be SciPy 2014 since the methods may change and improve from year to year, yet if each SciPy has the year appended it can still be found easily. I would even suggest porting back the papers from previous years using this format to make the papers from previous years more visible. I had problems finding my own paper using the correct year branch. Not all people who may read the proceedings will figure out the branch easily - yet a search for SciPy or Scpy 2014 may be able to help find the proceedings from within the github search. 

I agree that github is a good venue for publication since:

1. The submission of the manuscript is public through a request and a version of the submission is kept by the user and the published Version kept separately while those are connected through the communications. Everything is public and the user has the ability to withdraw his version of not accepted while once accepted SciPy gains control of their own copy. 

2. The review can be stored with the paper and again, the review is public. Never the less the review process will have to be defined with simple instructions and perhaps a video to name things easy for reviewers and some programming may be needed here to aid communications with editors/reviewers/authors and volunteers may be needs for testing the idea.

3. GitHub can handle multiple versions in case of corrections before and after publication. 

4. Github is natural for python programmers

5. Github can store different media types if needed. And I agree VMs are not yet an issue. However users can be encouraged to store as much as possible and link to other locations that can store more. 

I hope these ideas make sense to all. 

          Jacob


Sent from my iPhone

On Nov 1, 2013, at 8:48 AM, sheila miguez <sheila at codersquid.com> wrote:

> On Fri, Nov 1, 2013 at 1:35 AM, Jacob Barhak <jacob.barhak at gmail.com> wrote:
>> Also unless we store virtual machines with code, there is no need to worry about disk space for publication. And it may be even possible to store differences of virtual machine snapshots within limited space. Never the less, there are other issues to solve before discussing publishing VMs.
> 
> 
> I'd like to be able to store as much as possible so that people have
> enough to replicate the research. For code and some data, one approach
> would be to merely organize the structure of the repo to include
> those. But I know for some papers, the data used for the work is going
> to be huge (larger than some VMs).
> 
> We don't need to resolve this immediately for this email thread.
> 
> 
> 
> -- 
> sheila at codersquid.com