EMWCon 2016 – some notes (day 2)

Live-blogging (kind of) again, day 2. Also, livestream.

Notifications in MediaWiki


Yaron discussing the current status of notification (poor), and what would make an ideal notification system for MediaWiki. Page creation, edit, etc in different sets of pages, such as all pages, pages in namespace, etc, and certain people notified, e.g. users in a user group, specified list, users signed up to be notified, maybe external users via email.

Notification done by maybe email, Extension:Echo, or custom webhook of some kind. Echo (you can see on mediawiki.org) is planned to be added into MW Core. Several other extensions rely on Echo.

Many potential pitfalls. Too few options not helpful, too many confusing. Regular users vs. admins vs. “superadmins”.

“Looked at SharePoint for bad notification design, and SharePoint didn’t disappoint.”

Google Summer of Code, Yaron is co-mentoring a project to create a “page notifications extension”, started this past Monday. Goal is to create a framework that covers all the possible options, to make notifications in MediaWiki useful.

Jason mentioned Extension:Notificator, which allows users to set up notifications of others. NASA’s Enterprise Media Wiki team released Extension:WatchAnalytics and others that provide some insight into watching.

Inside Wiki Sales


Angelika Müller from Hallo Welt! talking about selling wiki services, especially Blue Spice, their enterprise wiki distro. Covered the basic lifecycle of sales, from contact to requirements to estimates to doing the work and shipping the final product. Challenges include technical and organizational.

All development, as much as possible, should be customer driven. After all, they are the ones who know what they want.

Discussed some of their big use cases.

  • Wiki farms
  • Document management – they first ask, why not use a document management tool, why a wiki? Things to address – setting rights for files, managing and editing
  • Quality management

In many ways, the same challenges any design / development shop has, but some uniqueness based on the product (MediaWiki based).

A big topic of interest is how they are using WebDAV with MS Office to allow their users to edit / save MS Office documents in-place inside the wiki, instead of having to download – edit – save – upload the file.  This was developed as custom work for a group of customers who came together to fund it, with a restriction that the code for doing it could not be shared for one year (which is almost up).

Anja offered that their WebDAV developer will have a webinar next week to discuss with those who are interested.

Lightning Talks

CWIX Wiki for Interoperability Testing

An overview of the CWIX 2016 wiki.

Making Cool Directories with MediaWiki

Yaron showed some examples of “cool” directory sites. Can you do this with MediaWiki? Functionally, yes. Visually / UI, no.

Question: how can we make our display as cool as theirs? Important for external facing wikis, but can be useful and important internally as well.

Check out migadv. And MITRE’s Gestalt.

Another option is to leverage the MediaWiki API to use MediaWiki as back end and build a custom front end using Javascript, etc.

Social Semantic


Jason Bock sharing some of the things we’ve been working on using SMW for bringing some social features to MediaWiki. Started with a brief overview and history of milWiki (see milSuite article on Wikipedia) and installing SMW.

If you are going to use SMW, you should definitely use Semantic Forms. “Has default form” and “has alternate form” are crucial to make sure people are using forms to enter semantic data.

Create Templates based on Queries, makes it so the user doesn’t need to understand how to create queries, they can just use them. Browse pages are the most popular click from homepage, a fact of life in a hierarchical-minded organization. Query forms, with filters, provides an “Amazon” like search / filter experience.

A 12 step training guide for general users to learn how to use SMW to create their own projects, covers basic overview through the more complex concepts. Crucial if you want your users to be able to create their own solutions.

Three examples of user created semantic projects: IT ticketing system, app store, unit training.


Anatomy of a Cyber Taxonomy Development Wiki


Cindy Cicalese from MITRE (Extensions by MITRE). Demonstrated live at the Malware ATtribute Enumeration and Characterization wiki.

Purpose of the wiki is to help generate an ontology for describing malware. Includes consistant iconography to provide better navigation and visual indicators of what you’re looking at. Built around hiearchies to work (hierarchy builder?). Uses a combination of Cargo and SMW, but the only SMW still in use will ultimately be converted to Cargo. It is an example of how the two can coexist, use each where best suited. (nts: Cargo vs. SMW?)

The “Graph this page” option uses MITRE’s VIKI extension. Very nice, reminds me of The Brain.

Cindy walked through some key aspects of the site, how it’s structured and configured. Went down the rabbit hole of walking through some of the code. (I stood at the top of the hole and watched her walk around, a bit beyond my own current knowledge 🙂

Contracting with the GPL


Greg Rundlett talking about the challenges – and joys? – of doing MediaWiki work for large enterprise clients.

Challenge 1 – Lead time: Make sure lead time and discovery are in your pricing model

Challenge 2 – Payment: Large enterprises have set processes that may not be in your best interest. Negotiate for the best terms you can get (net 14 would be good).

Challenge 3 – Insurance: E&O (errors and omissions) and general liability

Challenge 4-6 – “All Your Base Are Belong to Us”. The challenge is how to convince the client to allow you to publish the custom work as GPL.

The “Master Services Agreement” is a standard contract, typically a take-it-or-leave-it thing. But, you should try to write details into the agreement where details are allowed. This is especially needed for the code, how much can you “keep” for reuse or publishing to open repos.

Collaboration and cooperation, more is needed among consultants in EMW space. We aren’t competing against each other, we are competing against the Microsofts. 

Comment from Mark – we need more consultants like freephile as members of the MediaWiki stakeholders.

A bit of discussion – and disagreement – around GPL and how it applies to custom/proprietary code development.

Lightning Talk

Me – MediaWiki as part of larger Enterprise Social Network

Technical Collaboration – WMF


Chris Koerner providing some insight into the technical collaboration team at WikiMedia Foundation.

The team primarily focuses on supporting the WMF and its official efforts, but they do take input from 3d party users and work on things that provide value to them as well.

Phabricator – bug tracking. Look at in more detail later.

The team hosts several events – developer summit, hackathons, Wikimania, and others. If you are doing good things with MediaWiki, let them know so they can get the word out.

WMF – the ongoing saga

General discussion of topics related to the WikiMedia Foundation. Didn’t catch it all, so no real notes here.

EMWCon 2016 – some notes (day 1)

A live blog (of sorts) for Enterprise MediaWiki Conference (EMWCon) 2016. The conference is also being livestreamed.

Panel – Towards a MediaWiki Foundation


Cindy Cicalese, Anja Ebersbach, Mark Hershberger, Chris Koerner, Yaron Koren

Panel discussion to address some of the challenges around the development, maintenance, and use of MediaWiki and related software (extensions). Not a discussion of separating Wikipedia ops from MediaWiki core (which would be something similar to how WordPress is set up).

Yaron presented a case for a MediaWiki foundation that would help fund “unfunded” software. Specifically, funnel money from the users of the software to the developers of the software. Similar to other open source “foundations”, example given was the Linux Foundation. aka pay to play.

Part of the challenge is that the Wikimedia foundation is focused almost exclusively on Wikipedia and their other projects. Desire is to make sure that the MediaWiki software remains usable by other 3d party users, and actually includes development specifically to meet the needs of those 3d party users. For example, the MediaWiki Stakeholders Feature Wishlist.

An interesting mess.

Social Semantic


Jason Bock talking about applying SMW to achieve social objectives on MediaWiki: standard profiles, rate/review articles, user point system, user badges. Shared some of the specific extensions used.

It is possible to create a template for userpages and have it pushed automatically, need to get user feedback on whether they like this or not. Some people prefer freeform userpage. Balance between user needs / desires and the enterprise’s needs.

All uses existing extensions, doesn’t require any development just “front end” SMW work. Walked through examples the “code” for each. This has potential to cause significant performance issues, will work to have some of this turned into extensions.

Questions about gamification: how do you handle cheating (don’t really), has it helped with adoption (with some people).

Improving Enterprise Findability with SMW

Laurent looking at how SMW can be used to help people find answers to their questions.

“Searching doesn’t give you answers, it gives you search results.”

Use the wiki as a wiki; keep it lean and fast. Use APIs to access other systems. Such as WordPress.

Lightning Talks

MediaWikiFarm extension

Nicolas Nallet talking about the MediaWikiFarm extension. Slides from the talk.

US Federal Government MediaWikis

Peter Meyer talking about MediaWiki installations in U.S. Federal Government. Full notes. Something to follow up on – Federal MediaWiki Demonstration and Discussion Group, a monthly gathering to share ideas, practices, and demo ideas. A call for a more consistent coherent wiki policy across the Federal Government.

“Knowledge management is not a curse word.” — Peter Woudsma


Wiki Farms (again)

Peter Woudsma. Reasons for multiple wikis: ownership, access, control, processing. Defined: MediaWiki server install that includes core and some extensions and supports multiple otherwise independent wikis. Went through an example putting three wikis on one MediaWiki server. Reasons to use common elements: data re-use, template re-use, branding, data processing (inter-wiki data data exchange, queries, transposition)

Question: how much is common to all wikis in the farm? Many possible options.

Discussion among the group about approaches they have taken.


SMW Factory

Lex Sulzer spoke about SMW Factory. Offline, secure, encrypted, backup (and a bunch of other terms). Duplicity, Vagrant, Ansible (executable documentation). Details in the link. An easy way to “clone” a wiki soyou can work on it offline, then push changes back to production. (Meant for dev, not content.)

Ultimate goal – ability to have “offline” wikis that can be updated and merged back in with the main wiki. This would be huge. A project for Friday.

Single enterprise wiki


What’s new in Semantic Forms

Jaron giving an update.

Change 1 – Spreadsheet display. “display = spreadsheet” Each entry becomes a separate instance of  the template on the page. Less work for admins, allows for better HTML, such as <label> (important for accessibility)

Change 2 – Some input types moved from Semantic Forms Input extension to Semantic Forms, continues a process started with other input types. Few extensions, less work for admins and developers.

Semantic Forms is now its own thing, no longer requires Semantic MediaWiki.

Change 3 – removed some params, some of the long-deprecated parameters.

Thinking of changing the name, to reduce confusion with other “semantic” things.

Important takeaway – cleaning up Semantic Forms to make it better, easier for developers and admins.

Also discussed changes to Cargo (an alternative to SMW). Key feature of note (to me) – text search of articles.

Opening Session


Peter Woudsma gave a quick overview of the history of MediaWiki in the enterprise and some of the challenges of taking a tool designed as an easy way to update content and making it useful and valuable at the enterprise level. A nice summary of Enterprise aspects of previous conferences, and the need for balance in discussing the non-technical aspects along with the technical.

He gave us quite a few questions, homework if you will, to consider as the conference progresses. Not just in how we use the tools, but how we influence the future development of the tools, and the support infrastructure.

Good discussion around the philosophy and implementation. Differences between what’s going on with MediaWiki software and WikiMedia. Need to show off who is using MediaWiki, and how they are using it. WikiReport.

Lex – SMW power user is critical to success. SMW is a digital co-worker.


Mix of corporate, government, and non-profit interests represented. People from several places in US and Europe (France, Germany, Switzerland).

WordCampSTL 2016


Although this blog is a WordPress blog, it is not a blog about WordPress. At least not exclusively. It is, however, at times a blog about blogging, and the web in general, which inevitably will include some discussion of WordPress and a wide variety of other tools.

wcstl_badgeToday is one of those days as I spend the weekend at Washington University of St. Louis with a hundred or so others interested in learning more about the WordPress platform and how we can use it for fun and/or profit. (Though to be honest, if you are doing it for profit you are probably having a lot of fun as well.)

WordCampSTL 2016 is my second WordCampSTL event, and my third WordCamp event overall, and I’ve been recently attending the WordPress Meetups in St. Louis, so I know a few of the WordPressers in the area. But I always meet someone new and learn something useful, and try to share what I learn. This isn’t going to be a live blog, but I will be updating it throughout the weekend.

Day 2

Why WordPress Works This Way

WordPress Core committer Aaron Jorbin discusses the philosophy behind WordPress and how this drives the project.

When you work as a lifeguard, everyone starts the season at the same time. Onboarding is easy. Real world, no one starts at the same time. Onboarding is tougher.

WordPress has contributors joining the project every day. To work on 12 year old software. You may never write code, but it is useful to understand why it works the way it does.

Contributing is NOT frictionless. There will be conflict. GRIPI

  • Goals. What is everyone’s goal? What is the project’s goal?
  • Roles. Each person’s role needs to be clear, and understood by everyone
  • Information. Does everyone have the info they need?
  • Process. Flow, and everyone must know it.
  • Interpersonal. It’s not interpersonal. Really, it’s not.

80% of the time it is an issue with conflicting goals. We need a unified project philosophy.

Philosophy Driven Development. Instead of test based, or whatever based, development.

WordPress = Democtratize publishing. Goal is not to be the “best”, but to make sure anyone anywhere can publish what they want. The WordPress philosophy:

* Works out of the box, as little config as possible required
* Famous Five Minute Install: an idea, to be able to set it up without technical expertise
* Emoji.
* Design for the majority. And that majority is not technical, so they don’t force tech things on users. But they are available. A solid array of basic features.
* If a majority of people want to off a feature, it shouldn’t be a feature.
* Menus in the customizer. The majority of users want to see changes before they go live.
* WordPress makes decisions, not options. Options are expensive. Too many preferences mean you can’t find any of them.
* Striving for simplicity
* Link pasting – highlight text and paste a URL onto the text (instead of having to go to the add link in editor)
* Deadlines are not arbitrary. Don’t delay a release for that “one-more-feature”, just push it to the next release. Set targets, and stick to it, even if the full feature set isn’t there.
* The vocal minority (the WP Tavern commenters :-)).
* Our Bill of Rights – the freedom to run the program for any purpose, to redistribute it, to modify WordPress and give away, and to study it.

Don’t just study the code, study the philosophy as well.

Business Panel

Moderator Chris Lema, and the audience, asking questions of people from different parts of the WordPress business spectrum, from freelancer to established design/development shops.

What is the biggest business challenge you face on a day to day basis:
* CF – Knowing what to do that day
* MB – Trying to figure out what you need to fix problems
* JH – Balancing customer requirements on schedule and budget with internal requirements for quality
* SP –

* SP – email to have a record
* JH – uses platform (TeamWork) to track everything. Sometimes you need a real conversation with someone
* MB – Make comms effective and efficient. Standards are important (e.g. onboarding / offboarding)
* CF – actually communicate, even if just “I”ll get back to you”

Biggest estimating mistake
* CF – comes from not understanding the full scope of a project
* MB – unrealistic expectations of time (misjudging dev and scope creep)
* JH – accurate specific scope SOW in writing before the work starts. Customers / clients often don’t read the notes. “I assumed that’s what web sites do.”
* SP – From not having access to customer sites to see scope of updating. Never again.
* Chris Lema – Here’s an example of a mistake: The estimate was just the back end, there was no front end work in the estimate at all.

How do you figure out if you’re ready to hire someone new
* SP – Haven’t brought anyone new, use freelancers, etc. The WP Crowd (http://www.thewpcrowd.com/)
* JH – we only use full time employees. Tend to bring in programmers, then get them up to speed with WordPress.
* MB –
* CF – I can’t say no. I love hiring contractors to help out with things, especially in the WP community.

How do you manage the pipeline
* CF – I suck at managing the pipeline
* MB – weekly meetings to discuss
* JH – “Your current customers are the best source of new business”. Balancing the pipeline, resource management is a challenge. Software – Pipedrive.
* SP – Tell them it will be 3 months before we can start. Referrals.

How do you set your prices?
* SP – line item. good, better, best. Once you have the estimate, push it across the table and be quiet.
* JH – Line item. Hours expected * hourly rate = fixed bid. Everything is custom, but it’s all WordPress, so 80% of an estimate is pretty much standard. The other 20% can be trickier.
* MB – Similar to JH line items for new work. Support is either included in the support aspect of a project or priced separately if it is more than basic support (e.g. requires developer work)
* CF – Flat rate bid, based on estimated hours. But “wild west” projects are fun, when someone calls up and needs something and you just do it and get it done.

Do you sell maintenance with the project( or after the project, or outsource it?
* CF – I let them know I’ll do it, they’ll need to pay for it.
* MB – yes. also try to include education of the clients.
* JH – we offer it, we offer to host it as well. Define in the SOW when the project is finished and maintenance begins. Standard rate and rush rate.
* SP – Yes. “When you get that ‘what is a URL’ client…”. Pipeline.

* SP – Third, third, third. Work starts on payment, first revision, on launch. No admin access and maintenance page until final payment
* JH – 40/40/20. The initial deposit is non-refundandable. They work with well established agencies, so not too much of an issue.
* MB – Support; if payment stops, support stops. Dev maintenance; work starts when paid
* CF – 50% before I start, but I start anyway (usually).

How big is your margin? (Kind of related to how much non-payment you get)
* CF –
* MB – 20-25%
* JH – 25-30%. A bit more on ongoing maintenance support
* SP – never go below 50%.

Hardening WordPress, Again

An update from Gregory Ray of his Hardening WordPress talk from last year. Winter is Coming, are you prepared?

A lot has happened in the last year. A lot of new things to discuss, but it all comes down to the same basics.

98% of WordPress security vulnerabilities came from 3d party themes and plugins.

Why me? It’s usually not personal, a vulnerable system invites attach. If you are not vulnerable, chances are you won’t see a deliberate attack.

Four aspects of security.

Prevent. A tradeoff between security and convenience. Consider the Aerie in Game of Thrones. Security for WordPress is not just about updating WordPress. Primacy of defense goes from the bottom of the stack (DNS) up. Network Admin -> System Admin -> Site Developer.  So many firewalls (network, server, web app, plugin), troubleshooting can be a bit of a slog; but when they work, they keep attacks away from the WordPress level.


Protect. If you can’t prevent attacks from getting to WordPress, many steps to protect. Trusted software only, backups, complex passwords, no admin accounts called “admin”. The usual.

Layered permission. Separate users and server accounts, runtime vs. maintenance mode. The 5 minute install and auto updates require that WP can modify itself, you need to make sure permissions are managed. There will always be exceptions, something new breaks something old, etc.



Day 1

Code Review: Keeping Things Secure, Clean, and Performant

The importance of code review – it’s not “we know better than you”, but more “let’s work together to make sure this is successful.” By Ryan Markel of the WordPress.com VIP team.


WordPress.com VIP, problem in one client’s theme could cause issues for other clients, or the site as a whole.

Copy pasta

Code reviews aren’t to delay things, but to make sure your launch is successful.

The more we review WordPress code, the better we understand how WordPress works. Code reviews were critical in helping the Calypso team learn and use Javascript.

Pull requests are like built in code review opportunities. No one mergers their own pull request.

Stay positive – comment on the code not the person.

Three reasons for code review:
* Better code,
* more people who understand it,
* self improvement.

Code review needs to become a part of your team culture, not something you only do on special occassions (e.g. major release)

Self code review is possible, but you need to make sure you put some space/time between your editor self and your reviewer self.


The future of WordPress: five years out

Some words of wisdom from Chris Lema about the future of WordPress. Hint, it’s not the code, it’s the community. (OK, that’s a bit more than a hint.)


WordPress can only continue to exist if you (WP developers) have a life outside of WordPress. Using WordPress to share your hobbies, to share your life. Don’t think you can’t be a part of it, just realize that you need to spend some time at it. Don’t feel bad you can’t do something immediately, think about what you can do over time.

It is only through this that we can discover what we need WordPress to do. You only find what’s missing when you try to do something you can’t do.

When it’s client work, chances are you’ll be looking for a workaround. If it’s for your hobby, you’re going to figure out how to fix it.

WordPress the code needs WordPress the community.

There is no rule that the better product wins.

Some great stories and flashbacks to technologies and brands that used to be ubiquitous, that people didn’t think were going anywhere. And some discussion of software owned by companies. As opposed to WordPress, the “people’s code”. (nts: that’s a great title for a blog post.)

Learn to say no, so that you have the time and space to have a life, to have a hobby, something you care about. Bring that the WordPress, you have the opportunity grow WordPress.




Insider’s Look into 4.5

Some thoughts and insight from Mike Schroder, release lead for WordPress 4.5.

It all starts with The Matt Chat. And ask your wife, and then your boss.

Choosing your crew
* Deputy
* Design (Mel Choyce)

The release is built by contributors, not the release lead. It doesn’t matter what the release lead wants to do, it’s what the contributors are interested and willing to work on. The challenge, and joy, of a volunteer effort.

* Smart Image Resizing
** Images up to 50% smaller
** Photographers involved, research first!

* Site Logo
** How is this different from a site icon?
** This solves the problem of hacking a logo into a site header
** Ported from JetPack
** Maybe it should be “Theme” logo instead of “Site” logo. What works in JetPack probably wouldn’t work the same in core
** It is now known as “Custom Logo”
** Late addition to the feature set, just a couple of weeks before beta

* PDF Thumbnail
** Core natively supports some resizing of .pdfs already, but has issues
** Ran into challenges
** Updating an established feature seems like an easy win, but sometimes you need to punt it to the next release

* Formatting shortcuts
** As they got into it they realized that they don’t have a full understanding of how bold and italics would be represented. There are different approaches and implementations of markdown, so those two were left for the future
** Only code shortcut made the release

Biggest thing WordPress needs – a better onboarding process for new users, from creating a site to getting it up and running.

Shared some thoughts on how he thinks the release process might – should – evolve in the future. Most notably a move away from a release lead responsible just for a single release to more of a product design team that looks at the evolution of the product across several releases.


Getting to Yes: How to Ask for the Business & Get Paid What You’re Worth

Not specific to WordPress, but some great info and insight into how to make sales a more positive experience for you and your customers. Some stream of consciousness notes, with just a little bit of editing.


The way we’ve chosen to manifest sales in this country is negative, that doesn’t mean that sales is negative.

Spending time talking to the wrong people. Talk talk talk, then they don’t bite. You need to qualify the people you are talking to.

The way to succeed is to not spend too much time with the wrong people. “Addition by subtraction”.

You need to understand what you are selling. What is your value proposition. What are people buying from you?

Your marketing message needs to be about more than your time. It’s not the product you’re selling, it’s what your customer can do with your product that you are selling. e.g. No one wants a drill, they want a hole.

Value proposition.

What is it that people are buying from you.

Interruption based marketing / advertising.

How about a consultative based approach. Based around asking / answering questions. “How can I assist you?” Create a buying environment.

Everyone likes to buy, no one likes to be sold to.

Create an environment where people want to buy from you.

Netflix series reference: “Occupied”

Was his reference / recommendation “sales”? Yes. You recommend stuff all the time, why not take the same approach with business?

Don’t devolve immediately into the pitch, engage in some conversation. Establish a relationship, help them realize what they need. A consultative approach to sales. A process of discovery, not a “here’s the product I want you to buy”.

An holistic approach, not a reductionist approach.

Your job is not to close. Meet people where they’re at, and offer them an opportunity to work with me. (They need you more than you need them.)

Sales relationships
* Vendor
* Supplier
* Consultative
* Trusted advisor (not talking just about phones, but about business)

Cold calling – how can I can get someone to marry me if we’ve never gone on a first date.

Getting paid what you’re worth –

* Make a clear firm offer
** What they’re going to get in a confident manner
*** no wishy washy “let me put together a proposal”
*** listen to what they have said and tell them what you think they need, and give them the bottom line
* Pricing – he doesn’t like the hourly rate.
** We don’t price right because we do it hourly
** We don’t have an idea of what the value is
** This comes across to the client

Check out Allen Weiss, The Millionaire Consultatn

Simplifying your business, more consumable, clear firm offer

Content Modeling

A talk by Teresa Lane from Wash U about the importance, and the value, of modeling your content so you – and your customers – can get the most out of it.

Three main results from modeling your content:
* Content representation
* Relationships between content
* Develop and communicate your site model

Content comes in many forms
* General info
** Big, broad scoped info
** Small, specialized pieces
** People (bio, pictures, etc)
* Forms
* Recipes
* etc

Avoic assumptions with specificity. Consider the wishes you get from a genie; the more specific you are, the more likely you are to be happy with the outcome of your wish.

“When we are conscious of specifics, our content is more effective.”

Four steps:

1. Dismantle the blob
2. PUll the pieces you want
3. Identify the purpose and use for each
4. Put the pieces back together

She went through several examples including a blog post, events, and recipes. You can be very basic, or very detailed. The trick is to be as detailed and discrete in breaking out the fields as you need to be, but not more.

Why do we need models?
* So DESIGNERS know what they need to build
* So DEVELOPERS understand how they need to build it
* So PARTNERS / CLIENTS know how to use the site