Move technology to Pelican

[geoffroypeeters]

To make the update of the web site easier: move to pelican (no need to write html, just write mark-down and use pelican/jinja to convert it to static html)

• combine it with github to automatically update the site from github

http://docs.getpelican.com/en/stable/

[stefan-balke]

Hey @geoffroypeeters,

already noticed that ISMIR 2018 is using pelican–good choice.

However, I think GitHub is not supporting Pelican out of the box. You need at least a git post-commit hook: http://docs.getpelican.com/en/3.7.1/tips.html#extra-tips

BUT, GitHub supports Jekyll as its static-site generator (https://help.github.com/articles/using-jekyll-as-a-static-site-generator-with-github-pages/). In the same course, I'd also migrate the site to bootstrap...

I think I can squeeze in building up the page generation but I would need some helping hands in porting the content. It will be super easy because its simple markdown. Who's in?

[ejhumphrey]

been a while since this opened, but I increasingly think migrating to Jekyll is 100% the right decision. The built-in integration is nice, and having built a site in both, found Github Pages / Jekyll more pleasant.

I would go so far as to propose the following, which would have implications for #7, #8, and #9.

• Refactor the ISMIR website as a Jekyll site
• Host the main ISMIR site on GitHub Pages
• Migrate publications / proceedings to Zenodo
• Migrate subdomains to this organization with one repo each, and publish to GitHub Pages
• Once everything works, update CNAMES

Pros

• Merges to master on any repo will redeploy to its site, which is a major sticking point right now (currently this process is done manually)
• All of this work can be staged in separate repositories first without affecting the current website.
• Website subdomains are not currently version controlled, making it especially challenging to fix broken sites.
• Future conference sites could be created directly in this organization, making the archival process trivial.
• This will slash our hosting costs, while providing a more performant website. We could shut down our shared VM hosting, and Zenodo is far better equipped to serve PDFs.

Cons

• An unknown number of publication URLs on the web would be broken for some amount of time until sites / search engines re-indexed.
• It is like one or more of the past ISMIR conference sites will have trouble migrating.
• This is not a small undertaking.

Notes

• It would be possible to provide updated links to DBLP, and moving to GitHub pages might help our SEO / trigger re-indexing anyways.
• It seems many ISMIR publications are mirrored on university or personal websites these days, and shifting to Zenodo might not be so disruptive.
• Worst case scenario, GitHub pages supports submodules, which is one way to pull in the separate conference sites as subdomains.

thoughts?

[ejhumphrey]

Due to other recent changes (mainly #29), I may start experimenting with the migration soon since there's no risk to site, only (at worst) wasted time.

So, to more quickly get out in front of #29, I might actually reprioritize pulling in the conference subdomains as separate repositories, whether or not they can be served cleanly via github pages. This would allow a clean-up effort to be parallelized over the different repos / years, and perhaps help identify any major issues with serving the subdomains this way.

[stefan-balke]

Can you sketch how each of this repos would look like?

And: Would each publication get a record on zenodo? Isn't it enough (but less flexible) to only put the proceedings there? Distributing the data that much makes us rely on the services to be existent in...I dunno...20 years (or until MIR is solved...whichever is first)...do we want that? I mean, webspace with 10 GB is nothing terribly expensive. Drawback: Only Proceedings get DOI, not individual papers...

[ejhumphrey]

re: sketch, I think it'd look like this:

• Use /docs to keep the web content and publish from master, like this
• For now, the website will serve at https://ismir.github.io/ismir2017/

However, if you poke around, you'll notice almost immediately that many of the navigation links are hard-coded to the smcnus domain, which is 😞

As for publications / proceedings:

• I think they all go to Zenodo. Yep, it makes us reliant on them for serving, but being backed by CERN, I'm as confident in their long-term success as say HostGator or GoDaddy.

[stefan-balke]

Ah, okay, so conference websites are also part of the game...

In my opinion, they are the least interesting part of the chain, but, however, for historic reasons and serving as templates they might be helpful.

[ejhumphrey]

conference websites are nice to archive, but the important parts are (in loose order):

• proceedings
• each paper
• tutorials
• presentations (slides and / or video links) & posters, if available
• late-breaking / demos

re: templates, I dream of a world where conference organizers build their ISMIRYYYY website in the ismir organization, and perhaps clone previous years. I'm envious of the continuity (and simplicity) of the NIPS conference year on year (2015, 2016, 2017, ...)