Page MenuHomePhabricator

[Goal] Build the Metrics Platform control plane
Open, Needs TriagePublic

Description

Background

As part of the Data Platform Product Vision and Roadmap for FY 23/24, the Metrics Platform Clients will be managed by a control layer UI (heretofore Control Plane) that will enable centralized administration of instrumentation, schemas, etc.

See Phases 3+4 of the Data Platform Product Vision and Roadmap

Screen Shot 2023-02-22 at 3.26.15 PM.png (830×948 px, 85 KB)

Metrics Platform control layer (web app) requirements (high level)

  • Metrics Platform Clients can be used for easy instrumentation of events
  • Centralized and consistent way to run experiments (AB Tests, MAB Tests etc).
  • Control layer UI allows for centralized management of instrumentation schemas, including privacy and security enforcement.
  • Custom Data can be configured from within the control layer
  • Destination of where to write data can also be selected.
  • Not just stream creation but feature mgm't as well

Specific: What do we want to achieve?

Build a control plane interface for administering instrumentation of events using Metrics Platform client libraries.

Measurable: How will we know when we've reached our goal?

When the UI is in production and end users can effectively dispatch events to specified streams by submitting a form.

Achievable: What support will we need to achieve our goal?

  • Database for backend
  • Frontend interface for submitting events to specific streams

TK

Relevant: Is this goal worthwhile?

As part of the improvement effort of WMF's infrastructure platform, the Metrics Platform Client libraries and an associated centralized management system will dramatically reduce the friction of rolling out instruments for feature management, A/B testing, experiments.

Event Timeline

I met with @AnneT for a preliminary discussion about what Codex components are available and which components are being planned.

Taking a stab at initial requirements for the control plane, we'll likely need the following components:

  • Buttons - currently available
  • Dropdown menu - available as a Select component
  • Table to display tabular data - currently in planning stages (see T303320)
  • Datepicker for expiring instruments - not yet planned, no task

As we plan for building the control plane (most likely as a MediaWiki page), we can help contribute/upstream components back to Codex.

@cjming FYI, we're working on a task to enable the use of more input type attributes in the TextInput component, including date and a few other date-time-related types. This would enable you to use the TextInput component as a date input with the browser-provided datepicker UI. You can test out an example here. This might be a workable solution if you didn't want to build a full DatePicker component!

@AnneT that's fantastic news and will likely work for our use case - thanks for the heads up!