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

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

Rights management

 * Access Control List, cf. m:Grants:IdeaLab/A place to work together
 * SMW: 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 : https://github.com/HaloACL/HaloACL1.8

Extension 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.
 * SMW: Extension documentation on mediawiki.org: 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 a)
 * 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
 * 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. See bug 64475
 * A repository for JavaScript gadgets, and other bits and pieces but separate from templates
 * Easy extension maintenance/updating, not having to check the status of each extension at every upgrade

Release policy

 * Stable releases that don't break anything during/after upgrading.
 * That the distribution and extensions etc. take into account that small wikis using economical hosting might have only restricted access to the shell, e.g. they can't use git, nor make.
 * MediaWiki as framework: Standardized interfaces in MediaWiki for different solutions or distributions (documentation, translation, public wikis ... SMW)

Skinning

 * SMW: For a start: SMW community, add to https://semantic-mediawiki.org/wiki/Help:Skins
 * SMW: Skinning is a MW topic, but it is a mess:: https://www.mediawiki.org/wiki/Category:Skinning
 * Standardized interfaces in MediaWiki skins for the integration of new functions without customizing the skin.
 * SMW: Supported skins and skins in the future
 * Bootstrap extension: http://www.mediawiki.org/wiki/Skin:BootStrapSkin
 * See also the skin mentioned at the conference: http://www.mediawiki.org/wiki/Skin:Chameleon
 * See also https://github.com/thingles/foreground/
 * Not skins, but idea dumping grounds
 * What’s happening with Athena? https://www.mediawiki.org/wiki/Athena If going on, could broader community benefit?
 * See also Winter: https://www.mediawiki.org/wiki/Winter

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
 * Widgets as in Wordpress: More functionalities in menus (left, header, footer or in another menubars) like integration images, Facebook, iCal etc.

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.
 * Cf. Wikimedia technical search
 * 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.
 * 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.
 * 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?

Admin tools
Tools like, for example:
 * AutoWikiBrowser, already available
 * WPCleaner
 * Check Wikipedia
 * autoFormatter

Further feature lists

 * Metawiki: MediaWiki Feature Request (Archive)
 * MediaWiki.org:
 * Enterprise hub
 * Academic hub
 * Software bundles
 * MediaWiki4Intranet
 * semantic-mediawiki.org: SMWCon Fall 2014/Create camp
 * Planned Features for SMW (2012)