I’m a light Wikipedia (and related projects) editor, but help to maintain and support two
decent sized (hundreds of contributors, thousands of pages) internal wikis in the
healthcare industry. Our organization has been using (Semantic) MediaWiki for over 6
years. I’ve been maintaining it for over 3.
The first item we'd like to discuss with MediaWiki users is what should
we actually focus on?
Out of the box experience - As I was putting together this list I thought about how many
of the things I do when I setup the wikis. The default installation does include some
handy tools, but almost everyone I’ve spoken to has their own brew of extensions they
setup by default (I have upwards of 50).
I would love to see improved first-run experience and documentation (on
mw.org<http://mw.org>) on what is included by default, what the extensions do, where
do I go to get more, etc.
Editing - I think VisualEditor is the future of wiki editing. Wikitext is powerful and at
the moment savvy editors can do more than VisualEditor, but that gap is closing. I’ll meet
with many internal teams wanting to move away from email archives and Word docs for their
documentation needs. I go over the philosophy of MediaWiki, explain it’s features
(watchlists are magical!) and then I get to editing. Eww. People think it’s gross and
backwards. People expect easy-to-use WYSIWYG editing - and they should have it. I’ve spent
more time explaining and fixing wikitext errors than I’d care to admit.
Just in the past few months the VisualEditor team has improved support for things my
co-workers care about - IE support and tables. I think Mediawiki should increase the push
for use of VisualEditor in third-party wikis. I’ve been running it for a year now with
great success.
More consistency in WMF extensions - There’s an inconsistency in documentation, UI/UX, and
architecture requirements between WMF-backed projects.
One extension might lack documentation, another has a specific technical requirement,
another uses a unique UI paradigm, another an entirely unique set of iconography (for
similar actions!). I expect this when dealing with individual non-WMF extensions, but from
the same organization?
An example: VisualEditor is great and I think it’s use will continue to grow. But holy cow
is it a big requirement to have to install node.js on top of the LAMP stack. Another: MW
core requires PHP 5.3.3, but Flow requires 5.3.6. PHP 5.3.3 is the default install for
RedHat RHEL 6 - a common flavor found in many enterprise environments (like my own).
Getting PHP updated is not only a technical challenge, but also an administrative one
inside large organizations. The server team wants to stick with what is supported via the
vendor, I want to use the latest innovative features. Conflict arises.
More consistency in extensions in general - There’s an opportunity to show a focused,
collaborative, platform for the experience within MediaWiki - and extensions from all
sources. Where’s the MediaWiki Style Guide for buttons, dropdowns, menus, etc? Some use
bootstrap, some use jquery, some follow WMF’s designs. Developers from all walks are
making cool things, but let’s make cool things like behave as part of something bigger.
WordPress, while not perfect, is a great example of a robust ecosystem of 1st-party and
3rd-party extensions attempting some semblance of integration.
Updates - Composer is for nerds. I mean that in a positive way - I’m a self professed nerd
(as shown by the length of this response). Composer, and the traditional
installation/update methodology for extensions is cumbersome and yet another requirement.
I want a one-click update button from a Special: page. It would alert met to available
updates (from mediawiki.org<http://mediawiki.org> or git gerrit) and let me install
them without touching a Terminal window. Yeah, I know that there’s a lot of crazy
interdependencies between MW versions and extension version - and between extensions
themselves. Maybe that’s telling? How do other open-source projects accomplish a much more
unified install/updating experience?
WMF Extensions (or any really!) prepackaged with necessary templates - UploadWizard is a
great extension that makes the uploading of images super easy and consistent. I love it.
However, it requires numerous template files and images to work, none of which is
documented or included. I don’t need to include every language and deep documentation for
all those templates. Just the basics.
If you use MediaWiki for your own wiki, what sort of things do you think
need more attention?
Uhh, I may have gotten carried away with the first question. See above? I think some of my
thoughts touch on the cultural aspects of MediaWiki. We’re a diverse group without a lead
on some of these things. How do we get big things done like improving extension
documentation? How do we make the experience more consistent when there are hundreds of
cooks in the kitchen? How can we encourage popular developers to lead by example? We’re a
very technical community - more so than say (again) WordPress. There’s a large dev-focused
community around that particular software, but there’s also a large group of people just
using it! I think communication should be a bigger area we focus on.
How can we help you find out about things you need
to know to run your wiki?
Documentation on mw.org<http://mw.org>. Regional (or online) hangouts - where I can
see someone’s screen as they talk about something. Social Media - twitter in particular. I
feel like it’s hard to know about discussions (like the removal of site stats) as they’re
happening. I’m into MediaWiki developments, but not to the point where I read every
Request for Comment (RfC). How do we bubble up that to more folks using MediaWiki?
--
Shameless Plug: If you’d like to share the work that you’re doing with a group of
3rd-party wiki folk, you should attend SMWCon Spring 2015:
http://semantic-mediawiki.org/wiki/SMWCon_Spring_2015 . I’m the Local Chair for the
conference and would love to see you there. I’d be happy to set aside some time on the
third day to continue discussions like this one.
Nerd in Residence,
Chris Koerner
This electronic mail and any attached documents are intended solely for the named
addressee(s) and contain confidential information. If you are not an addressee, or
responsible for delivering this email to an addressee, you have received this email in
error and are notified that reading, copying, or disclosing this email is prohibited. If
you received this email in error, immediately reply to the sender and delete the message
completely from your computer system.