Preventing Random Acts of Metrics
summary
Google's Project Ocean applies a five-step metric process — objectives, observable aspects, baselines, desired trends, signal phenomena — and warns of abstraction traps (framing, portability, formalism, ripple, solutionism). A concrete example models install success for a fictitious Go data library using privacy-safe proxies (downloads, issues, doc patches), notes pitfalls of baselining against the wrong ecosystem, recommends leading and lagging signals (support requests as leading, doc patches as lagging), and points to CHAOSS and research awards for follow-up.
AI-written summary · about
chapters (6)
- 0:00Introduction to talk
- 2:30Open source as socio-technical systems
- 7:31Algorithmic vs sociotechnical framing
- 11:02Example Go library metrics
- 25:54Key takeaways and conclusion
- 27:00Q&A session
related talks
26mBuilding & Supporting Open Source Communities Through Metrics
35mThe Benefits and Pitfalls of OSS Project Metrics: Measuring Health and Risk in Open Source Communities
43mBuilding and Supporting Open Source Communities Through Metrics
36mPanel Discussion: OSS Viability and Project...
25mDefining the Limits of Risk
48mStanding Up for the Unmeasurable in The Design Process
41mBuilding and Supporting Open Source Communities Through Metri...
46mPanel Discussion: What Our OSPOs Have...
