Developer Meetings/20160809

To Discuss

• New wiki/web infrastructure
  • Use ansible to provision the infrastructure
  • It includes full config: apache, ufw, fail2ban, ..
  • cloud provided: Digital Ocean

• Wiki updates associated to release process: http://wiki.slicer.org/wiki/Documentation/Nightly/Developers/ReleaseProcess#Update_Slicer_wiki

Conclusion

Key takeaways and action items from today's discussion (edits/comments appreciated).

Basic functionality on reliable infrastructure is the priority.

Additional features, like Visual Editor will be great, but should not come before basic functionality. See the spreadsheet for extensions to review a list of what we have and/or what's installed in the new infrastructure.

Social media integration for account creation / identity management would be good. It was noted that some work was done 10 years ago on making MailMan compatible with a single sign-on service (user abstraction). However, a user in MailMan is still a separate user as far as I can tell. Even with 3.x, the best you can do is a rudimentary integration (like create a "subscribe" form on-wiki) e.g. https://www.mediawiki.org/wiki/Extension:Mailman (note that this is old code and doesn't incorporate the new secret hash that prevents MailMan subscriber spam).

Search needs improvement. Search needs to be considered from both the internal perspective (how good is the 'on-wiki' search?) and the inbound (aka external) perspective (Does a Google Search for "Slicer Documentation" result in correct/appropriate content?). External search is a priority over internal. So, JC has assigned an issue to follow up on this.

Action Item: Greg to follow up on the robots.txt issue, as well as look at Google Webmaster tools / Sitemap functionality to improve Google Search Engine results. Internal search will be improved via the Elasticsearch extension.

Steve noted that there may be a conflict in the configuration (cookies) which causes him to be logged out of one wiki when he's logged out of another.

How do we provide a good-looking, easy-to-navigate, mobile-friendly/accessible public front-end to the wikis? Would wiki2web be best replaced by a distinct (decoupled) front-end calling the mediawiki API for content in the "public" category (oversimplification) like Greg did with https://freephile.org/wikireport/about.php?

Or, would "Approved Revs" be the best option for handling the approval workflow while an attractive wiki theme such as the 'bootstrap skin' be an all-in-one solution? Greg suggested too that in addition to breadcrumbs (which help navigation), there is at least one extension that offers dynamic "mega menu". The MegaMenu extension can be used to take all the clutter in the sidebar/toolbox/contact us/documentation and organize it like you see on so many websites.

NCIGT is a good candidate to run through the import/upgrade/standardize routine.

Be sure to accommodate the Nightly Developer Docs Scripts