[Neuroimaging] Nipy.org new website needs a complete remake

[Matthew Brett]

On Tue, Jul 28, 2015 at 4:59 PM, Ariel Rokem <arokem at gmail.com> wrote:
>
>
> On Tue, Jul 28, 2015 at 8:53 AM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
>>
>> Hi,
>>
>> 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 [1].
>> >>>
>> >>
>> >> Nobody is saying something different about that. This is irrelevant to
>> >> the
>> >> 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
>> >> supports
>> >> 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
>> >> on
>> >> 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
>> > no
>> > 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
>> > your
>> > 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
>> > repo:
>> >
>> > 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
>> > I
>> > would like to see it implemented in an automated manner, and I don't see
>> > how
>> > we do that with Flask (or with Pelican). Since the main difference is
>> > really
>> > the design used, maybe there's some way to use that design on a
>> > Jekyll-based
>> > 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.

The old repo was a sphinx repo - so I would be surprised if a moderate
contributor to any of the nipy projects would have any difficulty
building the pages.  I suspect there was some other reason no-one was
editing those pages.

Ch,Mw