MediaWiki Usage Report 2015/What would you like to see most improved in MediaWiki the software?

Mentions are in brackets (e.g. 7).

Installation, Upgrade/Update. (13)

easy install and upgrade process, easy management
automatic updates
updates with one click

composer-based installation – not sure if this was mentioned as easy or difficult
push updates, similar to WordPress

„Maintaining the site is a bit of a headache. Some extensions are especially troublesome (particularly Collections, SMW, and even Math).“

„installability. I also run dokuwiki in a similar org. It's way easier to provide a useful environment to users there within just a couple of clicks. Upgrading is a breeze there.“

Extensions. (17)

improve extension discovery
improve extension installation/deployment
improve extension configuration
use webbased interface, configuration through admin panel: „Extension Manager“
similar to WordPress
improve sandboxing of extensions to not alter core (similar to WordPress) – (child theme??)
automated dependency check (MW core <> extensions) – backwards compatibility or make sure extensions don’t blow up with updates.
package manager
1-click-installation
configuration wizard
auto-update function
backword-compatibility of core and extensions to older versions and to PHP-Updates

„I would like to see Wikimedia stop looking at essential extensions (ElasticSearch, Echo, VisualEditor) as add-ons instead of integral parts of the software. I mainly refer to the fact that development of those continually ignores the release cycle, only taking into account Wikimedia's rolling updates.“

„Ease of installation of extensions has improved, but a more seamless installation process would be appreciated for me and my team.“

„For the most part the core MediaWiki code is pretty solid; however, the addition of composer, specifically extension installation via composer, has been a bit of a bear. Using composer for standard libraries that MediaWiki makes sense, and allows easier standardization for any extensions that want to use the same libraries. However, when it comes to extensions it has become a bit of a mess, especially with trying to efficiently control how they are managed. Especially if I need to quickly disable one on the fly for some quick testing (extension conflicts), or just troubleshoot a particular extension with a debugger.“

Editor. (13)

WYSIWYG-editor
complete visual editor, ready to use out of the box, included in standard installation
Visual Editor stable
Editor with a lot of features, nearly like Word
more features, more intuitive

„Continue developing VisualEditor until it's bulletproof.“

„ The editing experience (wiki markup) is what puts many people off editing/authoring.“

„ I would love to see VisualEditor more mature and with a built-in spellcheck - and working for IE. I would also like to see better support for the LTS versions - it seems like VisualEditor development moves forward with the newest updates to core, but they don't always get back-ported to the LTS version in a timely manner.“

„My users want wysiwym editing.“

Enterprise support: Access control. (12)

Bugreport, change request handling, based on the needs of paying customers
functions for MW to be included easier into enterprise environment, like ACL.
refined access control lists
per-page edit and edit rights
per-category
per-namespace
limiting reading-access

„In an enterprise we *know* who everyone is and they do, generally follow the rules. I would build the easy of watching content, keeping up on changes, who has the rights to change things, and who should check it off as being golden. The articles are great; we have a small set of reviewers and need tools that help us watch and verify the content.“

„I'd like to see better "enterprise" extensions to provide CMS-like functionality such as fine grained access control. I realize this type of functionality isn't very Wiki-like, but regardless, I get asked for it all the time.“

„Sometimes I wish, MediaWiki would support ACLs. MediaWiki is not usable as a knowledgebase in our company, because we have to restrict access of some parts to a few users. I would like to use MediaWiki instead of another Wiki or a CMS, but this key feature is not available. But I know that this is not the scope of mediawiki. ;-)“

„We would use it much more in business if page-level access control were more possible.“

Graphic User Interface (GUI), User Experience (UX), Usability (11)

Customization: Easy ways to customize the UI - a more modern look. An extension that lets a company easily brand/color scheme their wiki instance.
simple usability
ability to choose skins and/or adapt skins easily (without as much HTML/PHP/CSS knowledge)
Better customization within the interface without the need for a lot of things going to LocalSettings.php. That is the major bug for Wikifarms.
An easy to customize user interface where we can blend out everything that is not necessary for the unregistered reader
General usability and interface. Also the skin and the connectivity to other business tools like tools for process description.
Convenience for users.
easier visual editor deployment.

“IMO, most of the good wiki implementers (consultants) are interested in all the background plumbing of what MW can do - and UI is an afterthought. This is not a good approach for wider update. Average folks can't "see" what is cool about software, if it does not look good. “

“the ui. haven't tries other skins yet, though.”

“The reading side of things is kind of okay (though still far behind the rest of the web in terms of design and usability). However the editing side of things still feels very primitive and inaccessible. We need to start treating the special pages, edit page, review systems as a modern web application. Stop throwing more text at problems (endless walls of text) and start simplifying the interface in terms of design and UX. Even ignoring all of wikitext and templates, the experience of being a logged-in user is terribly outdated and full of usability nightmares.”

Skin. (7)

improve skin making, theming
templating system, restructuration of skin system

„Creating new skins and replacing the background must be easier for end-users.“

„Skinning (under way now, but I still have to see if any of my current sites can be upgraded without doing all the skinning work again)“

“Ease of deployment and customization of skins... difficult to go back to managing MediaWiki after experiencing the level of user friendliness of Wordpress.”

Spam (6)

automated spam catching
better spam tools
Clearer direction and configuration for anti-spamming techniques, though this will vary ending on the spectrum of public to private participation

„Every one of my wikis ends up dying or having to restrict access because of spam, even the ones maintained by 2+ MW-savvy people, as soon as it first becomes popular on google, and then the # of active patrollers drops too low.“

“Spam is a major problem on public sites. “

Codebase (5)

some standard admin functions into core (rename / merge users, spam stuff)
Stop removing/renaming core functions and variables
getting rid of external services (eg. nodejs for VE)
More ajax instead of reloading whole pages
More disbundled features from core to extensions, and perhaps a "lite" package of selected features.

„MediaWiki is a very big piece of software, and it only gets bigger and bigger. There aren't many performance improvements, and high-traffic MediaWiki sites won't run well without the help from HHVM and caching (e.g. Varnish and Redis). It would be cool if a big amount of code can safely be rewritten so that it is more efficiently. (not sure if this belongs to "community around MediaWiki") Also, it looks like that there are bugs which are very old (e.g. more than 3 years), and still not resolved. Old bugs = long-term bugs, and those are bad.“

Speed. (4)

Reduction of memory footprint, increase of performance

Development. (4)

As a developer, a modernized architecture (dependency injection, an ORM layer, proper skinning, decent test coverage...).
Way of making patches.
The development experience. Documentation is a mess of outdated information, and totally lacking a decent architectural overview and "public" api specification for extension developers.
easier cross platform deployment.

Files (3)

Easier integration for local files and media.
file handling (ClipUpload etc.), access control (Lockdown etc.)
Easier management of media files
Export files or a way to download all files in a zip-file.

Images (4)

image upload and licensing within page authoring workflow
Offline content generation doesn't support any extension-generated images. For example, it doesn't interoperate with the ImageMap or GraphVis extensions. I raised a bug but hey, a little more visibility couldn't hurt.
Better/easier image management -- the upload/link procedure is a bit tedious. Easier justification for keeping current -- it's not clear why I should suffer the inevitable pain of changing versions.
Easier upload (too many steps, too complicate for endusers)

Language (3)

Improved robustness of i18n caching
auto multi languages
Multiple Languages by default, Cache by default pre-installed and outsourceable

Database (2)

better support for non-MySQL databases
support for Oracle database

Mobile Frontend (2)

Out-of-the-box mobile support

Error messages (2)

clearer, more precise and helpful error messages (often these are easy things to address if one has good access to the code and observes an error condition)
clearer error reports + solutions

Wiki-Farm (4)

single-sign-on for wiki farms
enable multi-site searching
better multisite tools/extensions
support for wiki farms, wiki farm management portal

Search. (2)

search engine weak, improve

New Users (2)

better onboarding and tools for new users, gamified social aspects to entice prolonged usership
It is difficult for beginners to learn about the software, especially if they have no formal training in code and the like. The documentation assumes a lot of the users have prior knowledge.

Templates (2)

A way to share content (templates, forms, properties). Something similar to the way system messages can be shared in a flexible way.support for easier development of templates.

Watchlist (2)

Corporate use doesn't allow users to be anonymous, so ways to share lists of pages/articles to be watched would improve productivity (force watches would also be good)
Watchlist changes appear in notifications.

Discussion (2)

disussion tools, Updated extensions for comment threading in talk pages,

Single mentions.

ADMIN: great administrator interface (think WordPress)
CATEGORIES: Allow categories to be renamed and deleted with single, simple operations.
Enable small contributions, also per mobile
PDF export
RSS integration
IDE: We have a mix of structured and unstructured content and are building apps inside the mediawiki/SMW infrastructure.. Therefore we would need a real IDE, perhaps some kind of Eclipse for MediaWiki and SMW.
Import / Export of data, better Schema editing. Mobo (by Simon Heimler) is a good 3rd party tool that develops in the reoght direction
SMW: Better and more intuitive Semantic MediaWiki integration
CACHE: Overall Redis support to eventually replace Memcache.
USER INTERACTION: the interaction between user could be better. profile page, inter member discussion, should be improved ( see MW ep_lite plugin for quick multi user editing ) clarify the free editing concept for use as collaborative tool
Better ability to handle data that can be used for further scientific data mining: Ability to display (and format) and edit table-like data, eg., handle cvs like data. Representation of units in Wikidata (wikibase) http://neuro.compute.dtu.dk/wiki/Major_Depressive_Disorder_Neuroimaging_Database_-_Amygdala,_total_-_Statistics
WIDGETS: customized widgets
WIKITEXT: User-friendliness of wikisyntax, Wiki markup syntax highlighter
LOGIN: - Standard ways to login with LinkedIn, Facebook or Google credentials.
(3) Fix numbered lists so you can insert other wikitext into the middle of a list (like images) and not break the numbering.
As a Wikimedia user, the things I want most are on the way (good WYSIWYG, single sign-on an app integration, sane communication tools, semantic data). The things I would like to see most that are not works in progress are probably better cross-wiki content integration (global modules/gadgets).
email-Bouncer, Installation Part of the Visual Editor, Possibility to include different links in the side bar depending on the user lanuage, and as a (small) extension developer: a tool or any log to recognize that api calls are deprecated and how to replace them.
tools to determine the pedigree of each contribution to each page thus enabling the ranking of how trustworthy each bit of knowledge is.

Nothing. I love it.

„Nothing stands out. Happy to ride the slip-stream of a vast technical user knowledge-base.“

„the way it is right now is just fine :)“

„MediaWiki does pretty much everything I expect and want from it. If I have any complaints, they are chiefly around much things change between releases. As an example, I had a significant problem upgrading from version 1.23 because of the complete restructuring of how skins were handled. I was using a custom skin which I had to abandon because I did not have time to completely rewrite it to fit with 1.24+. Fortunately, I was able to work around this by using MediaWiki's built-in custom CSS and JavaScript functionality, but I wasted a full day trying to figure out how this worked. Such a major restructuring in a "minor point release" is an annoyance, and I don't think it was communicated well to downstream, non-WikiMedia users of MediaWiki. MediaWiki development seems to be very fast and volatile, making building a third-party site based upon it a risky and difficult process. Non-WikiMedia users are left to fend for themselves as the software seems to change at the slightest whim of Wikipedians.

„at the moment it does everything it has to, we are used to it“

„I pretty much love it as is.”

“First I want to say that we really love working with MediaWiki! […]”

??

You would have to ask my dev team :-)
Releases & Versions
More possibilities for easy enhancements
less favouritism for wikia, better performance
Multi part content.
parser function aware editor would be nice...
server usage
We are 1FOREVER FREEDOM everywhere
Ease of sharing information, SMW Like features, stability in the software
Security
shadow namespaces
The main mediawiki parser and job system.