[jakequade]

> it's pretty obvious that any developer involved in a project can make a reasonable assumption of how rare a bug is

... is it? The fact that a bug exists means there's a logic gap. You can try and patch it with theory, but that's just adding assumption to a scenario created from broken assumptions. Also, the job of telemetry in incident reporting isn't to be vague - its to add precision.

[lmeyerov]

There's probably a ratio of bug-report-to-occurrences that they're used to for difference kinds of bugs. Ex: If user-visible security bugs have good report rates, say 100-1000 leaks per 1 report, and 10 reports, then 1K-10K incidents. This is harder in b2b, but in b2c, PM's should have a feel for it..

[conradev]

You’d be surprised how difficult it is to estimate the frequency that someone sees a bug. The only way to have a “feel for it” is to base it on… other data.

Say there is a bug that happens in the photo taking flow – you’d need to know how often people take photos in Signal. You’d think you could spitball something for that, but it is actually really hard. But if you log how often photos are taken, then that is a great starting point.

But further, lower level logic errors like this, especially ones involving race conditions, are even harder to pin down. That is why on iOS you can log “faults” which are non-fatal but very not-expected events:

https://developer.apple.com/documentation/os/logger/3551617-...

They generate reports with stack traces that you can use to a) judge the prevalence of an issue and b) see where it originated