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

This is a list of features commonly and widely requested by non-WMF users.

Release policy

 * Stable releases that don't break anything during/after upgrading.
 * Upgrade platform
 * 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.
 * To help select from and to support running on the wide variety of hosting options from free wiki-farms, through shared hosting to dedicated servers.
 * Up-to-date_documentation
 * 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.

Rights management

 * Access Control List, compare Grants:IdeaLab/A place to work together
 * Fine-grained access control
 * 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
 * Include a way to moderate/sandbox new users as an anti-spam measure, or have a way to approve genuine new users. For example 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.

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. Sometimes to get around this non-WMF wikis export templates from Wikipedia and then their users wonder why bits of Wikipedia (redlinks, context, logos etc.) are appearing in the other wiki. Also the imported pages may be without attribution, especially if the export included all the other transcluded pages. Alternatively just include a good range of templates with MediaWiki.
 * 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.
 * 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.

Extension management

 * Be able to pre-select extensions to download together in one bundle/tarball.
 * SMW documentation, power it by an SMW instance: show showcase of updated smw.referata.com
 * Installing extension as easy as in wordpress
 * SMW: Extension repository: Drupal/Wordpress: browse for plugins/extension, click on “install” or “upgrade”
 * precondition: extensions moved to composer? requires detailed analysis
 * what about “uninstall” - solved with 1)
 * deactivate vs. uninstall
 * 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?
 * 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
 * Extension management on MediaWiki installations for admins
 * 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.

Specific ideas for extensions

 * 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)
 * Install extension VisualEditor along with Parsoid easily.
 * Interwiki links to other wikis.
 * Trackbacks to other wikis and sources
 * 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.
 * Widgets as in Wordpress: More functionalities in menus (left, header, footer or in another menubars) like integration images, Facebook, iCal etc.

Gadgets management

 * A repository for JavaScript gadgets, (and other bits and pieces?) but separate from templates and extensions

Skin management

 * 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

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, Bugzilla, 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

Admin tools
Tools like, for example:
 * For backing up and restoring
 * AutoWikiBrowser, already available
 * WPCleaner
 * Check Wikipedia
 * autoFormatter

Developers

 * Easier contribution

Semantic MediaWiki

 * Semantic MediaWiki on mediawiki.org
 * 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.

Other features

 * 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

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)

Semantic-mediawiki.org

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