[Neuroimaging] Nipy.org new website needs a complete remake
arokem at gmail.com
Tue Jul 28 17:59:49 CEST 2015
On Tue, Jul 28, 2015 at 8:53 AM, Matthew Brett <matthew.brett at gmail.com>
> On Tue, Jul 28, 2015 at 4:43 PM, Ariel Rokem <arokem at gmail.com> wrote:
> > On Mon, Jul 27, 2015 at 8:58 PM, Eleftherios Garyfallidis
> > <garyfallidis at gmail.com> wrote:
> >> Hi,
> >> On Mon, Jul 27, 2015 at 5:13 AM, Matthew Brett <matthew.brett at gmail.com
> >> wrote:
> >>> Hi,
> >>> On Mon, Jul 27, 2015 at 6:25 AM, Gael Varoquaux
> >>> <gael.varoquaux at normalesup.org> wrote:
> >>> > Hi,
> >>> >
> >>> > Since it is the time to gives one opinion
> >>> Sorry to be quiet.
> >>> I don't have strong feelings about whether the new or old website is
> >>> better, but Ariel saved us from a lot of frustration by moving us to
> >>> github pages before the recent Sourceforge meltdown .
> >> Nobody is saying something different about that. This is irrelevant to
> >> point of the thread.
> >> I very much appreciate Ariel's push and work on the gh-pages.
> >>> Eleftherios - your main complaint against Jeykll is that it's hard to
> >>> render the pages before you submit a PR?
> >> No, Jeykill is great but Pelican is as as great and in Python and
> >> both md and rst.
> >> So, as this being a Python project I would give it a chance.
> >>> I don't think it's that
> >>> hard - see http://jekyllrb.com . OK, it involves installing something
> >>> in Ruby via gem, but that's not a major burden, and pelican is not
> >>> trivial to set up either.
> >> Pelican is easy to setup at least this is my experience from trying it
> >> my machine.
> >> I haven't played with Jekyll to see if Jekyll is easier in some way.
> > The main advantage of Jekyll relative to all the other solutions is that
> > one has to *ever* build the site on their machine, and that you really
> > didn't need to go through even the minor burden of installing Jekyll on
> > machine. Everything is done on the Github side. You can review the fully
> > rendered site on a contributor's fork, before merging any changes. For
> > example, here is the website on the gh-pages branch of my fork of the
> > http://arokem.github.io/nipy.github.com/
> > Any less automated process poses a barrier to contribution and
> > collaboration, relative to this workflow. I too love the new design, but
> > would like to see it implemented in an automated manner, and I don't see
> > we do that with Flask (or with Pelican). Since the main difference is
> > the design used, maybe there's some way to use that design on a
> > infrastructure?
> I don't think it's absolutely necessary for there to be an automated
> online build. There are also advantages to website builders with
> nice features, so we end up with a better-looking and more
> configurable website. I guess that most of the work here will be done
> by people who aren't afraid to set up sphinx or pelican or flask on
> their own machines. It's easy to do minor edits on the page source
> with the github interface, for rephrasings or typos.
Our best data on the topic comes from the old nipy.org repo (
https://github.com/nipy/nipyco). There are 0 (zero) PRs on this repo, even
though the content was really running out of date. I would argue that at
least part of that is that no one wants to bother building this thing on
their machine. Recall also the difference in the experience of making and
merging PRs before and after Travis.
> Neuroimaging mailing list
> Neuroimaging at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Neuroimaging