[Scipy-organizers] twist on github PR approach: treating gh-pages as master

[James Bergstra]

I can appreciate wanting to use the scipy domain.

Regardless of where the result is hosted, I would like to see the
proceedings (in all its forms) built incrementally as PRs are accepted (no
work left until "the end" to fall on some poor volunteer's head).

If that feels to some people like more of a "journal" publication model,
then fine, that's what I mean. If the organizers don't want to go fully to
the rolling deadline model, and prefer to bundle together all the
submissions and reviews to be at the same time of year, that's OK. I still
think that all of the PRs should be published on a rolling incremental
basis even if they all happen to occur in the span of a few weeks leading
up to the annual conference.

And that's another side-effect I'd like to see: publication *PRE*
conference when people are a-buzz about the happenings.

I'm happy to look at some scripts, but only if they are meant to be used in
more of a rolling / incremental organizational strategy. The model in which
some volunteer has to go back, after all the fun of the conference is over,
with no deadline in sight, and take on the daunting task of building and
publishing scores of potentially mal-formed RST documents using custom
in-house software, running scripts that no one has tested since the year
before... that's not a model I want to support.

Also, I would say let's not wait for a decision regarding DOIs or PMIDs
etc. The Theano paper from 2010 has 100+ citations without any such ID
(thanks to those who uploaded the PDF!). Academics will cite a paper if
they want to; they'll just do more-or-less what the project instructs them
to do, or copy how other people do the citation. Academics will not,
however, cite a paper that they can't read because some thankless volunteer
hasn't gotten around to uploading it.

I would love to be promoting SciPy via citations to hyperopt, for example,
but... it's not happening. Those citations are going to either nowhere, or
possibly to ICML instead. I'm missing out on citations, SciPy is missing
out on citations, it's not good.

- James


On Thu, Oct 31, 2013 at 5:24 PM, Andy Ray Terrel <andy.terrel at gmail.com>wrote:

> Well I'm fine with building a script that grabs the github source and
> publishes it on conference.scipy.org.  But we need to create a index
> website and build some providence for things to persist over time.
>
> The only thing I don't like about scipy.github.io/scipy_proceedings is
> that it isn't as stable as conference.scipy.org/proceedings/<year>
> (meaning we can't ever move to a new service with the same url if
> github pages stops).
>
> James, any help in this area would be greatly appreciated. I haven't
> had time to debug the scripts that are there.
>
> -- Andy
>
> On Thu, Oct 31, 2013 at 2:19 PM, James Bergstra
> <james.bergstra at gmail.com> wrote:
> > New to the list: hi people!
> >
> > In follow up to the other thread (Publication and review in SciPy) I
> wanted
> > to suggest a technical twist that would address *part* of the difficulty
> > getting publications out.
> >
> > The github PR system is great, but one trouble with it is that it doesn't
> > go far enough along the path to publication. Namely, merging things to
> > master doesn't actually publish them in the conventional sense of the
> word.
> >
> > However, Github runs Jeckyll-based webpage rendering services so that
> > individuals and organizations can host things at e.g.
> >
> > http://scipy.github.io/scipy_proceedings
> >
> > by pushing to gh-pages branch instead of master or master2013 or
> whatever.
> >
> > PRs should essentially be operating on that branch, rather than master.
> PRs
> > should include a file in the _posts subdirectory, and put supplementary
> > data (like e.g. the paper source and built PDF) in some other folder that
> > the webserver can access. That way, when the chair/admin signs off and
> > merges a PR (a paper) then it's DONE. The website served by github using
> > Jeckyll is immediately and automatically updated with a new post about
> the
> > paper, that post has links to whatever the author wanted: a PDF, a demo,
> > link to slides, source, etc... in short, it is PUBLISHED, and no one has
> to
> > come back and change anything later.
> >
> > Thoughts?
> >
> > - James
> > _______________________________________________
> > Scipy-organizers mailing list
> > Scipy-organizers at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-organizers
>