# Rust Metrics Planning Document

- ## Context
- https://estebank.github.io/rustc-metrics.html
- https://github.com/rust-lang/compiler-team/issues/679
- Tracking Issue: https://github.com/rust-lang/rust/issues/128914
- ## Aims
- **Trust**: Do not violate trust of our users
- NO TELEMETRY, NO NETWORK CONNECTIONS
- emit metrics locally
- user information should never leave their machine in an automated manner, sharing their metrics should always be opt in, clear, and manual
- All of this information would only be stored to disk, with some minimal retention policy to avoid wasteful use of users’ hard drives
- **feedback**: improving feedback loops to assist with iterative improvement within the project
- answer questions from real production environments in a privacy preserving way
- improve legibility of rare or intermittent issues
- earlier warnings for ICEs and other major issues on nightly, improving likelihood that we'd catch the issues before they hit stable.
- https://blog.rust-lang.org/2021/05/10/Rust-1.52.1.html
- **performance impact**: leave no trace (minimize performance impact, particularly for default enabled metrics)
- **Extensible**: it should be easy to add new metrics as needed
- Only add metrics as a way to answer a specific question in mind, with an explicit documented rationale
- **user experience**: improving user experience of reporting issues to the project
- ## Quests (provisional)
- Supporting rust feature development
- Improved ICE Reporting
- build tooling for automated cleanup of metrics in cargo
- collate information in crater
- build support for reporting specific issues back to relevant contributors
- e.g. cargo plugins, vscode, or rust-analyzer could be used to locally analyze metrics for issues rust teams care about and present users with an appropriate summary to file as a ticket
- Direct improvements of User Experience e.g. identifying which compiler errors to focus on improving
- Improve perf feedback loops and insight
- collate information in perf