MediaWiki.org is the central web page for the distribution of mediawiki extensions. But in comparison to other open source projects the usability for developers and users is underdeveloped. For instance: extensions can't be rated, there are no statistics of most wanted or downloaded extensions available.
That makes MediaWiki uncomely for developers and users.

• How can Mediawiki.org be improved in direction to an up to date extension store?
• Which developments are necessary, which are nice to have?
• How can improvements be realised? Technically and politically?

Thanks, Richard, for leading this. When is our first meeting to flesh this out?

Would it be in scope to discuss the extension installation/update experience? After hearing folks talk for so many years about how much better the plugin management experience is in WordPress, I am now experiencing that first hand. You install the plugin from the front end in an administrator console. Further, when a plugin update is available, a message on the administrator console indicates this, and the plugin can be updated at the push of a button. It would be great to have this as part of the functionality of the extension store.

As I understood it, @RichardHeigl "volunteered" for doing the research! :) I think it is too early to open up the discussion, before we go into detail, we could need an analysis of the current "store" and existing stores (WordPress, Magento etc.) plus problem/demands descriptions and goals/improvements. From this, we shall get a concept draft, which can be opened for discussion. Richard, do you think we can start with this?

@cicalese, I believe, the installation/update process is absolute crucial part of this!

Please fill me in, in case I misunderstood!

Possible problems:

• Many extensions are outdated, the documentation, the status is not up-to-date.
• The update process of extensions is non-automatic and tedious.
• Extensions are not tested against new core releases.

Already there (see Template:Extension):
Technical info:

• Release status.
• Latest version, latest preview version
• Implementation type (special page, hook, wikipage, parser function etc.)
• Database changes
• Tables
• Namespace, Parameter, Hooks used and provided
• Vagrant roles
• Links to open bugs in Phabricator

Installation info:

• Compatibility notes: "MediaWiki 1.17+". "PHP 5.3" – Is this info sufficient?
• Composer
• Download link

Developer info:

• Author/Developer
• License note

Usage info:

• Description
• Image (Screenshots)
• Example
• Link to translation page

In fulltext: Release notes, installation instructions, extension dependencies.

Feature ideas:
see also Magento Connect and WordPress plugins

• New rating system for extensions: 1–5 stars for e.g. "Usefulness, Functions as Described, Developer Support"
• New statistics: Most wanted extensions, most downloaded extensions, most highly rated extensions (total, average, percentage)
• Popularity score: The download statistics visualized in an icon with 5 versions.
• User text reviews with commenting functionality – extended talk page?
• Follow this extension – via watchlist, but also via email, RSS/Atom
• Developer info – Contact possibilities and preferences (email, talk page etc.) – template that lets developers include a nice list of their extensions on their user page, statistics about the developer
• Compatibility: "Tested with" – extended compatibility notes – "requires 1.21.x, compatible up to 1.25.3" (see WordPress!) –  what has been tested, what is supported and what is assumed – also "intercompatibility", compatibility between extensions
• Enhancement of screenshots and use case examples – extend the existing "Example"
• Short screencasts
• Extended usage information beyond technical settings.
• Link to WikiApiary
• Info about CSS classes for styling.

Extension management for admins (on a special page):

• Get notifications at new releases, choose automatic or manual update.
• Functions:
  • Install new
  • Activate/Deactivate
  • Delete
  • Edit settings

Please add @Kghbln and @Lex as subscribers! – Edit: Aha, with this I just did.

@RichardHeigl, @ZaBien, @cicalese: thanks for diving into this. I'm always worried that decisions made on a Friday will be forgotten.

T90345: A proper catalog of extensions was first but this task here has already more beef.

See also https://www.mediawiki.org/wiki/Google_Summer_of_Code_past_projects#Catalogue_for_MediaWiki_extensions , mentored by @MarkAHershberger and @Mglaser

Another related task: T534: Create a List of Requirements for Extension Management

Hi. This is hwat I call an "agile" discussion. Before I make some additional remarks, should we arrange an hangout meeting e.g. on Friday 20th of November? 4 PM (European Time)??

this task here has already more beef

Not in task description though, please edit.

@RichardHeigl, please add your remarks anyway! What's the intention for the Hangout? I suggest to state clear questions to be answered (agenda) before. This is a topic with a lot of technical details which cannot be discussed easily within an hour (your initial 3 questions included). Please help me working on the details as basis for discussion: a concept draft for an improved extension "store". See my humble list above as starting point. Sounds good??

@ZaBien: Thanks for the helpful feature collection! I completely agree, that in a first step we need other stores as a benchmark. My first impression is, this is nearly a complete list to create happy users. :-)

Many requirements could be met by improving the exsting templates or with semantic extensions for lists. But there would be some extension programming and maintaining necessary. I can imagine, that WMF could help a bit with the funding? Maybe. Don't know.

For setting up an ecosystem it would be helpful, that third party user can offer extensions or skins for a small or greater amount of money. MediaWiki.org won't support this for good reasons. The sponsor is a non-profit organization. So we should maybe envisage links to pages and other stores.

@cicalese: Yes. In my opinion this extension issue has at least three components.

• Extension store / repository - where you get extensions and descriptions. Or at least links, whre you can find it in the web.
• Upload and extension management - standardization of architecture and installation routines (check version and compatibility...)
• One-click installation of extensions, templates and skins from an extension repository via web and as part of the software edition.

If you start a discussion about requirements every component should support the other two. Or at least support it in a fantastic future. ^^ As far as I know, the establishing of the Wordpress environment took years of development, with many backlashes. But we need something in this direction. Hallo Welt! plans to start working on a solution for the last two components at least for our customers (see slide 12 here: http://de.slideshare.net/bluespice/bluespice-goes-semantics-smwcon-2015), but if there's a MediaWiki native solution possible, we would support to develop this as far as possible. Or we can open our develpment. For us it's only important, that the solution is reliable, usable by ordinary customers and based on non-exotic technologies.

@ZaBien A hangout session could discuss your feature list. In a second step we could add ideas for solutions and a first estimation of efforts?

In T118188#1796177, @RichardHeigl wrote:

@ZaBien A hangout session could discuss your feature list. In a second step we could add ideas for solutions and a first estimation of efforts?

I would love to do this. Can we have a collaborative session next Tuesday?

Also see T117550: [RFC] Content bundler. The store should support distribution of content bundles.

In T118188#1794523, @ZaBien wrote:

Feature ideas:
see also Magento Connect and WordPress plugins

• New rating system for extensions: 1–5 stars for e.g. "Usefulness, Functions as Described, Developer Support"
• New statistics: Most wanted extensions, most downloaded extensions, most highly rated extensions (total, average, percentage)
• Popularity score: The download statistics visualized in an icon with 5 versions.
• User text reviews with commenting functionality – extended talk page?
• Follow this extension – via watchlist, but also via email, RSS/Atom
• Developer info – Contact possibilities and preferences (email, talk page etc.) – template that lets developers include a nice list of their extensions on their user page, statistics about the developer
• Compatibility: "Tested with" – extended compatibility notes – "requires 1.21.x, compatible up to 1.25.3" (see WordPress!) –  what has been tested, what is supported and what is assumed – also "intercompatibility", compatibility between extensions
• Enhancement of screenshots and use case examples – extend the existing "Example"
• Short screencasts
• Extended usage information beyond technical settings.

• Link to WikiApiary

Re: Rating (pls only 3 stars in future), most parts of usage statistics, popularity, (text review) is actually already there at Wikipiary which is also already linked from every extension at mw.o - perhaps this needs to be fluffed up further and we need a way to sync this info into wm.o directly (a prototype is somethere in the water, too) the biggest issue here is to get compatibility info which is also teased by Wikiapiary though at a high performance burden.

@kbhbln, thank you! Very valuable. We'll take this draft as a discussion basis for tomorrow's Hangout and will report first outcomes.

I haven't had the chance to read through all of this yet, but:

there are no statistics of most wanted or downloaded extensions available.

We now have statistics of most downloaded extensions through ExtensionDistributor at https://grafana.wikimedia.org/dashboard/db/extension-distributor-downloads and a top 10 list will be shown on the Special:ExtensionDistributor web interface once the Wikimedia deployment freeze is over (probably January).

Can we use the extension.json metadata to fill out more of these template goodies automatically? Less manual work is usually good.

Which reminds me we need much better documentation on how to create and maintain an extension.json file...

brion writes:

Can we use the extension.json metadata to fill out more of these
template goodies automatically?

+1

Which reminds me we need much better documentation on how to create
and maintain an extension.json file...

What do you think it should cover that it doesn't already?

In T118188#2233425, @MarkAHershberger wrote:

brion writes:

Which reminds me we need much better documentation on how to create
and maintain an extension.json file...

What do you think it should cover that it doesn't already?

How to write one from scratch, what all the keys mean... :)

How to write one from scratch, what all the keys mean... :)

Which should be part of "How to write an extension".

I'd suggest we create a bootstrap script to aid in this. It could use the Example extension to start and, maybe, do wizard-like configuration to help a developer understand what to do.

In T118188#2233451, @MarkAHershberger wrote:

How to write one from scratch, what all the keys mean... :)

Which should be part of "How to write an extension".
I'd suggest we create a bootstrap script to aid in this. It could use the Example extension to start and, maybe, do wizard-like configuration to help a developer understand what to do.

@Mooeypoo started such a tool at the Jerusalem hackathon: https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2016/Showcase#MWStew:_MediaWiki_extension_boilerplate_maker

In T118188#2233477, @brion wrote:

In T118188#2233451, @MarkAHershberger wrote:

How to write one from scratch, what all the keys mean... :)

Which should be part of "How to write an extension".
I'd suggest we create a bootstrap script to aid in this. It could use the Example extension to start and, maybe, do wizard-like configuration to help a developer understand what to do.

@Mooeypoo started such a tool at the Jerusalem hackathon: https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2016/Showcase#MWStew:_MediaWiki_extension_boilerplate_maker

Yep, and the code is in Github: https://github.com/mooeypoo/MWStew

The tool is live on tool labs, too: http://tools.wmflabs.org/mwstew/

There are already a bunch of issues - some of them feature requests, and some minor bugs - and I could really use bug testing and more feature requests, as well as help in filling in more hook templates, which is a really tedious job of mainly copy/pasting (while taking into account the function naming... if anyone wants to do that, I'll lay out the method so we can get more hooks available)

If you have ideas, please feel free to add them in to the issues, test the tool, and participate with pull requests!

In T118188#2233426, @brion wrote:

In T118188#2233425, @MarkAHershberger wrote:

brion writes:

Which reminds me we need much better documentation on how to create
and maintain an extension.json file...

What do you think it should cover that it doesn't already?

How to write one from scratch, what all the keys mean... :)

+1! Yes, exactly.

A script is great, and I'm looking forward to looking at the one @Mooeypoo wrote, but that's not a replacement for good documentation. When I began the extension upgrade process, I wanted to know what the set of keys I could use was. The conversion script did a great job of taking the existing code and building extension.json, but I wanted to know if there was anything it might have missed or if there was anything else cool that I could specify. I could not find that documented anywhere.

In T118188#2234874, @cicalese wrote:

A script is great, and I'm looking forward to looking at the one @Mooeypoo wrote, but that's not a replacement for good documentation. When I began the extension upgrade process, I wanted to know what the set of keys I could use was. The conversion script did a great job of taking the existing code and building extension.json, but I wanted to know if there was anything it might have missed or if there was anything else cool that I could specify. I could not find that documented anywhere.

Yeah, the documentation in general is not really very good, and not just with extension.json. The tool I wrote isn't solving that specific issue; it's more to make the boilerplate automatic (you pick your basic preferences for your new extension, and you end up downloading a .zip file with all the base files where you can start work)

For what it's worth, there's a documentation for extension.json key/values in https://phabricator.wikimedia.org/diffusion/MW/browse/master/docs/extension.schema.json

In general, however, I think we need to consider that there should be a difference between "technical documentation" (which the extension.schema.json answers) and documentation for new developers (which it doesn't). I personally would like to see more step-by-step tutorials and more down-to-earth practical explanations for new developers that supplement the masses of purely technical documentation that we have.

There's a reason why most other open source tools out there have graphical tutorials for "newbies" with step-by-step instructions starting from the most basic level. These tend to be what new developers look for (whether they are completely new or have experience in other development environments online)

OOjs-UI was attempting to do this with its (currenly still lacking) documentation, I think it can be great if we work on similar efforts (plus tutorials?) for how to create extensions from scratch -- or how to work with specific aspects of development, like how to work with hooks or how to work with proper translations, right-to-left, etc.

Adding @Osnard, as he has worked on a concept for an extension store at Hallo Welt! and might have valuabe contributions.

Random notes from a meeting about extension store at Wikimania 2016

• @Osnard
  • Pick well known extensions, then mwstake makes sure these extensions work with a particular version of mw.
  • create packages from these extensions, zip archive, add manifest, for installation/activation/configuration process
  • have a base class for standard operations in php, which can be overwritten by the package
  • SMW installaton as repository for everyone who wants to consume this. We are experienced with this. MW brings a lot of features, like versioning, history, etc.; description pages, api endpoint to communicate with the client
  • client is a standalone application
  • write some kind of managed confguration file
• @Legoktm
  • we need to push the new extension.json registration for developers. Possible means are: new stuff is only available for extensions with extension.json. Also, availability in an extension store could be an option.
  • 3 main aspects: discovery, installation, updating
  • discovery: portal page, list of popular extensions, tag search, search, etc.
    • compatiblity information in extension.json, but also feedback through users
    • has to be on mw.org, for legitimacy
    • SMW not so good, but custom extension
    • Integrated in extension distributor
  • installation: extension distributor or git as a source to download extensions
    • extension distributor should move from labs to production
    • command line script on mw: download extension, remember which ones it downloaded
    • we can move to web interface later
    • problem: rollback. But this is possible via extension.json, e.g we can disable extensions in the updater
• Make it pluggable, e.g. package system of Robert, or github extensions
• PHP vs. extension.json: json is just declarative, php does not needs be related to the wiki
• Problem is security: never run php code until the script says so. Look at the data without executing code
• new patch to extension.json: configuration can be declared
• idea: backing extension discovery with wikidata
• ACTION: Create a list of subtasks, small steps to work on
• Have an advocate within the WMF (e.g. Legoktm)
• Make it pluggable, maybe different stores, different sources etc.
• Discovery: create lists from extension distributor, create manually list and add them to extension distributor
• ExtensionDistributor is a extension. and there's a python script on labs.
• issues: Versioning, e.g. based on tags. But there is no good testing infrastructure
• idea: store stable version in wikidata. but security issues might arise as everyone can change the information
• in the commandline script have a list of approved repositories

Note from above meeting: we need a way to use extension.json to specify what needs to be configured before the extension's installation can be finalized.

I wrote a very simple POC for the command line tool to enable/disable/fetch/update extensions that I proposed earlier: https://gerrit.wikimedia.org/r/308891

Thank you Legoktm! I've just had a quick look at the code (did not test it yet) and it looks very promising.

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

I think at this point we just need someone to lead the implementation, there's not much left for discussion.

Some discussion currently happening around the WordPress plugin developers' interface: https://make.wordpress.org/plugins/2017/11/06/concept-a-developer-dashboard/ (just for interest's sake).

See also T155029: MediaWiki.org: Generate infoboxes from extension.json in git (which is in need of a data store to drop information extracted from extension.json etc. into)

Some overlap with T115650: Create an authoritative and well promoted catalog of Wikimedia tools.

For more recent developments see T199372: Use stakeholder feedback to develop a plan for extension management (TEC13).