Prior to the 2018 Developer Summit SJ asked me what my most optimistic outcome of the summit would be. I came up with a shortlist of four projects I felt were important for the WMF to resource; in conversation with SJ and Tim we added a few more. I came up with a little acronym to help me remember them all when pitching the ideas at the dev summit; the ordering below reflects that acronym, not any particular priority. For each "dream" I've added a specific product idea that would motivate development, as well as some alternates. I've also given a brief thumbnail of the infrastructure which the dream would use, demonstrating some of the architectural synergies which mitigate on-going maintenance costs.
Core database support for branched revisions; a canonical way to store a revision which is not immediately visible on the site, or is an edit relative to a revision which is not the currently-visible revision. Improved tools for merging a branched revision. (Read more.)
Product: Improving the Draft Namespace
Alternates: Improving the edit conflict experience, Avoiding Newcomer Reverts (Roadmap: Onboarding), Session checkpointing during edits
Technologies: Merge Tools, Fork Storage
Roadmap: Retaining contributors, better contributions
Bridge the language barriers between wikis so we can work as one project. Global user talk, multilingual chat, edit suggestions across languages. (Read more.)
Product: Translated Edit Suggestions (Roadmap: Global)
Alternates: Split screen UX, Multilingual chat
Technologies: Unified backend database, Improved Language Tagging, Parallel Text Annotations
Roadmap: more diverse languages, more productive contributions
A beautiful MediaWiki install experience that includes OAuth (from M/T/G/D) and spam control out of the box; with a way to notify those users of new updates and features. This guarantees more devs and testers of any branch/fork/offlining.
Product: (Roadmap: Community)
Alternates:
Technologies:
Improve Visual Editor to allow real-time collaboration. Help wiki editors spend less time off-wiki on Etherpad, Google Docs. (Read more.)
Product: Teahouse Mentoring (Roadmap: Onboarding)
Alternates: Wikinews, Internal dogfooding
Technologies: Visual Editor, Fine-grained blame maps, Collaborative session storage
Roadmap: Better contributions
Separate queue for merging offline edits, with an effort to get edits back from disconnected communities and to allow Tor edits from repressed communities; enhanced attention to sneakernet distributions of the wikis. Partly resolved by any merge/fork framework.
Product: Allowing Peruvian Schoolkids to edit offline (Roadmap: Global)
Alternates: Enabling edits from Tor (Roadmap: Resiliency)
Technologies: Merge Tools, Fork Storage, Queue UX
Roadmap: Local language content, Mobile editing, More diverse capabilities and geographies
Provide good UX for tracking exactly what parts of an article were modified by a particular user. An authorship map is checkpointed every N revisions, but intermediate maps are put in ephemeral storage since they can be recomputed on-demand. These can also be used to compute trust scores or edit quality, based on how long-lived the replaced text was, or how long-lived a particular editor's contributions were. (UX mockup.)
Product: Tracking Fake News
Alternates: Uncovering hoaxers, Trust computation, ORES feature improvement
Technologies: (Tree Structured?) Blame Maps, MCR
Build a way to let any WikiProject identify a set of articles & a set of microtasks, and design banners to encourage readers to edit those articles. Show those articles to a small # of readers who visit those articles, and help the wikiproject follow up with readers who act on the banners. Track cohorts of new editors brought in by each wikiproject (who are naturally motivated to follow up).
Product: Banner A/B testing for WikiProjects
Alternates:
Technologies: A/B test harness, Banner toolchain
Make it possible to embed discussions, or summaries of them, inline in content pages. Especially useful when a discussion is critical to understanding current content or lack thereof; for instance anywhere that currently has a section-level cleanup template.
Roadmap: Communications
Store Parsoid-format markup in MCR; fetch only the markup needed for a specific *paragraph* (or other fine-grained unit) when editing is started. Integrate fast subtree-extraction code (originally from restbase).