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:
@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.
(Jean Christophe Fillion Robin (Kitware))
@mhalle Thanks for the investigating. It all makes sense.
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.
I’d have to change the sync if we change the branch name, so it’s important to coordinate.
Since gh-pages is configured in GitHub to automatically be hosted at slicer.github.io. I’d use that branch name as a ‘preview’, but the caveat is how do we avoid accidental visits that would fake out a user?
For hosting the true site, we don’t really need a new branch. we could just merge the current gh-pages into master and then pull from master.
(Jean Christophe Fillion Robin (Kitware))
The branch used for github pages can now be configured
merge the current gh-pages into master and then pull from master
Since I anticipate we will add some scripts and tooling to potentially help build the static content, I still think it makes sense to server the site from a dedicated branch (e.g slicer-org)
In the mean time, I created a new branch named slicer-org based of the existing gh-pages …
how do we avoid accidental visits that would fake out a user
@bpaniagua I was just wondering the same thing for another logo and found your question Copy-pasting the text from Mac Preview of a pdf version of the logo into TextEdit, the font appears to be Verdana (changing it back and forth gives the same look so I think that’s correct).
Now that are using the github.com/Slicer/Slicer.org repo as the main Slicer landing page, I wanted to bring back to the conversation the fact we wanted to give some presence to the SlicerDistributions to the landing page.