Page MenuHomePhabricator

Develop a long term vision for community managed scripts and gadgets
Open, Needs TriagePublic


It is time we develop a vision on what community based extensions to MediaWiki should look like. Without even having a vision of where we are going, it will be hard to make the right technology choices.

We should index what the current problems are, what the purpose is of us offering the ability to use scripts, what responsibilities are for each of the actors in the system and eventually interesting ideas to improve the overall system, and methodologies to reach that new state, without blowing up the community.

Current problems:

  1. security (who has access and what can you do) T171563: Only allow MediaWiki, Gadget, and User namespace pages to be treated as JS or CSS (no project namespace, etc.)
  2. abandonware (lot of scripts are in use by thousands of people, but not actively maintained/owned)
  3. fragility (the scripts break easily and often)
  4. hard to detect broken scripts
  5. hard to know how extensively used a script is
  6. little reuse across the wiki's T22153: Implement global gadgets (WMF-wide)
  7. revision control (wikipage vs. git)
  8. quality control
    1. T71445: Implement a proper code-review process for MediaWiki JS/CSS pages on Wikimedia sites
    2. T53651: Auto-generated gadget code documentation
    3. T39230: Provide standard way to create/run QUnit tests for Gadgets and user scripts
  9. userscripts execute in global scope T65728: ResourceLoader: User scripts should not execute in global scope
  10. Translations and configuration options are not consistent.

A few problems that I (TheDJ) see that we should consider

  1. It's hard for a script to change owner.
  2. It's hard to deprecate an existing user script
  3. it's too hard to maintain your user scripts. You shouldn't have to know about RL or JS itself even, in order to enable a userscript (this is what made importScript work so well for years).
  4. It should be easier to have a userscript promote to being a gadget, and easier to 'drop' it from the gadgets as well.
  5. We need better frameworks. A language to modify your UI. A consistent API and place for your page extensions, without interfering with the rest of your UI. addportletlink has reached it's limits

Edit as you please.

Event Timeline

See also:

My dream is for user scripts to become a per-user repo of gadgets. Similar to how each wiki has one repo of site-admin maintained gadgets, each user can have such repository. This level of abstraction would solve many problems user scripts have that gadgets has already solved and/or gadgets 2.0 will solve:

  • Compression via combination and minification.
  • Canonical ID separate from page name.
  • Usage tracking.
  • JavaScript execution scope.
  • Easy for users to enable without modifying code. (All they'd do is auto-complete a user name in the Gadget preferences to add that user's repo)
  • Discovery (all local-wiki hosted user repos could be indexed/searchable as machine-readable gadget names+description).

The remaining concerns of Security, Revision control, Quality control, Localisation are hard to address within the wiki platform. But these could be used as a carot for making a gadget a "Global gadget", where "Global gadgets" would be addressed by using our existing development infrastructure instead (Git, Jenkins, Phabricator). Some milestones we crossed since the creation of the Gadgets extension in 2006:

  • Reduced default deployment cycle from 6 months to 1 week.
  • Moved from SVN to Git.
  • Peer review for code. (Gerrit)
  • Place to submitt patches before merging, requiring code review. (Gerrit)
  • Create patches through web interface. (Gerrit)
  • Upload Git patches through web interface, no SSH setup required. (
  • Jenkins for automated running of unit tests and integration testing.
  • Made creation of Git repositories super easy. (Gerrit).
  • Made setting up of Jenkins jobs super easy. (Zuul templates & Jenkins Job Builder templates)
  • Introduced multiple ad-hoc deployment windows, every week day. ("SWAT" /

See also T71445#1459477

A related question is whether scripts/gadgets can be considered a good entry point for new developers. If they are, then Developer-Advocacy could get involved, and connect better gadget projects and maintainers with Featured Projects and the other activities we are organizing to attract new developers.

The main vision-level question IMO is whether we want gadgets which are "familiar" for wiki editors (can be updated by editing a wiki page) or for developers (can be hosted on gerrit/github, with CI). I'm with Krinkle on that, we should provide a path for turning gadgets into proper libraries that get all the tooling support available for JS developers these days.

That would take care of everything apart from error detection (T106915: Use Sentry in production would be the nice solution for that), abandonware (not really a technical problem) and lack of frameworks (T120755: Mobile-friendly framework for multi-column portal and project pages and T155567: Make OOUI easier to use for gadgets are somewhat related).

A related question is whether scripts/gadgets can be considered a good entry point for new developers.

Worked for me. :)

For the records, after the Developer-Advocacy got dissolved I'm not aware of any WMF team for which this would be in scope