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

Jump to navigation Jump to search

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[edit]

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.

Primary Requirements[edit]

Easier installation, extension management and a better upgrade process[edit]

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 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[edit]

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. Most wiki farms and hosting services find VE too complex to implement.

Skinning and UI[edit]

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[edit]

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.

Secondary Requirements[edit]


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 possibility to install load balancer and several servers. That's why many users ask for an architecture that answers to confined resources.

Media Management and Licensing[edit]

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[edit]

Currently templates are a huge and unnecessary multiplication of effort and a huge waste of resources, every wiki admin has to re-invent the wheel for themselves.

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[edit]

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

Marketing Tools and User Support[edit]

  • 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.[1]
  • Integration with external tools[1]

Developer Support

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

See also / Further feature wish-lists[edit]


  • T113210[1] How should the WMF support non-technical mediawiki installs?




References or external links about the same issue[edit]

  1. 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 Third-party MediaWiki users discussion/Summary, 2013.
  2. 2.0 2.1 Extension_talk:VisualEditor#Using_VisualEditor_on_shared_hosting
  3. 3.0 3.1 Talk:Parsoid#VPS needed?
  4. Comes up regularly on Mediawiki-l.
  5. Stack Overflow:How to prevent mediawiki spam
  6. Stack Overflow:How to make Mediawiki account registrations only allow unique emails?
  7. Stack Overflow:Mediawiki Moderation
  8. Stack Overflow:Mediawiki rollback bot (Mass undo troll actions!)
  9. Stack Overflow:Reliably detecting PhantomJS-based spam bots
  10. Stack Overflow:Making registration for media wiki require admin approval?
  11. Stack Overflow:Mediawiki database recovery
  12. 12.0 12.1 Task 52329: We need a common repository for Scribunto modules and templates
  13. 13.0 13.1 13.2 Task 56221: Support for text/syntax/markup driven or WYSIWYG editable charts, diagrams, graphs, flowcharts etc. (Identify, develop, review and deploy extension on Wikimedia wikis to add)
  14. 14.0 14.1 Task 66475: Make crosswiki bits and pieces truly global
  15. 15.0 15.1 Task 6547: Support crosswiki template inclusion (transclusion => interwiki templates, etc.)
  16. 16.0 16.1 Task 58388: Pre-packaged templates for new MediaWiki installs (closed as declined)
  17. 17.0 17.1 Task 41610: Scribunto should support global module invocations
  18. Requests for comment/Global bits and pieces
  19. Requests for comment/Shadow namespaces
  20. Global-Wiki
  21. User:Peter17/Reasonably efficient interwiki transclusion
  22. Global templates and Lua modules is also an aim of Project:MediaWiki Farmers user group
  23. Template repository