[tor-bugs] #30612 [Metrics/Website]: Replace timeouts-and-failures graph with errorcodes graph

[Tor Bug Tracker & Wiki]

#30612: Replace timeouts-and-failures graph with errorcodes graph
-----------------------------+--------------------------------
 Reporter:  karsten          |          Owner:  metrics-team
     Type:  enhancement      |         Status:  needs_revision
 Priority:  Medium           |      Milestone:
Component:  Metrics/Website  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:                   |  Actual Points:
Parent ID:  #29507           |         Points:
 Reviewer:  irl              |        Sponsor:
-----------------------------+--------------------------------

Comment (by karsten):

 Replying to [comment:2 irl]:
 > This graph is heading in the direction of graphs that are interesting
 for us but not so useful to put on Tor Metrics. This is not an easy graph
 to explain to the general public. Explaining cases where tor might refuse
 to attach a stream to a circuit goes way beyond what we've had to explain
 in other graphs.

 I see what you mean.

 How about we write a specification/description what these error cases mean
 for ourselves and decide later whether that's digestible for Tor Metrics
 users? Worst case we decide against adding this graph but still have a
 description for a graph we discuss internally.

 > It's also a very busy plot, that might be concealing information. When
 bars are on top of each other it is not clear if there is a consistent
 z-order or if it is somewhat intelligent to show shorter bars on top?

 It is indeed a lot of information, though I don't think it's concealing
 anything. If two OnionPerf instances had the same error type on a given
 day the two bars are stacked. Admittedly, this isn't obvious and would
 require a half sentence in the explanation.

 > Is there some middle ground for a plot between this one and the one
 currently on Tor Metrics that is simpler to explain but still is more
 detailed than the current one?

 What parts would you simplify?

 For example, we might reduce the number of error types by picking the most
 common ones and using an "other" category for the rest. This would require
 making sense of the error types, though, which is something we should do
 anyway.

 Or did you have anything else in mind?

 Thanks for the feedback!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30612#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online