rust-lang / rust-lang/rfcs

telemetry service that tabulates top warnings, complaints

Open
#629 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

T-dev-tools
Dominant language
Markdown
Stars
6.6k
Forks
1.7k
Avg merge
16h 14m
Merged PRs (30d)
1

Description

Issue by graydon
Wednesday Jul 31, 2013 at 20:05 GMT

For earlier discussion, see https://github.com/rust-lang/rust/issues/8161

This issue was labelled with: A-diagnostics, A-infrastructure, A-instrumentation, I-enhancement, I-wishlist in the Rust repository


This is a bit of a weird / wishlist item, but it would be nice to be able to gather statistics on how often our users hit which errors, and how much they like them vs. loathe them.

This would be a relative of #2092 in which we have a code reserved for each warning/error/lint message (which we never reuse). Rustc would be configured to keep local tabulation in your homedir while you work of a few basic statistics (codebase size, number of unique files processed, number of runs of the compiler, resource usage) and the number of occurrences of a given message, along with a pair of commands (say: rustc yay and rustc boo) that mark your approval or disapproval of the most recent error message. Periodically, or on demand, you could submit your tabulated set to a telemetry service. This way we could get directed feedback of the sorts of problems people are having while using the compiler as well as whether they appreciate or feel annoyed by various forms of error message.

(Other suggestions welcome; was thinking win vs. fail, or perhaps some variant of derp, wat or fuuuuuu but couldn't think of suitable paired positive-affirmation phrases, and in any case they seem a little unkind.)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the earlier discussion in issue #8161 and the reserved diagnostic-code context in issue #2092. The issue names no implementation files or tests; work would first need a settled scope for local statistics, user feedback commands, and telemetry submission before completion could be defined.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
observability
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.