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: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)