Scope and deliverables

[ctb]

In order to approach wider groups, I think we need a statement of scope & a rough idea of deliverables. If I were to one together it would say:

• develop proposed simple/common denominator standard around specification of dependencies, execution of code, inputs and outputs, etc. so that services like mybinder/everware/thebe/etc know how to run papers.
• implement alpha-level demo/vertical spike through idea, implement some use cases
• expand mybinder/everware to deal with R stuff
• provide & implement integration points with travisCI/github/pull requests
• integrate with zenodo to provide DOIs
• convene discussions with publishers and other potential stakeholders
• think hard and prototype ideas around composition of workflows

(& I think this is all do-able within the size of the prize.)

thoughts?

[betatim]

I would add:

• tools to go from blank directory -> directory with basic
  structure/sensible defaults everywhere
• tool to run things locally as if it was published

The lack of this is init tool one of the biggest hurdles people have to
overcome when I ask them if they have considered everware'ing their stuff.
The local running part is important because it allows people to keep using
their editors and tools and they don't have to share their code publicly on
github from day one.

On Tue, Feb 23, 2016 at 6:25 PM C. Titus Brown notifications@github.com
wrote:

In order to approach wider groups, I think we need a statement of scope &
a rough idea of deliverables. If I were to one together it would say:

• develop proposed simple/common denominator standard around
  specification of dependencies, execution of code, inputs and outputs, etc.
  so that services like mybinder/everware/thebe/etc know how to run papers.
• implement alpha-level demo/vertical spike through idea, implement
  some use cases
• expand mybinder/everware to deal with R stuff
• provide & implement integration points with travisCI/github/pull
  requests
• integrate with zenodo to provide DOIs
• convene discussions with publishers and other potential stakeholders
• think hard and prototype ideas around composition of workflows

(& I think this is all do-able within the size of the prize.)

thoughts?

—
Reply to this email directly or view it on GitHub
https://github.com/betatim/openscienceprize/issues/24.

[ctb]

👍 I will try to write it up tomorrow morning Central time US, if you don't beat me to it.

[betatim]

I have to sleep sometimes ;) Looking forward to the PR

On Tue, Feb 23, 2016 at 8:59 PM C. Titus Brown notifications@github.com
wrote:

👍

I will try to write it up tomorrow morning Central time US, if you don't
beat me to it.

—
Reply to this email directly or view it on GitHub
https://github.com/betatim/openscienceprize/issues/24#issuecomment-187877696
.

[odewahn]

There's one other aspect I'd consider adding -- creating a system for visualizing diffs.

For the notebook, in particular, this is a difficult problem since JSON is a hard thing to diff. There have been various efforts at it, like http://nbdiff.org/, but my favorite solution is https://github.com/rossant/ipymd, which allows you to store the notebook directly as markdown. This enables you use plain old diffing tools, like the one's built into github.

I'm not sure how important this would be directly to scientists, but it's an incredibly important priority to publishers.

[ctb]

+1

[betatim]

👍 you often see .ipynb as a format being compared to binary blobs like .doc This is why I keep typing paper.{md,ipynb} because personally I think I would always store the md version when collaborating with others as the diffs for json are so horrible.

I wonder how we should put this in the scope without getting to technical. everware and binder both use the jupyter frontend so they take ipynb as input. Where as if we build our own frontend (a la thebe) we can determine the input format and support markdown, Rmarkdown, ipynb all at the same time. As well as rendering things in the way we want them to look. The notebook interface is nice, but we could have something much much cleaner (hinthint #23).

[ctb]

+1 to that too :) I really like the idea of driving a vertical spike through the proposed system, and then having a more grounded set of discussions around the places where we disagree. I think that's a pretty good OSP submission, frankly.

[khinsen]

+1 from me as well. For my point of view on notebooks in the context of diffing and merging, see my enhancement proposal for Jupyter (which I don't have the means to implement).

[cranmer]

There was once the idea from @lnielsen to write a GitHub LSF backend for zenodo.