EMWCon Spring 2017/Etherpad

Distributed notetaking for EMWCon 2017, day 1 edit

Introductions edit

  • Alex Tanchoco
    • What does an enterprise wiki mean to you?
      • Integration
      • Federated search
    • Why are you at EMWCon?
      • network, learn, share
    • Generally, what is your experience like using wikis?
      • Volunteer IT Chair - Lions Clubs district serving three counties in New York.
      • MSK - PHP developer, wiki administator, modify existing extensions to customize, created Tableau extension.
      • modify extensions, wiki champion at work, walking the talk of transparency and sharing knowledge
    • What are your hopes for the future?
      • Integration with Sharepoint and RDF stores/Graph data
    • Share the one thing you'd love to see during the event
      • Continue networking and collaboration after the event.
    • What is a frustration with wikis you'd like to discuss with other attendees?
      • Maintenance support of various extensions.
    • What is the biggest challenge of an enterprise wiki that does not arise for Wikipedia or other public wikis?
      • People's hesitation for being open and transparent. "Stumbleability" of siloed information. Finding other people in the "mainstream" knowling and learning wiki.
  • James Montalvo:
    • Started a wiki farm at nasa to solve our own knowledge management issues, so I use it to do my day job. Nowadays my day job involves a lot of administration at the server level.
    • Hopes for the future:
      • Like others, I hope to make administration a lot easier for wiki farms with VE, elasticsearch, etc.
      • enterprisemediawiki/meza which aims to do that ( https://github.com/enterprisemediawiki/meza/tree/dev ). Would love to either get people to join our efforts there or if there is someone already building something better I'd love to join forces.
    • What is a frustration with wikis you'd like to discuss with other attendees?
      • Double standards vs SharePoint/etc, people calling us "wiki police" when we try to help, info hoarding
    • Biggest challench compared to Wikipedia: On Wikipedia everyone can view and edit. On enterprise wikis that is generally not the intent. Instead, EMWs need to figure out how who should be able to view/edit, and it's difficult to determine where to draw the line. Personally I think it is best to push towards to as much transparency as possible, which is a never ending battle.
  • Gergő Tisza
    • MediaWIki developer @ WMF, long-time Wikipedia editor
    • frustration 1: the pace of MediaWiki development is slow so Wikipedia is not quite up to the UX/DX standards expected from a top10 web page
      • development speed is limited by size of developer community, which is (mostly) limited by availability of MediaWiki jobs, which is currently mostly limited by Wikimedia Foundation budget, which comes from donations and does not scale well with demand
      • hoping to figure out how enterprise MediaWiki can be supported to the point where it becomes self-supporting / feeds back significant resources into the MediaWiki software ecosystem
    • frustration 2: Wikimedia Foundation is the only one in the position to do overarching architecture changes but does not have an established practice of consulting third-party stakeholders (especially if they are not MediaWiki developers)
  • Matt Nemphos
    • Administrator of Internal and External Policy Manual for MDOT (Maryland state Dept of Transportation)
    • Hopes for the future:
      • Out of wiki: The ability to easily output wiki pages into book format and an easy way to improve mobile responsiveness. I’d also like to find a way to mass move pages into an archive for retention/legal purposes.
      • Out of the group: an enterprise mediawiki forum would be extremely useful.
    • Share the one thing you'd love to see during the event:
      • Building a support network. I am currently the only “go to” person for end user support.
    • What is a frustration with wikis you'd like to discuss with other attendees?
      • A better user rights management system would be extremely helpful in the enterprise environment.
    • What is the biggest challenge of an enterprise wiki that does not arise for Wikipedia or other public wikis?
      • User buy in. Getting our 12K employees to acclimate to using an online wiki policy manual rather than the intranet. Additionally, our technology team isn't very knowledgeable on troubleshooting server side wiki issues.

Anyone written custom extensions (not yet published on MediaWiki) that would like to share? edit

  • Embedded Tableau workbooks within wiki page - Alex Tanchoco

Making our interfaces smarter - Yaron Koren edit

https://www.mediawiki.org/wiki/EMWCon_Spring_2017/Making_our_interfaces_smarter Slides: https://upload.wikimedia.org/wikipedia/mediawiki/f/fd/EMWCon_2017_-_Making_our_interfaces_smarter.pdf http://workingwithmediawiki.com/book/ https://www.mediawiki.org/wiki/Extension:Page_Schemas http://migadv.com/ Simplify extensions

  • FlagRev -> Approved Rev
  • Semantic MediaWiki -> Cargo
  • Page Forms: smart defaults

Interesting challenges encountered at Vistaprint - Daniel Renfro edit


  • Vistaprint: 10 years, 10K employees, several offices worldwide
  • Vistawiki: ~250K pages, 1K active contributors
  • custom extensions:
    • shared drive access
    • one converts from Excel and Word to wikitext
    • embed complex Excel sheets in wiki pages
    • SQL
    • people directory (LDAP based)
    • Archive - soft-deletion (put stuff into a separate namespace, remove from default search)
    • Curation - identify article owners
    • Certification - post-publish review for edits
    • plans to opensource eventually but not a priority
  • challenges
  • persona/per-teaml (content) space (like Confluence)
  • results in poor man's namespacing via title prefixes, which hurts discoverability
  • proper namespaces too inflexible as teams change, no way to archive
  • no enterprise search
    • switched to CirrusSearch recently (modified settings to increase importance of text prior to first heading, to capture the gist of a page)
  • Uses lots of categories and DPL for navigation
  • tried to use templates to make company name changes easy, but ended up with a compley reorg so it wasn't helpful

Federal Government Wiki Introductions edit

Intellipedia - Sean Dennehy edit

https://en.wikipedia.org/wiki/Intellipedia wiki started 2005 (?)

  • killer features:
    • talk pages make discussions about content transparent
    • ability to track past positions or discussions in an environment where the people involved might not be around anymore

Having two wiki advocates in the organization was useful for getting management on board. Used an acronym glossary to hook in new users (easy to add to, no secrecy concerns) Multiple highly-funded attempts for alternative collaboration systems, but Intellipedia survived them

NASA wikis - James Montalvo edit

(was presented in more detail at past SWMCons)

  • Plan, train, fly - work of their part of NASA
  • three wikis, working towards merging them

wiki started 2011 (before, no organized document management) uses Semantic MediaWiki to track e.g. fields of expertise, uses people pages as data and navigation nodes

  • looked at SMW long before installing it (as it was #1 most used extensiobut it was extension page was not convincing and took a while to understand what value it brings

uses VisualEditor, ElasticSearch (CirrusSearch?), interested in making them simpler to install

Statipedia - Peter Meyer edit

  • editathon! https://www.mediawiki.org/wiki/EMWCon_Spring_2017#Wednesday.2C_March_8
  • cross-agency sharing of statistics data, not public but not secret either
  • creation/documentation of shared termonology was a ig reason for creating it
  • documentation for interagency projects (which often do not have a dedicated web page)
  • preserves history (e.g. how definitions change)
  • scientific information (good support in MediaWiki - Math, footnotes, good navigation)
  • internal journalism (e.g. drafting public response)
  • wiki designs and uees - documents vs wiki-text
    • documents are more final, authorship is more clear
    • wikitext are more fragmentary, authorship is lessened

Diplopedia - Tim Hayes/Bob Watts edit

  • eDiplomacy started in 2002 as a task force, became a regular office in 2003
  • Diplopedia over 9,000 registered users, 2k average workday users
  • acronyms a popular use case; someone even wrote an acronym lookup plugin for Outlook
  • Mentioned issues with video uploads. Side note: NASA wikis have had issues with uploading videos to mediawiki due to conflicts with img_auth.php. See https://phabricator.wikimedia.org/T122858.

Powerpedia - Tom O'Neil edit

since 2009 https://energy.gov/cio/articles/powerpedia-turns-two content portals (similar to Wikipedia - Did You Know, anniversaries etc) uses MobileFrontend, maps (Extension:Maps), Portals, Labeled Section Transclusion, Collection, DPL, Multi Boilerplate, Quiz

Federal Government Use of MediaWiki Panel edit

1. In the federal government, we often have lengthy clearance processes to ensure that any information is thoroughly vetted before presented to the entire enterprise. So, how do you deal with content in a wiki where anyone can edit any article? Do you have a moderator who monitors changes to ensure appropriate content is being posted?

  • Statipedia: just watch recent changes
  • NASA: use an extension called Watch Analytics to see how often staff are reviewing content - https://github.com/enterprisemediawiki/WatchAnalytics
  • Intellipedia: Adopt a "Be Bold" approach and get out of the mindset that you need approval before adding content. Cultural change between "people won't come to me if I put it on the wiki" to "more people will come to me because I shared my knowledge on the wiki"
  • Diplopedia: Knowledge managment is shared professional responsibility - make collaboration and sharing part of staff evaluation form - putting it on the wiki is the easiest way to do so.
  • Follow up question: What happens when someone accidently puts content on the wiki that is sensitive?
    • Flagging content that needs to be removed - versions, search cache. There's a mindset difference between emailing 100s of people sensitive information vs thousands who can view (and who are generally unknown) on the wiki. Understaning and chainging that mindset.

2. By taking full advantage of the Discussion page, MediaWiki can be a powerful collaboration tool featuring transparent discussions. How successful has your organization been using a wiki for collaboration via the Discussion page?

  • Diplopedia: discussion pages haven't really caught on
  • Powerpedia: few thousand(?) talk pages which is minor compared to # of article pages
  • NASA: Cite emails in the discussion pages - direct conversations that start in email to the talk page to capture the conversation (extension Talk Right to help manage talk page rights) - https://github.com/enterprisemediawiki/TalkRight
  • Intellipedia: hit or miss; big meta discussion about the wiki itself but otherwise lots of discussion happens in other platforms; no VisualEditor -> UX pains
  • Follow up question: What types of things are you governed by related to information security and how do you make sure your wiki is adherent to those standards?
  • Diplopedia: ToS covers what can and can't be on the wiki. A question that does come up is that, "From a records management point of view how do you manage it?"
  • FISMA standard (more at http://openfisma.org/) for Statipedia - server infrastructure inspection by IT people at EPA (which hosts their wiki)
  • Powerpedia:
  • NASA: Code changes are run through our security professionals - scans and rules are vetted against the wiki. For Content, export control for new audiences to the wiki(s)
  • Intellipedia: AIr gap network for wiki, some content not allowed at all
  • Follow up question: I'd like to ask the panel to discuss how they handle the different levels of data protection (printer info versus export-controlled data versus personal/SBU data) If you go with multiple wikis based on protection level (something we're working toward at NASA), how do you deal with overlap between wikis and how do you prevent unnecessary siloing?
  • Diplopedia: Ask what is your authority to ??? - at the network level, ???. Cleared to SBU, but not PII.
  • Powerpedia: Don't publish anything that could cause a danger. Users are reminded not to post sensitive data every time they are logged in.
  • Intellipedia: Created an extension(?) to add 'annexes' to the article about information with different access restrictions than the main text, to avoid the whole article getting locked down because of a small part which is sensitive. Users can ask the person who added the information (via page history) for access to informaiton if needed.
  • Intelink is on three networks of varying permissions levels - can see lower levels but not higher levels - no connections between articles.

3. Using Open Source software like MediaWiki on internal networks in the federal government normally requires overcoming quite a few political obstacles and hurdles. Have you had any issues because MediaWiki is Open Source? If so, what have you done to solve the problem?

  • Statipedia: lots of early arugments (not limited to MediaWiki) - largely about having a vendor for support. The thing that workee was to redefine the work as a cross-agency project with a dedicated agency hosting it. Once it was cross agency, there was enough buy-in to make it work.
  • Powerpedia - the large adoption of other open source software like Drupal across the federal governemnt made the argument easier. A certain portion of work done by the federal government is now required to be open source
  • Intellipedia: Intellink, because of budget they adopted open-source, and helped to establish that strategy. The media attention around Intellipedia using MediaWiki helped adoption at other government orgs.
  • NASA: No pushback from it being open source, but with getting buy in from management it has certainly helped to say the intelligence community is using it (https://en.wikipedia.org/wiki/Intelink Intelink apparently was an early adopter, and/or proponent of open source)
  • Diplopedia: All federal agencies are to release up to 20% of devleoped software (by paid devleopers) are to be released as open-source
  • Follow up statement: There wasn't bringing any issues open-source sofwtare into the military suite. The two issues we found were: MS SQL support and being surprised it was lacking. The other thing we were happy to find out is that the penetration testing for the application itself did not find issues with MediaWiki and security guidelines were well laid out - is the same true for extensions?
  • Extensions can do whatever they want and are diverse in their application of security best practices. Extensiosn deployed to Wikimedia projects do go thorough security-review so you can assume they have passed some testing [editors note: https://www.mediawiki.org/wiki/Security_for_developers]
  • Follow-up question: how often do you reject extensions because they have problems, and do you report back?
  • Diplopedia: no rejections; Wikimedia Foundation is one of the cleared sources
  • NASA: has not happened; they use extensions written by Wikimedia or themselves or people they know
  • Powerpedia: encountered some questions about permission usage in some extension, but that was all
  • Find Something; Report it https://www.mediawiki.org/wiki/Reporting_security_bugs

4. What’s next for the enterprise wiki? What does the future look like for MediaWiki in your organization? Is there competition from other similar platforms?

  • Powerpedia: Internal silos (Sharepoint, Drupal) exist, they have their reasons, but wants to use wiki to tie them together and point to how to get access/find the information. The wiki is a way to remember/bookmark things that are outside the wiki itself
  • Intellipedia: We have 'tool fatigue' sometimes (Sharepoint, Wordpress, tweet platform). Any time someone is contributing, but not to the wiki, that's less time and energy going into the wiki - VisualEditor is not enabled, but hopefully will be in the future. Hopes that will assist in adoption. Folks are use to things like Google Docs and WYSIWYG editors.
  • Statipedia: SharePoint has been a competitor for a while. If folks have secure infomration, put it in SharePoint, the wiki is not for you. However, do put an entry on the wiki so folks can search and know that it does exist somewhere. As far as the future: make it easier for people to create and format content. More automated tools to keep content current
  • Follow up question:: accessibility
  • Powerpedia: training based on Wikipedia guidelines - alt tags, section heading. Lack of a tool to test pages for accessibility.
  • NASA: software-level accessibility included in professional IT review; other than that they rely on MediaWiki doing the right thing
  • Follow up question:Has anyone ever had an edit-war on your wiki?
  • [General shaking of heads from the panel] No.
  • Follow up question: read access control (currently not well supported by MediaWiki; would it make a difference?)
  • NASA: discussed it a lot, WMF won't add read access levels support to core, would not trust an extension coming from a different source. Actually prefers lack of access controls, makes transparency the default.
  • Diplopedia: would create too much code review burden
  • Intellipedia: everyone has R/W access to all pages, by design.
  • Statipedia: managers sometimes ask for read access control, actual users never do. Management culture can create false expectations.

5. What version of MediaWiki do you use? How important is it to you to use an up-to-date version?

  • Powerpedia: 1.24 , waiting for PHP upgrade. Had problems with read stats removed from core.
  • NASA: using 1.25, updating to 1.27 (or 28?) once review is done
  • Intellipedia: don't know, not newest (can't use VE - so pre-1.25?)
  • Statipedia: 1.25
  • Diplopedia: not sure, 1.23/1.24?
  • Follow up question: why not use Long-Term Support version?
  • NASA: went to 1.25 for VE, now going for next LTS
  • commenter: needed LTS to meet approval criteria for .mil usage
  • Diplopedia: need LTS due to resource limits, updates twice a year would be too much effort
  • Powerpedia: use own gitlab for testing
  • NASA: use Travis + own gitlab for testing

Would be interested in which of the mentioned wikis use Semantic MediaWiki...

Live stream working here (Boston) https://www.youtube.com/watch?v=Qtb7qk9OV78

Distributed notetaking for EMWCon 2017, day 2 edit

Q&A Victoria Coleman - CTO Wikimedia Foundation edit

  • two data centers -TX and MD/VA
  • Tim Starling is the technical lead
  • Wikimedia Cloud Services
  • Self service VMs
  • Automated testing for Wikimediahosted git repository
  • Using Gerrit, Diffusion,etc tools
  • Product vs feature
  • Creating a tiered levels of support
  • Bridge the gap between the stakeholders group and the foundation
  • Create camp could be used to build a statement of needs, this would inform the foundation next weekend as their decide their budget

Enterprise Wikis in Support of Blast Injury Standards Recommendation - Bernadette Clemente edit

MediaWiki as a Software Documentation CMS - Juan Lara edit

  • FrameMaker and RoboHelp used to be industry standards for documentation.
  • But they presented many problems. Delays in getting new information into these formats
  • They tried Ponydocs and are happy with i: https://www.mediawiki.org/wiki/Extension:PonyDocs
  • Imported thousands of config opitons from XML files, or described these opitons ; user can search based on product, component, and operating system
  • Every Page is Page One - http://everypageispageone.com
  • They aspire to rewrite Ponydocs to use Cargo

Content is Architecture - Lex Sulzer edit

  • EMW as a ChatBot to EPPO
  • How to find information, not where to go look to find it.
  • EPPO stands for means “every page is page one” It’s a phrase associated with a community or network or philosophy: http://everypageispageone.com/
  • content style: EPPO. he loves the book about it by Mark Bake. the web site above seems to be a blog by Mark Bakerr
  • Book here: http://xmlpress.net/publications/eppo/ :)
  • it’s designed to enable action; not learning art for art’s sake.
  • Refers to "the EPPO way"

Embracing Scribunto - Tobias Oetterer edit

developed an extension that enables inheritance among Lua classes

Introducing SemanticScribunto Extension edit

  • Created by JamesHK, other contributers include Matthew Thompson from MITRE

Authentication and Authorization in Enterprise Wikis - Cindy Cicalese edit

Upgrading to AuthManager - Gergő Tisza edit

Synchronizing Wikis - Mark Hershberger edit

Enterprise Wiki Analytics - Bernadette Clemente edit

https://elgg.org - open-source social tool MITRE uses

Building confidence in your wiki - Chris Koerner edit

Day 3 lightning talks edit