I’m a light Wikipedia (and related projects) editor, but help to maintain and support two decent sized (hundreds of contributors, thousands of

internal wikis in the healthcare industry. Our organization has been

(Semantic) MediaWiki for over 6 years. I’ve been maintaining it for over

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

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,

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

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

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

things my co-workers care about - IE support and tables. I think

should increase the push for use of VisualEditor in third-party wikis.

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

set of iconography (for similar actions!). I expect this when dealing

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).

PHP updated is not only a technical challenge, but also an administrative one inside large organizations. The server team wants to stick with what

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

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,

let’s make cool things like behave as part of something bigger.

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

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

easy and consistent. I love it. However, it requires numerous template files and images to work, none of which is documented or included. I

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.

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

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

- 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

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

an addressee, or responsible for delivering this email to an addressee,

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. _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

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. _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Chad -- why would Mediawiki be the wrong tool if someone wanted to exercise some form of access control? Considering the number of extensions that have created for different types of access control it seems to be a very popular desire. Just because someone desires access control doesn't mean that they don't want the wiki experience elsewhere in their website -- they just don't want it on every page.

(Implicitly Mediawiki developers agree with this philosophy since all Mediawiki Namespace pages on every wiki have access control).

Strangely the only type of access control build into Mediawiki is a top-down centralized type of access control, which is strange when you think about it. Everyone agrees some type of access control needs to build into the software, but Mediawiki, out of the package, only allows a top-down centralized approach. Others just want more varied types of access control than the off-the-shelf model presented inside a standard Mediawiki.