On 3 Apr 2011 at 10:56, Brion Vibber wrote:
(Breaking this out from 'Focus on sister
projects' thread.)
I just want to give an official shout out, as Lead Software Architect for
the Wikimedia Foundation, that Wikipedia's sister projects are important and
that they need more love. Not only are they directly useful and interesting
in various ways, but their explorations of additional subject areas, media,
and organization styles is something that needs more attention as Wikimedia
looks to its future beyond Wikipedia's first decade. The next decade can't
just be ten years of doing the same things...
Historically it's been difficult to get enough attention for review &
deployment of special-purpose extensions for those projects, so I'm highly
interested in proposals that will help put more flexibility and power into
the hands of their own motivated contributors: from easier
self-configuration of sites to new plugin architectures that allow the use
of new creative media tools without the explicit intervention of Wikimedia
staff.
In particular, I think there's some low-hanging fruit in the Gadgets system.
Right now it's honestly pretty awkward to create a Gadget in the first
place, and sharing code modules between wikis requires a lot of
cut-and-pasting (which leads to divergent code bases, which makes
maintenance nigh-impossible in the face of MediaWiki framework changes).
Some things that would be very spiffy, and probably not that hard:
* Provide a nice interface rather than forcing manual editing of MediaWiki:
namespace message pages
* Self-publishing: be able to do your user JS/CSS in modular Gadget-form,
with easy sharing to other users. Don't require manual work to move
something from 'my own custom JS' ro 'a user .js file that other people can
use' to 'a Gadget that anyone can select in preferences'.
* Cross-wiki gadget sharing: if we can avoid fragmenting common scripts,
they'll be easier to maintain.
Harder, but very interesting in the medium to long-term:
* Security model for safe code sharing: we could devise an explicitly
limited interface between the wiki page JS and gadgets hosted in an offsite
iframe. A foreign gadget could add certain UI elements (tabs, toolbar
buttons) to be triggered, and could open as an embedded view to provide
things like image editing, drag-n-drop category rearrangement, custom
visualizations or interactive diagrams.
Some commentary.
For WS projects, ThomasV has been utilising this model for his proofread page schema.
Most of his javascript is placed in
http://wikisource.org/wiki/Mediawiki... and the local
stuff would be local customisations for language, eg. field names
I would hope that as a model that this can be used, so that the guts of a script can be
separated from the labelling.
With regard to calling gadgets from elsewhere, often the issue is
1) which server, there is so much variability, and many started at WP.
2) knowing what available on servers, and this is a documentation issue. Trying to find
available scripts on TS is just as problematic.
Regards, Andrew