[tor-bugs] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files

[Tor Bug Tracker & Wiki]

#25383: Deprecate stats.html and stats/*.csv files
-----------------------------+--------------------------------
 Reporter:  karsten          |          Owner:  metrics-team
     Type:  enhancement      |         Status:  needs_revision
 Priority:  High             |      Milestone:
Component:  Metrics/Website  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:                   |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:  irl              |        Sponsor:
-----------------------------+--------------------------------
Changes (by karsten):

 * status:  merge_ready => needs_revision


Comment:

 Replying to [comment:31 irl]:
 > Replying to [comment:29 karsten]:
 > >  - Does it make sense to specify our per-graph CSV files there, rather
 than in the CSV file header?
 >
 > I think yes. The CSV files are machine-readable first, human-readable is
 not the priority for these files.

 Agreed.

 > >  - Is the format with two subsections Parameters and Columns okay? Is
 something missing?
 >
 > I think this is OK. Perhaps we need an example GET request to start this
 document off. We're really documenting an HTTP API, not just the
 individual files.

 Good point. I'll add something.

 > Perhaps we need to say that either we do, or we don't, guarantee the
 ordering of the columns. If we add/remove columns later would we change
 the ordering? Especially with removal, would we pad with nulls or
 something like that? (Anything by transport is particularly affected by
 this).

 Good questions. I think I'd rather not want to guarantee the ordering of
 columns and instead require users to refer to columns by name and not
 index. In particular the null padding sounds like it would implicitly stop
 us from removing unnecessary changes, which seems bad. So, yes, let's
 state this at the start of the page. I'll add something.

 > >  - Are specifications roughly correct/plausible?
 >
 > Nothing is jumping out at me as obviously wrong. I haven't considered
 every one thoroughly yet though.

 Okay.

 > >  - Do the suggestions make sense? The rule of thumb for deciding which
 columns we need was: "it should require a code change to change columns,
 and neither the user should be able to control which columns exist by
 their choice of parameters, nor should the available data have any
 influence on that."
 >
 > The suggestions do make sense, and would solve the immediate column
 ordering issue (although we should still make a statement as to what we
 would expect to happen in the future). I commented on #26950 separately.

 Perfect!

 > > Regarding timing, how about we deploy this page still in July, make
 suggested changes by August 15, take out pre-aggregated stats files by
 September 15, and handle any questions coming out of that in the two weeks
 before the Mexico City meeting?
 >
 > Sounds good to me!
 >
 > merge_ready for this page.

 Setting to needs_revision for the page header part. Will move it back to
 needs_review for whenever I have something.

 Thanks!

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