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

• Output 3.4  + (API pages on developer portal)

• Issue:064  + (APIs are about interfaces not languages, s … 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)y". Universailty is a long tail of things))
• Issue:065  + (Archivability of our projects as they evol … 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?")at tooling do we need around that issue?"))
• Issue:041  + (Better collaboration with Google (especially around Google API usage))
• Issue:068  + (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))
• Issue:029  + (Certain longstanding MediaWiki technical guildelines (that it run in a shared hosting environment, that it not require JavaScript) are too conservative and are seriously impeding modernization effort)
• Issue:012  + (Code modularity (good) gets confused with "optional features" or even "unmaintained community features", since the same mechanisms are used (ie, pushback against unbundling the parser "for greater modularity" since "it's not an optional feature"))
• Issue:008  + (Configuration complexity: Installation and deployment of mediawiki + services requires a lot of different configuration files to be managed (sometimes with duplication, ex: sitematrix code in parsoid and in core))
• Isolate session data by creating a specialised session service  + (Create a session storage service that uses the storage component and isolate it from the rest of the system using a simple API, and make it easily available from MediaWiki)
• Create a purpose built developer portal for documentation  + (Design and Implement a developer portal to host and centralize documentation for our technology.)
• Design MediaWiki REST API  + (Design and prototype a REST API that would … Design and prototype a REST API that would enable the full functionality of the desktop web experience in MediaWiki Core (and "critical" extensions?) with cacheability and consistent parameters, property names and objects. Note that this highly depends on the overall design of information flow (see [[Output:1.1]])[[Output:1.1]]))
• Develop, publish and implement Code Standards that align with our new priorities around APIs, encapsulation and global state  + (Develop and implement coding standards tha … Develop and implement coding standards that inform and enforce 1. better encapsulation with the creation of public PHP APIs and REST APIs to expose functionality 2. the use of the Service Container. 3. librarization for components that are likely to be extracted to services for scaling needs of the WMFd to services for scaling needs of the WMF)
• Document system architecture, lifecycles, etc. on developer portal  + (Document "mid-level" items that explain how our systems work. This provides an overview of systems and architecture with diagrams and workflows along with links to low level documentation)
• Document MediaWiki REST API on portal  + (Document REST API along with responses, specs, examples and prose explaining use cases and workflows)
• Document MediaWiki PHP service interface on portal  + (Document internal PHP service interrface along with responses, specs, examples and prose explaining use cases and workflows)
• Make REST Routing possible in MediaWiki  + (Enable PHP based routing of URLs in MediaW … Enable PHP based routing of URLs in MediaWiki to enable REST along with an easy way for developers to specify caching and purging semantics. The routing should be fast and preferably not require all of MediaWiki to be loaded in order to start. Routing patterns should be standard both in and outside of MW. This should be transparent to clients.MW. This should be transparent to clients.)
• Issue:069  + (General theme: enhancing commonality while … 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 creationine) for both content consumption and creation)
• Issue:009  + (Healthy extension ecosystem has the unfortunate side-effect that few third-parties are actually running "mediawiki as WMF uses it", and lots of valuable functionality is hidden in overlooked extensions)
• Issue:067  + (How are media integrated in our platform: … 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)bricator.wikimedia.org/T90914#2918931 etc))
• Issue:042  + (Identify owners for critical core features and extensions that are orphans (e.g. AbuseFilter))
• Issue:035  + (If we are investing time in native apps, non-WMF users should be able/encouraged to customize & use those apps as well. We need community participation in all of our code bases.)
• Improve installation of default MediaWiki for WMF development, testing and production environments as well as 3rd parties (ARCHIVED)  + (Implement fixes needed to support the default installation on for environments based on the 3rd party and default MediaWiki research tasks)
• Develop MediaWiki REST API  + (Implement the REST API incrementally by addressing one feature at a time in core)
• Port Desktop Workflows to Mobile and/or Responsive (ARCHIVED)  + (Implement workflows that respond to both desktop and mobile presentations as identified by research)
• Issue:026  + (In turn, there's an increasing (and unfortunate) tendency for some product teams to self-isolate.)
• Refactor MediaWiki Core into well encapsulated components, removing global state and circular dependencies between classes  + (Incrementallly refactor MediaWiki code int … Incrementallly refactor MediaWiki code into logical classes/components/libraries to isolate functions such as storage, parser, events and app logic. Prioritizing refactoring of code into components to allow: Easier testing (leading to faster development), more easily support both LAMP stack and WMF use cases that require scale and selective SOA, increased re-usability, enabling an API-first approach be de-coupeling the presentation layer. Removing global state also enabled full cross-wiki capability (e.g. loading and rendering content from multiple wikis in a single request). from multiple wikis in a single request).)
• Outcome 1 (ARCHIVED)  + (Infrastructure for Wikimedia projects can be more easily scaled due to increased modularization, re-use, maintainability, and testability of the technology stack)
• 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)