Property:Description
From atwg
0
lack of clarity on the status of various projects which have been tagged as RfCs but never had an official decree or discussion +
lack of clarity around new frontend plans (e.g. how will the desktop look and who will maintain it?) +
developer tooling of MediaWiki is underresourced; developer tooling of most other things is pretty much nonexistent +
APIs are about interfaces not languages, so build a REST interface in PHP and use Cassandra if needed, but make a cache-able, powerful API that slices the data according to every use case (probably "common" rather than "every". Universailty is a long tail of things) +
Archivability of our projects as they evolve: do we continue to rely on archive.org storing rendered pages? What's the age cutoff for maintaining an editable source representation? Will we ever solve the "rendering an old page with new templates" problem? (Another way of stating the problem: "how do you render old revisions in the face of changes to wikitext and templates--and what tooling do we need around that issue?") +
Is "one linear chain of revisions" the history and future of the platform, or will we eventually need to add branches/fork/merge (or somethine else) to core? What about collaborative real-time edits w/ finer-grained multi-user edit histories? +
How are media integrated in our platform: can we do something better for page layout than what we've got? Can we better support non-wikitext content? (cf https://wikimania2016.wikimedia.org/wiki/Discussions/Rethinking_the_layout_of_Wikipedia_articles https://phabricator.wikimedia.org/T90914#2918931 etc) +
Can we lower the "template editing"/"module editing" wall between editors and "power users"? Are there "simple templates" we could edit/author in Visual Editor? (cf https://phabricator.wikimedia.org/T114454 for one idea) +
General theme: enhancing commonality while improving shared functionality and enabling innovation & experiments across various device form factors (desktop / laptop / tablet / smart phone / dumb phone; online, intermittently online, offline) for both content consumption and creation +
Lack of strong module boundaries in MediaWiki - anything can access anything, the skins are highly intervened with the internals making it hard to use modern frontend tech with clear division between backend/frontend code +
Lack of environment to quickly prototype/test MVPs without going through the full burden of deploying an experimental feature to production +
Lack of clarity of whether the product is MediWiki or wikipedia is bringing the lack of clarity in the whole architecture +
Inter project event propagaton and storage updates make it difficult to efficiently display and update caches for renders that contain data from different proejcts +
Wikidata queries (especially location based ones) take much to long to execute for end user cleints to use them +
It is hard to see dependencies in phabricator and discus as different people/teams create task trees differently and there is no way to actually mark a task as blocked by another. i.e. phab is conflating substasks with dependencies +
We need better dependency tracking and updating/purging artifacts when needed. Links tables and the job queue don't scale, especially not for scacading updates. For a rough idea of what that could look like, see https://www.mediawiki.org/wiki/User:Daniel_Kinzler_(WMDE)/DependencyEngine +
Using modern isomorphic JS technology (e.g. React) or similar things is hard with our stack. More and more web development happens in JS/node, so that's where all the modern tooling is (and what new hires are used to working with) +
Our edge caches will run out of hot storage if we have an increasing set of finer grained and customized API and page responses with quick response time requirements +
