webrtc-stats
webrtc-stats copied to clipboard
Write a "how to add more stats" guideline document
This has been on the plan for a while, but it's nice to have a bug on it.
This document will be targeted towards developers and aims to:
- Give developers an idea how standardization works and guide them through it.
- Put ownership of the entire process of adding the stats (spec issue, spec PR, implementation) on the developer proposing the stats. Allowing resources and expertise to be used appropriately.
- Decrease the perceived and actual delay time of standardization efforts. Spec should not be a blocker unless we really should not add the stats.
No more "I filed an issue and nothing happened so I added a goog-stat".
This will allow us to:
- BAN adding more goog-stats, which will...
- Incentivize more development efforts to be put into spec-compliance, and
- Encourage switching to the spec-compliant API.
- And eventually deprecate legacy getStats().
The document should also cover experimental stats, both the kind we aim to standardize but need to test the metric before we know it's a good one and the kind that is only useful for Chromium debugging and evaluating the result of feature experiments.
Experimental stats will have limited exposure, e.g. not exposed to the web platform by default (hidden behind Origin Trials experiment, etc.).
Here's the doc I intend to share, please comment. https://docs.google.com/document/d/1q1CJVUqJ6YW9NNRc0tENkLNny8AHrKZfqjy3SL89zjc/edit?usp=sharing I'll send it to the mailing list tomorrow. @vr000m this also shows an overview of some of the C++ implementation of getStats() even if it doesn't tell you how difficult it is to add a particular metric.
Sent to mailing list, no comments. Guess it's perfect.
It makes sense to either link to it or copy it into the webrtc-stats repo - not as a spec, but as "helpful material".
I'll create a PR to link to it from our README.md.
We're so closed to PR we probably don't need this anymore
Go to provisional stats to give input