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: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))
• Issue:014  + (We need a Roadmap for the MediaWiki core platform and any important optional functionality)
• Issue:037  + (We need a better "innovation" process that lets teams create MVPs of disruptive products (ie, the mobile app experience, services, new skins, machine learning, etc) without creating long-lived splits and silos)
• Issue:016  + (We need a better contract/set of expectati … We need a better contract/set of expectations w/ third-party community, so we have a coherent lifecycle from "started by third-party" -> "adopted by WMF" -> "deprecated by WMF" -> "maintained by third-party" -> end-of-life (cf Semantic MediaWiki, PDF export, etc); end-of-life (cf Semantic MediaWiki, PDF export, etc))
• Issue:020  + (We need a build system that supports pre-compilation of assets (JS, CSS, templates) during integration rather than immediately prior to delivery in order to support modern tooling.)
• Issue:004  + (We need a coherent, understandable set of documented APIs for our own projects and 3rd party API consumers (an example: https://developer.github.com ))
• Issue:006  + (We need a generic storage for long term storage of content other than article renders (feed content, edits-in-process, collaborative sessions, translations, annotations, conflict resolution, media, archival renders of pages, etc))
• Issue:038  + (We need a larger more independent community of developers (currently 78% commits over past two years from WMF/WMF-DE; compared to eg 10% employee committs for Automattic))
• 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)