[tor-bugs] #30303 [Metrics/Website]: Add "archived" badge to graphs that are not updated anymore

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#30303: Add "archived" badge to graphs that are not updated anymore
---------------------------------+----------------------
     Reporter:  karsten          |      Owner:  karsten
         Type:  enhancement      |     Status:  assigned
     Priority:  High             |  Milestone:
    Component:  Metrics/Website  |    Version:
     Severity:  Normal           |   Keywords:
Actual Points:                   |  Parent ID:
       Points:                   |   Reviewer:
      Sponsor:                   |
---------------------------------+----------------------
 Yesterday's discussion on #29772 made me think about a process for
 archiving Tor Metrics graphs. The background there is that we need a
 defined way to remove graphs when we think they're not as useful anymore.
 On the one hand we don't want to surprise our users that their favorite
 graph is gone, but on the other hand we simply cannot keep updating
 everything forever. Last but not least, we need confidence that we can
 remove an experimental graph, or we might decide to rather not add it in
 the first place.

 Note that this topic has also come up a while ago in the context of
 removing the Tor Messenger graph (#26030, #26047). We just didn't find a
 good place to archive that graph and the underlying data. Maybe we can
 find one now.

 How about we add a new badge "archived" for graphs that are not updated
 anymore? (Or if that's too much UX, we could simply write "(archived)"
 next to the graph title.)

 Whenever we archive a graph, its URL will not change. Whoever has the
 graph page bookmarked will just end up on a page where the graph doesn't
 show the latest three months and where they cannot update the graph
 anymore. But users can still download the graph or data or learn about the
 CSV data format and how to ~~re~~produce the graph.

 One technical detail we need to think about is that we'll have to put the
 graphs (PNG and PDF) and data (CSV) somewhere. I think we were blocking on
 that the last time we talked about this, but we shouldn't. I suggest to
 simply add them to Git and include them in the .war file that we deploy.
 The image files will always be small, and if the CSV file would be too
 big, we could compress it. As an example, the Tor Messenger files are: 24K
 for the CSV, 32K for the PDF and 32K for the PNG. Still, this seems easier
 than making sure that all relevant files are present in the file system of
 the server. And for comparison, with all the required libraries, our .war
 file is currently at 22M.

 Something else we'll need to consider is ''which'' graph we're putting on
 the graph page. For example, if the graph had a country parameter, we'll
 have to choose one country as a sample, and the user will not be able to
 customize the country on the website anymore. However, the CSV file will
 still contain all countries, so that the user can plot their own graph
 with whatever country they want to see.

 Regarding timing, it would still be nice to give a two weeks heads up for
 people to make their favorite customized graph and for them to tell us why
 we're wrong to archive that graph. Basically, we'd write "(deprecated)"
 (or add a "deprecated" badge) next to the graph first, and two weeks later
 change that to "archived".

 How does this sound?

 Setting priority to high, because it would be great to have a plan for
 removing graphs before we add the more experimental ones for #29772 and
 #29773. We don't have to implement this idea first, but it would be good
 to agree whether this would be a viable solution.

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs