I would like to bring up again the topic of transitioning the Slicer.org landing page to a place that facilitates collaboration.
As you know, @rkikinis appointed me to start looking into showcasing the different slicer-communities in the Slicer landing page. We created a mockup in January during project week that planned to show different slicer user communities directly in the landing page.
Are there any supporters for conserving the current structure, or to move towards github pages? Are there any general ideas on how to move forward with this?
Thanks for commenting on the new Slicer Discourse forum
Overview
The current website already successfully presents Slicer and its outstanding community. It served us well and is still serving us and our users.
That said, considering what is possible today, the current infrastructure doesn’t allow to easily experiment and improve the website. I think it is important to enable everyone to do so. In the long run, it will make the Slicer platform and associated projects more useful.
Current infrastructure
It consists of html pages (and few wiki2web pages) stored on a server that have to be updated by a single person (without relying on version control).
While the individual(s) helping in the process are awesome and responsive, the process is quite daunting and involves often a lot of emails.
Next
@bpaniagua will help us move forward and improve the user experience related to the main Slicer website.
If we all agree to move forward with this experiment and adopt GitHub to host and serve our website, I wonder if Mike and/or Greg could setup the redirection ? (cc: @pieper ?)
Actually, this is going to be tricky, possibly too tricky to have github.io hosting be viable.
slicer.org (which forwards to www.slicer.org as per best practices) is now hosted on Digital Ocean. www.slicer.org/wiki points to the wiki, also hosted on digital ocean. There are a bunch of rules on the slicer.org web server that keep old links working while allowing current, consistent, cleaned up wiki URIs. Backward compatibility was one of our goals in the re-architecture of the wiki.
If we moved slicer.org to github, we don’t have a place to put those Apache configurations, since slicer.org is top-level. Right now I don’t see how it can be done.
An alternative would be to author the site on github, and pull it over to the main site where our existing slicer.org HTTP server would serve it. That would also take care of the SSL configuration, which is working and continuously maintained using letsencrypt.
Yet another alternative is to declare everything-wiki “legacy”, and move on with hosting documentation using ReadTheDocs or GitBook, as some of the folks discussed earlier.
Do we have any idea of who is using Slicer wiki, how it is used (editors/readers ratio), what pages are being accessed, etc? My guess is that it could be the case that most of the wiki content is not used either because it is obsolete, not searchable, or for various other reasons.
@fedorov in fact, we do now have some good data on that via google analytics, at least on page views and it’s in the thousands per day (see below). I would not want to move to either gitbooks or readthedocs because either one would be a disruptive change that doesn’t offer enough advantages at the moment.
I like the idea of hosting the repository for slicer.org static pages on github and then using the existing digital ocean infrastructure that already handles the wiki to host that content under https.
@mhalle it sounds like we could set up something like:
where “=>” means a githook publishes every commit over to the digital ocean host and “example” can be any community that wants to participate, is that right?
@pieper it is great that we have analytics set up! It should be very helpful to prioritize migration, if there is ever agreement to do it.
I disagree though about “a disruptive change that doesn’t offer enough advantages”. I think it is an opportunity to bring some order to the various resources that piled up over the last decade, and improve the appeal of these resources. By making documentation more accessible for both users and developers, we have a chance to attract more people and grow the community, and there are few things that are more valuable than that. I think there is also relatively low risk if wiki is maintained in read-only legacy mode, as the content is migrated/populated.
But I also think that, as we have experienced already, reaching consensus on what will be the new platform is challenging.
During the weekly developer hangout, @bpaniagua and I talk about this, and we suggest to setup a cron job on the server that is currently serving “slicer.org” ?
A cron job like this one (running every minutes) should do the work:
SITE_DIR=/path/to/slicer.org
if [[ ! -d $SITE_DIR ]]; then
git clone https://github.com/Slicer/slicer.org $SITE_DIR
fi
cd $SITE_DIR
git fetch origin
git reset --hard origin/gh-pages
I just talked with @mhalle about this and it sounds like the digital ocean instance is now set up and would be ready to start autopulling from github.com/Slicer/Slicer.org. As I understand it @freephile has a git repository of what is currently hosted on https://slicer.org which I think is similar (identical?) to what is currently on github.
So I think we are ready for the plan to make the github.com/Slicer/Slicer.org repository become the official one and use github issues and pull requests to maintain it.
There is a bunch more file content in the live slicer.org site. Some of which just needs to be purged (e.g. DownloadSlicer.php). Some may be desired, but ignored in the repo (e.g. doc), in which case we’ll just use the .gitignore file to avoid collision. And some would be candidates for addition to the repo (e.g. robots.txt).
Thanks Greg. I’m not sure what all is in the existing slicer.org folder,
but based on the toplevel page it looks like most links to go the wiki or
to the download site, so perhaps we just start fresh with just index.html
and its assets. On the other hand it doesn’t look huge, so we could commit
it all and then clean up.
Either way I understand that github.com/Slicer/Slicer.org is a placeholder
that can be overwritten by the content of the currently non-public slicer.org git.
@jcfr I made a pull request to update index.html Do you want to make me an editor on the repo, so I can push, or if you want I can continue to issue pull requests.
With that merged, I can pull the github repo and setup cron on https://slicer.org
I’ll simply archive the existing content listed above (it’s all legacy by the looks of it), and add in the .gitignore, favicon and robots.txt files to the github repo.
Now that we have the sync setup, what do you think of:
we rename gh-page branch to slicer-org
create a branch preview-slicer-org that would allow to try changes on “preview.slicer.org” (or we could have the preview rendered by Github configured at as github page)
