Jump to content

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

From mediawiki.org

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 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
  • Be able to pre-select extensions to download together in one bundle/tarball.
  • Installing extension as easy as in Wordpress (Autoupdater)
  • Automatic update (click on a button, ala dokuwiki)
  • Extension management and configuration from a webbased interface
  • SMW: Extension repository: Drupal/Wordpress: browse for plugins/extension, click on “install” or “upgrade”
    1. precondition: extensions moved to composer? requires detailed analysis
    2. what about “uninstall” - solved with 1)
    3. deactivate vs. uninstall
    4. where to put code/documentation: clear guidelines for developers: github used by many) or gerrit (official, with translatewiki support). mirroring how to do this, needs to be documented, ask Jeroen). move from gerrit to phabricator?
    5. directions on how to update existing extensions
  • Easy extension maintenance/updating, not having to check the status of each extension at every upgrade
  • Management of extension pages on mediawiki.org[1]
  • Extension management on MediaWiki installations for admins[1]
  • Be able to install all extensions without requiring superuser to modify system files. E.g. currently (Nov 2014/MW 1.24) can't install Math or VisualEditor without this.
  • Popular (and less popular) extensions don't get abandoned. When they've reached stable and are in enough use these are still supported/developed when e.g. the original author moves on to other projects.
  • 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.
  • That the distribution and extensions etc. take into account that small (possibly experimental/trial) wikis using cheap shared hosting might have only restricted access to the shell, e.g. they can't use git, nor make. See the confusion caused by lack of texvc in extension Math.

Upgrade process

  • Easier install and upgrade process. Better backwards compatibility or help making sure extensions don't blow up with updates.
  • Stable releases that don't break anything during/after upgrading.
  • Upgrade platform[1]
  • To help select from and to support running on the wide variety of hosting options from free wiki-farms, through shared hosting[2] to dedicated servers.[3]
  • Up-to-date_documentation[1]
  • MediaWiki as framework: Standardized interfaces in MediaWiki for different solutions or distributions (documentation, translation, public wikis … SMW)
  • Don't include developer cruft.
  • Packaging consistency - don't have sometimes download tarball and other times download from Git.
  • Getting rid of external services (e.g. nodejs for VE)
  • Easier cross platform deployment

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.

Detailed Requirements - VisualEditor
  • VisualEditor "bulletproof"
  • VisualEditor stable and working in an LTS or stable build.
  • Visual Editor installable/customized widgets
  • 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.
  • Easier visual editor deployment.
  • A completely visual editor ready to use out of the box included in the package at installation.
  • 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.
  • Install extension VisualEditor along with Parsoid easily.[2][3]

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.

Detailed Requirements - Skinning and UI
  • Skins known to work well with Semantic MediaWiki.
  • Skinning is a MW topic, but it is a mess, MW:Category:Skinning
  • Standardized interfaces in MediaWiki skins for the integration of new functions without customizing the skin.
  • Skins[1]
  • Improve of the UI. Haven't tries other skins yet, though.
  • 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)
  • Improvement of general usability and interface, also the skin
  • Creating new skins and replacing the background should be easier for end-users.
  • User Interface, simple usability, simple upgrade/extension handling, ability to choose skins and/or adapt skins easily (without as much HTML/PHP/CSS knowledge), clearer error reports + solutions
  • Ease of deployment and customization of skins... difficult to go back to managing MediaWiki after experiencing the level of user friendliness of Wordpress.
  • Easier theming

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.

Detailed Requirements - Access Controls
  • Access Control List, compare Grants:IdeaLab/A place to work together
  • Fine-grained access control[1]
  • HaloACL testing, documentation and avoiding patching in future. How to get MediaWiki.org to keep things in core that we need for HaloACL. New HaloACL GitRepository
  • Access control (Lockdown etc.)
  • Better spam protection
  • Include a way to moderate/sandbox new users as an anti-spam measure, or have a way to approve genuine new users. Examples: mw:Extension:Moderation or a slimmed down mw:Extension:ConfirmAccount, where it only asks "Hello, please tell us briefly about yourself and why you'd like to edit this wiki?". Currently any new non-WMF wiki is unexpectedly left open to spambots.[4][5][6][7][8][9][10][11]
  • 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.
  • Per-category and/or per-namespace access control
  • Better support for limiting read-access.
  • We would use it much more in business if page-level access control were more possible.

Secondary Requirements

[edit]

Performance

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

Detailed Requirements - Performance
  • Reduction of memory footprint, increase of performance
  • More ajax instead of reloading whole pages
  • 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 efficient.

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.

Detailed Requirements - Media Management
  • Easier management of media files
  • Easier integration for local files and media.
  • image upload and licensing within page authoring workflow

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.

Detailed Requirements - Template Management
  • A repository for templates and dependencies, e.g. Scribunto modules, Lua modules, JavaScript, CSS, etc. Otherwise non-WMF wikis have to export/import and debug, these from wikipedia. Making a mess of the wiki with unwanted Wikipedia specific bits.[12][13][14][15][16][17][18][19][20][21][22][23]
  • Will the wikis using this repository then be part of a wiki-farm? Alternatively just include a good range of templates with the MediaWiki software.
  • Templates on WMF sites themselves differ between sites
  • Supporting templates on cheap shared hosting, where Scribunto fails because of the disable_functions directive in php.ini.

Release Management

[edit]

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


Detailed Requirements - Release Management

Admin tools

  • Standard admin functions as part of the MediaWiki core (rename / merge users / spam stuff)
  • A great administration interface (think WordPress)
  • Allow categories to be renamed and deleted with single, simple operations.Tools like, for example:
  • For backing up and restoring
  • AutoWikiBrowser, already available
  • WPCleaner
  • Check Wikipedia
  • autoFormatter
  • A repository for JavaScript gadgets, (and other bits and pieces?) but separate from templates and extensions[17][15][12][13][16][14]

Semantic MediaWiki

  • Better and more intuitive Semantic MediaWiki integration
  • Semantic MediaWiki on mediawiki.org[1]
  • Being able to access data from external websites, e.g. to display prices that are current.
  • Creating an article with an infobox. Lists wherever about the subject should automatically update with the data from the infobox. The page itself should be automatically inserted into the relevent navboxes.
  • SMW documentation, power it by an SMW instance: show showcase of updated smw.referata.com

Miscelaneous

  • A calender management system to use different calender systems.
  • An improved pdf handler.
  • Upload of Office documents (docx etc.). Security issue. Needs changes in MW core. (see talk page discussion)
  • A way to automatically archive any new external link to e.g. WebCite or archive.today. For citations with link rot to be repointed to the archived copy.
  • A way to scan through all external links and to offer repointing any failed ones to a new URL, e.g. if necessary to Archive.org. (see Extension:ExternalLinks)
  • Interwiki links to other wikis.
  • Trackbacks to other wikis and sources
  • File handling (ClipUpload etc.),
  • Support and maintain the obsolete Extension:WikiTeX or something more user friendly. So that users can illustrate articles, in a consistent style, without having to make much more effort than regular editing. For example: graphs, plots, charts, venn diagrams, structural formula for chemical compounds, circuit diagrams, musical scores, etc. Maybe a better solution would be a stand-alone application (e.g. LibreOffice Draw, Inkscape, Xfig or WinFIG) plus libraries. Then the wiki just needs to handle the uploaded images.[13]
  • Widgets as in Wordpress: More functionalities in menus (left, header, footer or in another menubars) like integration images, Facebook, iCal etc.
  • Feature for MediaWiki users to see all pages viewed by day
  • Feature to set local timezone as default
  • Feature to modify MediaWiki so that it sends an HTTP 301 or 302 redirect to the target page when #REDIRECT is done
  • Feature for automatic article summary on main page
  • Updated extensions for comment threading in talk pages
  • Better cross-wiki content integration (global modules/gadgets)
  • Connectivity to other business tools like tools for process description.

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]

Phabricator

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

Metawiki

[edit]

MediaWiki.org

[edit]

Semantic-mediawiki.org

[edit]

Skinning

[edit]

Other

[edit]
[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
Retrieved from "https://www.mediawiki.org/w/index.php?title=MediaWiki_Stakeholders%27_Group/Tasks/Feature_wishlist/2015_assessment&oldid=5725796"