Add "archived" badge to graphs that are not updated anymore
Yesterday's discussion on legacy/trac#29772 (moved) 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 (legacy/trac#26030 (moved), legacy/trac#26047 (moved)). 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 reproduce 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 legacy/trac#29772 (moved) and legacy/trac#29773 (moved). We don't have to implement this idea first, but it would be good to agree whether this would be a viable solution.