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).

* Cross-wiki gadget sharing: if we can avoid fragmenting common scripts, they'll be easier to maintain.

(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.