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.
- 1 Current Surveys
- 2 Primary Requirements
- 3 Secondary Requirements
- 4 See also / Further feature wish-lists
- 5 References or external links about the same issue
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 MediaWiki.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.
|Detailed Requirements - Extension Management|
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. Most wiki farms and hosting services find VE too complex to implement.
|Detailed Requirements - VisualEditor|
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.
|Detailed Requirements - Skinning and UI|
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.
|Detailed Requirements - Access Controls|
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.
|Detailed Requirements - Performance|
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.
|Detailed Requirements - Media Management|
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.
|Detailed Requirements - Template Management|
Consistent releases, integrate crutial extensions (echo, ve, flow, etc.), compatibility
|Detailed Requirements - Release Management|
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
- A modernized architecture (dependency injection, an ORM layer, proper skinning, decent test coverage...).
See also / Further feature wish-lists
- MediaWiki Feature Request (Archive)
- 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
- What’s happening with 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: MansonWiki and KDE UserBase Wiki
- Foreground skin that emphasises the wiki's content
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/2015 assessment
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/2019 assessment
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/Aaron B
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/Alaete
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/GabrielLee
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/Husun Shujaat
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/NAME
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/Pranav K January
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/Pranav K July
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/Pranav K June
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/Robin Verhoef
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/Robin Verhoef June
- MediaWiki Stakeholders' Group/Tasks/Feature wishlist/Template bundling
- Third-party MediaWiki users discussion/Summary, 2013.
- Talk:Parsoid#VPS needed?
- Comes up regularly on Mediawiki-l.
- Stack Overflow:How to prevent mediawiki spam
- Stack Overflow:How to make Mediawiki account registrations only allow unique emails?
- Stack Overflow:Mediawiki Moderation
- Stack Overflow:Mediawiki rollback bot (Mass undo troll actions!)
- Stack Overflow:Reliably detecting PhantomJS-based spam bots
- Stack Overflow:Making registration for media wiki require admin approval?
- Stack Overflow:Mediawiki database recovery
- Task 52329: We need a common repository for Scribunto modules and templates
- 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)
- Task 66475: Make crosswiki bits and pieces truly global
- Task 6547: Support crosswiki template inclusion (transclusion => interwiki templates, etc.)
- Task 58388: Pre-packaged templates for new MediaWiki installs (closed as declined)
- Task 41610: Scribunto should support global module invocations
- Requests for comment/Global bits and pieces
- Requests for comment/Shadow namespaces
- User:Peter17/Reasonably efficient interwiki transclusion
- Global templates and Lua modules is also an aim of Project:MediaWiki Farmers user group
- Template repository