MediaWiki Stakeholders' Group/Tasks/Feature wishlist/2015 assessment

Feature Wishlist describes the most wanted requirements of MediaWiki users beyond the Wikimedia projects. For new additions and ideas, please use the talk page to discuss additions and help to prioritize the list.

Current Surveys
There has been several initiatives to collect needs of MediaWiki users (see further links on the end of this article).

In 2015, the MediaWiki Stakeholders Group explored the current desires of MediaWiki users. In a first step we asked the group members about their requirements and documented those requests here. In a second step, a MediaWiki User Survey 2015 was launched and received 137 answers from MediaWiki users from around the globe. The results of both activities became the foundation of this current feature list.

Easier installation, extension management and a better upgrade process
Most users want improvements in the extension management (10 mentions in the survey), installation (6) and upgrade (11). And they ask for auto-updates (9). Appropriate extensions should be easier to find, install and customize. Today's organization on MediWiki.org falls in many respects behind the standards in other Open Source projects (for instance find the most popular extensions). Although the installation of extensions is not difficult, systems like WordPress show that fast installations by click or auto update functionalities are expected.

Making upgrades is still problematic, sudden technological changes make it difficult for the developer communities and users to keep their MediaWiki and extensions of third party users current.

Many features could easier maintained with a better standardization in the extension management and with a reliable release policy.

Editing and VisualEditor
The development of VisualEditors (VE) concerns users outside of WMF. Users and companies have been waiting for a native solution for years: The usage habits have changed rapidly and MediaWiki lost rapidly attractiveness. In other words, MediaWiki is not competitive without an VE compared with other products such as Confluence.

The problem has been recognized by WMF and a development process has been initiated. The polls show large support for the VisualEditor development. Even there are still problems. Seventeen (17) answers in the MediaWiki Users Survey 2015 address this issue. External users have considerable difficulties to use the tool. There are technical barriers (e.g. Parsoid) and interfaces missing. Most wanted is a better stability.

Skinning and UI
When it comes to skinning and UI MediaWiki has made real improvements in the past, but a lot of non-WMF users (14 out of 137 answers) see still a major task for further developments. Again WordPress is the benchmark in many responses and suggestions.

The general revision of the UI is pending. Integrative UI projects such as Athena or Winter were not continued. Although MediaWiki offers a convincing solution with Mobile Skin (Mobile Frontend Extension) Wiki maintainers often asked for responsive skins for MediaWiki. Wiki maintainers also critize, that it is not easy to select and integrate skins. A professional skin management would be helpfull. Today skins still must be customized with HTML and CSS skils for instance for an integration of some extensions into the skin layou.

This relates to the question how we can establish some binding architectural standardization and style guides which would ease skin programming by third party developers.

Access Controls and Rights Management
Even if that sounds strange for Wiki enthusiasts many wikis outside the WMF world require a granular rights management system. Public wikis need internal pages to organize themselves or they must control the visibility and edit rights of pages for other reasons. In businesses and organizations the situation is quite similar. Even if the wiki managers are willing to configure the wiki as open as possible, a rights management for individual users and user groups on namespace or page basis is very often needed. That's the reason why 12 (out of 137 responses) address this topic.

Performance
Performance is an ongoing and complex issue. If the MediaWiki development focus on Wikimedia sites, it comes out of scope that ordinary MediaWiki sites don't have the possiblity to install load balancer and several servers. That's why many users ask for an architecture that answers to confined ressources.

Media Management and Licensing
Users need to ensure, that users only upload files legally and with the necessary meta data. And the management of media files is still very cumbersome.

Template Management
Templates provide a lot to a wiki. However most non-WMF wikis make very little if any use of templates. The user wants a wiki they can install and then just get on with using. Templates are unwanted extra work. Having to learn how to write and debug templates, Lua, etc. to make use of them is too much to ask for – that's not what the end user wants to be doing. Templates transcluding templates is confusing, and using style sheets.

Sometimes to get around this non-WMF wikis export templates from (English) Wikipedia and then their users wonder why bits of Wikipedia (admin categories, redlinks, context, logos etc.) are appearing in the other wiki. Also these imported pages may be without attribution, especially if the export included all the other transcluded pages. There is no single interface to manage all the imported pages. Wikipedia doesn't use latest stable as most non-WMF wikis are advised to do, so things break. Wikipedia has some very complicated templates, using many sub-elements which also need to be included or things won't work quite as expected.

Release Management
Consistent releases, integrate crutial extensions (echo, ve, flow, etc.), compatibility

Marketing Tools and User Support

 * Places for brochures, promotion videos and screencasts and project descriptions
 * Navigable user support, i.e. easy to find solutions. Currently there are multiple routes to use, Phabricator, MediaWiki-l mailing list, talk pages, Project:Support desk, etc. Compare Wikimedia technical search.
 * Ways to encourage users to register and contribute to the wiki, e.g. wysiwyg editing, social networking, rewarding user contributions by keeping a score/rank, etc.
 * Talent pool, central resource for technical writers, illustrators, coders, etc. to offer their services, free or paid, to work on wikis. MediaWiki vendors?
 * Better visibility for Third-party users.
 * Integration with external tools

Developer Support


 * Easier contribution


 * A modernized architecture (dependency injection, an ORM layer, proper skinning, decent test coverage...).

Phabricator

 * T113210 How should the WMF support non-technical mediawiki installs?

Metawiki

 * MediaWiki Feature Request (Archive)

MediaWiki.org

 * Enterprise hub, wikis for corporate (or organizational) context
 * Academic hub, wikis for academia
 * Bundling, for some users it's preferable to get MediaWiki up and running with a software bundle. E.g. MediaWiki4Intranet
 * Talk:Third-party MediaWiki users discussion and Summary of third-party users discussion (spring 2013)
 * Feature Map, taxonomy of possible additions and changes to the MediaWiki software and to other parts of Wikimedia's technical infrastructure, validating potential features against Wikimedia's strategic plan

Semantic-mediawiki.org

 * SMWCon Fall 2014/Create camp
 * Planned Features for SMW (2012)

Skinning

 * What’s happening with [//www.mediawiki.org/wiki/Athena Athena]? If going on, could broader community benefit?
 * BootStrapSkin skin
 * Chameleon, a highly customizable MediaWiki skin
 * Examples of non-WMF MediaWiki wikis where extra care has been taken with the skin: [//www.mansonwiki.com/wiki/Main_Page MansonWiki] and [//userbase.kde.org/Welcome_to_KDE_UserBase KDE UserBase Wiki]
 * [//github.com/thingles/foreground/ Foreground] skin that emphasises the wiki's content