Search by property

This page provides a simple browsing interface for finding entities described by a property and a named value. Other available search interfaces include the page property search, and the ask query builder.

List of results

• Issue:019  + (We need a mechanism for delivering assets (JS, CSS, templates) that generates the asset graph and bundles from the source code itself, rather than one defined and maintained by hand alongside it.)
• Issue:022  + (We need a system for capturing analytics events that doesn't require synchronisation with Analytics Engineering. (see also: https://wikitech.wikimedia.org/wiki/User:Ottomata/Stream_Data_Platform))
• Issue:021  + (We need a system for defining and running A/B tests that run in isolation from those defined by other teams and that don't require source code edits to initiate.)
• Issue:039  + (We need an asset delivery system that is easy to use for developers. Generating the asset graph from the source code would help with this, but build steps could hurt this unless care is taken to make it transparent.)
• Issue:076  + (We need better dependency tracking and upd … 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)/DependencyEngineser:Daniel_Kinzler_(WMDE)/DependencyEngine)
• Issue:031  + (We need consistent localization practices, well-integrated with translatewiki and our other language infrastructure)
• Issue:013  + (We need to agree on what constitutes the MediaWiki core platform and if there are additional optional bundles of important functionality)
• Issue:032  + (We need to erode the hard barriers between template, lua module, gadget, extension, skin, and core code to make it easier to develop and deploy code written by the community)
• Issue:024  + (We need to maintain a services stack that is independent of mediawiki to deliver data that is not mediawiki related)
• Issue:033  + (We need to reduce our dependence on WMF-proprietary wikitext and allow non-WMF wikis to use whatever markup they prefer (this is a controversial opinion, I know))
• Issue:034  + (We need to reduce our dependence on wikitext and better accomodate non-textual content)
• Issue:044  + (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)
• Issue:081  + (We will run out of disk space if there's explosive growth in large files)
• Issue:083  + (What responsibility do we have for the security of our platform? For protecting the privacy of our users?)
• Issue:074  + (Wikidata queries (especially location based ones) take much to long to execute for end user cleints to use them)
• Issue:010  + (Wikitext parsing is tightly entangled with a lot of core code)
• Output 1.1  + (architecture for the flow of control and information from the user down to the database and back)
• Output 3.2  + (architecture pages on developer portal)
• Issue:046  + (by overusing services, we are shifting a pre-existing language barrier from the edge of the server stack to the middle)
• Output 3.3  + (coding standards pages on developer portal)
• Output 5.3 (ARCHIVED)  + (decision on supporting shared hosting)

• Output 3.1  + (developer documentation portal)

• Issue:063  + (developer tooling of MediaWiki is underresourced; developer tooling of most other things is pretty much nonexistent)
• Output 5.1 (ARCHIVED)  + (easy installation, update, and deployment of MediaWiki)
• Output 5.2 (ARCHIVED)  + (easy installation, update, and deployment of the full technology stack)
• Output 2.3 (ARCHIVED)  + (full featured workflows on mobile form factors)
• Issue:057  + (having multiple systems with different deploy cadence (apps, MW core, services) works fine for greenfield development but increases coordination costs of maintenance)
• Issue:061  + (lack of clarity around new frontend plans (e.g. how will the desktop look and who will maintain it?))
• Issue:060  + (lack of clarity on the status of various projects which have been tagged as RfCs but never had an official decree or discussion)
• Issue:048  + (lack of feature parity and widespread adoption in services means we are forced to maintain both the MediaWiki and the service version)
• Issue:055  + (making MediaWiki less useful for third parties cannibalizes our ability to attract volunteer developers, yet this consideration is routinely ignored)
• Issue:059  + (mismatch between TechCom definition of when an RfC is needed (strategic/cross-cutting/hard to undo) and how some Audiences teams interpret it (no RfC if the technical changes are not large, even if it has a serious strategic impact))
• Issue:062  + (mismatch between how Technology and Readers understands the role of RESTBase)
• Output 1.2  + (modularized MediaWiki)
• Output 1.3  + (modularized RESTBase)
• Output 2.2  + (personalized and non-personalized content can be assembled into a page outside of the MediaWiki application)
• Issue:052  + (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)
• Issue:053  + (resourcing of the various interfaces is not commensurate with their actual usage)
• Issue:047  + (services complicate the installation process, both for developers and for third parties)
• Issue:049  + (services result in duplicated infrastructure which results in increased server spending)
• Issue:056  + (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)
• Issue:051  + (we should investigate how to better integrate Parsoid with PHP, to reduce system boundaries +1)