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:073  + (Inter project event propagaton and storage updates make it difficult to efficiently display and update caches for renders that contain data from different proejcts)
• Issue:030  + (Investment in native device products has a questionable return on investment vs a single responsive, progressively enhanced, device and vendor agnostic web experience)
• Issue:066  + (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?)
• Outcome 5 (ARCHIVED)  + (It is easier to install, update, deploy, and configure our development, testing, and production environments as well as simple third-party instances of our technology stack)
• Issue:075  + (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)
• Issue:023  + (It should be possible to define and render UI components on the client and server without expertise of two distinct languages and stacks.)
• Issue:017  + (It should be possible to support page composition at the network edge without requiring that ordinary page design changes require source code edits across a service/language boundary)
• Issue:011  + (Lack of clarity around what functionality and features are specific to the wikimedia usage and what is generic for all mediawiki users)
• Issue:072  + (Lack of clarity of whether the product is MediWiki or wikipedia is bringing the lack of clarity in the whole architecture)
• Issue:071  + (Lack of environment to quickly prototype/test MVPs without going through the full burden of deploying an experimental feature to production)
• Issue:070  + (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)
• Issue:058  + (MediaWiki has a mature staging system (beta cluster, X-Wikimedia-Debug etc), the integration of other services with that system is often lacking)
• Issue:040  + (Metrics/dashboards around project quality (instead of just quanitity))
• Issue:005  + (MobileFrontend does not faithfully display all content as the desktop experience does)
• Outcome 2 (ARCHIVED)  + (More of the full functionality of MediaWiki can be delivered across all interfaces, devices, and form factors while maintaining usability, accessibility, and internationalization standards)
• Issue:079  + (Our (MariaDB SQL and Cassandra NoSQL) databases will run out of storage or suffer performance or integrity problems if we continue adding application enhancements)
• Issue:078  + (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)
• Issue:080  + (Our event logging data stores may run out of space if event logging load increases non-linearly)
• Identify features that the REST API needs to support  + (Perform Product and IA analysis to identify which workflows and features to build REST APIs (and PHP APIs) to prioritize first as needed we work to expose more of the full functionality of MediaWiki APIs.)
• Create a multi-purpose key/value storage component  + (Profiting from the RESTBase split, create a multi-DC storage component that can serve multiple needs inside Wikimedia's production environment. Use cases include, but are not limited to, Parsoid storage, MCS and others.)
• Prototype and test PHP implementation of Parsoid  + (Prototype portions of Parsoid in PHP or a PHP-extension supported language to inform parser unification effort)
• Prototype page assembly  + (Prototype the ability to assemble a page containing both non-personalized and personalized content.)
• Output 2.1  + (REST API for MediaWiki)
• Issue:050  + (REST routing could be reimplemented in Med … 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)category, not just analytics-focused ones))
• Issue:054  + (Readers teams rely on various core functionality but do not take up the burden of maintaining it)

• Refactor Parsoid to support porting  + (Refactor Parsoid to facilitate future port or integration efforts)

• Research 3rd party installations, uses, and contributions (ARCHIVED)  + (Research 3rd party installations to better understand their environments in order prioritize what types of environments and installations to prioritize. Important dimensions to understand include: Bare metal, VPS, Shared hosting, LAMP and LAMx.)
• Define the default MediaWiki installation (ARCHIVED)  + (Research and define what a "default" 3rd party installation would be to support. This enables us to better define the work to make installations easier for all parties.)
• Research Desktop Workflows to port to Mobile and/or Responsive (ARCHIVED)  + (Research desktop workflows to identify and prioritize workflows to move to mobile. Decide if making Desktop responsive is feasible or if another approach must be taken.)
• Issue:082  + (Resourcing of service development is now augmented by front end engineers, which natuarlly gravitate towards JS. Moving to pure PHP is possible, but that would mean a responsibility shift back tot tech for APIs OR a change in hiring strategy for audiences)
• Simplify the RESTBase stack  + (Separate the routing and storage components of RESTBase into two services)
• Outcome 4 (ARCHIVED)  + (Session management system is isolated from the rest of the platform)
• Improve installation and deployments of the "WMF Technology stack" for WMF development testing and production environments (ARCHIVED)  + (Standardize on the use of containers and K … Standardize on the use of containers and Kubernetes for deployment of new services, use containers/minikube to make it possible to reproduce the production service ecosystem locally for developers. Create documentation to introduce developers to this new stack.to introduce developers to this new stack.)
• Research architecture requirements and needs, identify and resolve trade-offs  + (Starting from user stories and work flows, … Starting from user stories and work flows, identify requirements. Based on available technology and resources, identify constraints. Present trade-offs to PMs and C-Level management for resolution. NOTE: This informs the re-design and refactoring of the API layer, MW core, as well as auxilliary aspects such as Varnish, RESTbase, and EventBus.s such as Varnish, RESTbase, and EventBus.)
• Output 4.1  + (The key/value storage component has a well-defined API)
• Output 4.2  + (The key/value storage component is isolated from RESTBase as a stand-alone component)
• Issue:043  + (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)
• Issue:045  + (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)
• Output 4.3  + (The session service has a well-defined API that can serve use cases and be plugged into MediaWiki)
• Output 4.4  + (The session service is deployed in production)
• Issue:015  + (The third-party community needs to be involved in the development of installation/deployment strategies targeting their environments to be sure that solutions fit the problem)
• Issue:018  + (Third party community keeps asking for composer for extensions deployment; we should agree on a mechanism that meets their needs but does not bring composer's issues re: extension management)
• Issue:036  + (Third-parties should be able to reference and use Wikidata in the same way they can reference and use Commons)
• Issue:025  + (Too many Readers technical and product initiatives (e.g., the native apps, marvin, MCS to some extent) do not have much (or any) Technology department buy-in.)
• Output 1.4  + (Unified Parser)
• Standardize on a single parser  + (Unify Parsers into one implementation, deprecating the existing PHP parser.)
• Issue:077  + (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))
• Outcome 3 (ARCHIVED)  + (WMF and volunteer engineers and developers are more effectively onboarded using new and improved documentation that is clear, complete, and cohesive)
• Issue:027  + (We don't have a cohesive engineering culture.)
• Issue:028  + (We don't have any consensus on whether it's valid or valuable for WMF to build user-facing products that are not MediaWiki)
• Issue:007  + (We have duplicated functionality in core and in services (ex: title handling code, parser tests syncing, some parts of lang. variant support))