Statement:52: Difference between revisions
No edit summary |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 3: | Line 3: | ||
|lastname=Vibber | |lastname=Vibber | ||
|tags=Gadgets, Templates, API, JavaScript, Security, Tools, Mobile | |tags=Gadgets, Templates, API, JavaScript, Security, Tools, Mobile | ||
|primarysession=Session: | |primarysession=Session:2 | ||
|statement=Infrastructure for Open: Safe code sharing in the Wikiverse | |statement=Infrastructure for Open: Safe code sharing in the Wikiverse | ||
Latest revision as of 11:01, 14 December 2017
| Tags | API, Gadgets, JavaScript, Mobile, Security, Templates, Tools |
|---|---|
| Primary Session | Evolving the MediaWiki Architecture |
| Secondary Sessions |
Infrastructure for Open: Safe code sharing in the Wikiverse
Wikipedia has always been a place where people build things, starting with MediaWiki itself... Talk pages were created out of formatting conventions manually followed. Templates and Lua modules grew out of users' need to automate common markup & text blocks. Gadgets came about to let users add new capabilities to their experience.
To scale our users' ability to work, we need to build modern infrastructure and APIs for on-wiki code: templates, gadgets, and custom workflows.
First, gadgets and templates need to be maintainable and sharable in a centralized place; copy-pasting doesn't scale. Integrate with "real developer" tools like git, so complex tools can be edited and archived off-wiki.
Second, they need to be safer and more future-proof. Template & module output is in wikitext, a fragile format; consider separating sanitized "true" templates from the data sources.
JS gadgets can access internal or deprecated APIs that may break ... or hijack a session as malware! We should create narrower APIs and run the gadgets in isolated JS contexts to provide fault isolation -- this would also enable using them in different contexts such as mobile apps, by implementing the same interfaces.
Third, we need to make content "smarter" by giving it the ability to run interactive scripts safely -- a mix of what templates/modules and what gadgets can do. This can be used to make animated widgets for article pages, but more importantly could be used to implement discussion & editing workflows to supplement what you can do with just a talk page and a set of conventions. At a minimum, think of what people do with Google Forms to guide input, and let folks do that on-wiki.
On-wiki tool-building is a "force multiplier" that lets people get more done by organizing themselves. Providing better tools for tool builders will lead to happier, more productive users working for our mission.
