Property:Description
From atwg
0
Identify owners for critical core features and extensions that are orphans (e.g. AbuseFilter) +
The mobile web site should be as good as or better than the app; right now the app is much better, and I use the app because the mobile web site drives me up the wall +
We should make page composition faster, either at the network edge or in a Service Worker, this would make reading (logged-out and especially logged-in) much faster +
The multi-DC project should become a serious priority. It's basically had only 1 person work on it for the past year or two, and we're still pretty far away from being able to run active/active +
by overusing services, we are shifting a pre-existing language barrier from the edge of the server stack to the middle +
lack of feature parity and widespread adoption in services means we are forced to maintain both the MediaWiki and the service version +
REST routing could be reimplemented in MediaWiki, reducing configuration complexity, network overhead and language boundaries (see line 50, many users of services do not use anything mw related) (which services would those be? The only one I can think of is pageviews. No, we have several services: pageviews, contributors, edits , unique devices: https://wikitech.wikimedia.org/wiki/Analytics/Systems/AQS#Hosted_API , also any service that would manage meta-data (ex: reading lists) would fit this category, not just analytics-focused ones) +
we should investigate how to better integrate Parsoid with PHP, to reduce system boundaries +1 +
replacing Cassandra with ParserCache and moving the changeprop mechanism into MediaWiki would significantly reduce server costs and the functionality would be useful for many third-party extensions +
Readers teams rely on various core functionality but do not take up the burden of maintaining it +
making MediaWiki less useful for third parties cannibalizes our ability to attract volunteer developers, yet this consideration is routinely ignored +
to preserve coherence as a software framework, services should extend from MediaWiki (e.g. have a REST router in core then override it with an external service where it makes sense), not live in a parallel dimension +
having multiple systems with different deploy cadence (apps, MW core, services) works fine for greenfield development but increases coordination costs of maintenance +
MediaWiki has a mature staging system (beta cluster, X-Wikimedia-Debug etc), the integration of other services with that system is often lacking +
