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.
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
We could add some javascript checking the hostname and making a banner visible
Sounds good.
I updated the git version on the host which works better with credential configuration and cron seems happy with git fetch
What is the font that is used in the 3DSlicer logo? Such in this image https://www.slicer.org/img/3DSlicerLogo-H-Color-218x144.png
@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).
Hi all,
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.
I did a version of what that would look like here: https://bpaniagua.github.io/slicer.org/
Ideas?
Bea
It’s a good start.
What I miss the most is that these distributions are most importantly custom downloads, but they are not mentioned on the download page.
SlicerRT and SlicerIGT will remain just extensions - we don’t plan to create custom install packages. So, I don’t know if we should list them among distributions.
I believe we discussed this over Project Week thinking it is not really about the dissemination mechanism (custom packages vs extensions), but about having a start-to-end software solution that serves a very specific research community. These communities can be either methodological (i.e. salt, dmri) or clinical (i.e. IGT, CIP).
The problem here is that we might be getting a bit tangled on the syntax/branding of what we are trying to provide more presence to. Maybe “SlicerDistributions” refers too much to the dissemination vehicle. I believe it will benefit everybody to present these specialized solutions within Slicer to our user-base 1) because it might attract specialized researchers to the Slicer community 2) because it showcases the real power of Slicer to be customized to a number of different applications.
Yes I agree that we settled on the goal was to provide visibility to “packages” and showcase Slicer’s usefulness as a platform rather than to focus on the dissemination mechanism. Our original idea was that an extension or distribution with sufficient user base, documentation, website, etc. can be featured, and this will benefit all of us.
As I remember we thought Slicer Solutions was a good name, to remove the focus from the dissemination method. What do you think?
I like “Slicer solutions” to refer to group of features and related documentation etc. It make sense to use this term even if there is no specialized installer.
“Distribution” word is good for referring to the specialized installation packages.
It would be important to feature distributions on the Slicer download page and preferably include them in the download stats. Have you talked to @mhalle about this to see if this is feasible?
As I think about this more, I like the “solutions” concept a lot. If user clicks a solution then we could show a page with some nice pictures about typical use cases, instructions about how to set up (either download a special distribution or download Slicer and install extensions), tutorials, sample data sets, etc.
Great! I am glad we all agree on SlicerSolutions as possible branding, since this was the initial plan. I will incorporate this change tomorrow and send the link again for review.
@lassoan @ljod @jcfr @rkikinis @ihnorton @pieper
New version https://bpaniagua.github.io/slicer.org/
What is the process of deciding whether “X” can be called “a SlicerSolution” or not?
People involved in the SlicerVerse project during the Winter Project Week 2017 decided there will be some sort of voting process that will score/evaluate the candidate solution in base to certain criteria. I am just trying to recall discussion points and thinking out loud, but probably we can formulate all this.
Ideas about criteria:
We have not yet decided who will be the people making this decision, but it would make sense to collect any SlicerSolution candidates during the year (maybe they have to send a form that can be provided in the website) and decide if they are provided with visibility in the landing page after a meeting at either of the project weeks (that happen twice a year).
What do you think?
Here is a PR with the changes of @bpaniagua: https://github.com/Slicer/slicer.org/pull/7
If there are no objection, we would like to move forward with the integration later this afternoon.
LGTM for now. We should work on creating “solution” pages, based on the same template, such as a short intro describing the scope, list a couple of use cases with nice pictures, etc. and link to the external website. That would allow users quickly browse through what solutions are available.
@lassoan, wouldnt that be redundant? SlicerSolutions need to have a page to be included within the landing page.
That external website should have all the information necessary.
I believe this is something we should enforce before a solution is provided presence in the landing page.
No, it would not be redundant. It would not be feasible to maintain a uniform design among solution overview pages if they were hosted on different websites (each using different technologies - jekyll, WordPress, Drupal,…). As a prospective user, I would like to browse through these solutions easily, so overview pages should follow the same template and have “go to previous/next solution” link on them.
Update of overview pages should be a very lightweight process: if you save send a PR with some changes of your own solution’s overview page, then it would be merged very quickly, almost automatically.
Yes, the plan is about what you described. Anything that is specific to a software version (such as user and developer manuals) will be hosted on readthedocs. Documentation that is common to all versions (main page, intro, events, use cases, etc) will probably remain hosted on a wiki-like website (most likely stored on github).
