we need a place to keep track of our tech reports

We produced a bunch of pdfs for the mid March deadline, and I think we've had a bunch of pdfs for previous things too. They're all scattered, and soon they'll be lost to the sands of time.

We should gather a tech report page to track them.

Assigning to me so people aren't like "wtf close it", but do feel free to jump in and do it first if you like. :)

added component::webpages/website owner::karsten priority::medium resolution::implemented status::closed type::enhancement labels

I'm maintaining a list of metrics reports here.

Should we collect the other tech reports that are scattered around, decide on some criteria for calling a PDF a "Tor Tech Report," number them chronologically, and put them on the Tor website?

I can help with that.

Yes please.

The main criteria I think are a) whether we'll still want people to read it down the road, and b) whether it's plausible that a paper will want to cite it someday.

I think txt files in the proposals directory shouldn't be. But things that are pdfs that we make a blog post about, when we don't publish them in a traditional academic venue, should.

There are grey areas though, like my research blog posts. I think they probably should count, since they're little mini research papers that I didn't make into pdfs but could probably get accepted at a workshop somewhere. The tie-breaker that makes them count is that other research papers are citing them.

Replying to arma:

Yes please.

I started a list of possible tech reports here. Far from being final, but should be a start.

Superseded technical reports should still be considered technical reports. They may still be useful for historical purposes.

Replying to rransom:

Superseded technical reports should still be considered technical reports. They may still be useful for historical purposes.

Hmm, right. Maybe the better criteria would be whether we'd made them technical reports back then. Feel free to edit the wiki page.

Speaking of, I just moved the wiki page to doc/TechReports.

Replying to rransom:

Superseded technical reports should still be considered technical reports. They may still be useful for historical purposes.

Agreed. The goal here is to document our thoughts over time, not to pretend we never had any thoughts before the current ones. That said, marking old ones as superseded is a great thing to do.

So, now that we have a list of possible Tor Tech Reports, how do we proceed? I think one aspect we need to discuss is the process for publishing a Tor Tech Report. Here's a suggestion:

• We define YYYY-NNNN as the numbering scheme with YYYY being the year and NNNN being a counter that starts at 0001. Numbers in a given year don't necessarily match publication order, especially not for past years. But that's probably fine.

• We set up a tech-reports.git repository with all the LaTeX sources of published tech reports in their own subdirectory. Whenever someone wants to publish a tech report, they clone that repository, create a new directory YYYY/short-tech-report-title/, and put all their source files in there. They don't assign a tech report number yet. They send an email to tor-dev with the abstract or first introduction paragraph and links to their repo and to the PDF. Roger or Nick approve that their report should become a Tor Tech Report. The guy maintaining tech-reports.git (which could be me) pulls from the repo of whoever sent the tor-dev mail, assigns the next report number to it, puts the number in the LaTeX sources, merges them into the official tech-reports.git, puts the PDF on the Tor website, and replies to tor-dev that the report is available.

• There are no formatting requirements to the report, except that they must contain a line "Tor Tech Report YYYY-NNNN" in their subtitle.

• Changes to existing tech reports should be rare. It's okay to fix typos or add a footnote saying that the report is superseded by another report. But major updates should instead go into a new report.

Roger, Nick, does the process above make sense to you? If so, I could start collecting LaTeX sources of existing tech reports.

Trac:
Cc: N/A to nickm

After talking to Roger today, we came up with these modifications to the suggested process:

• If tech report sources already exist in a different Tor Git repo, we don't have to copy them to the tech-reports.git repo. We should rather add a file pointing to the location containing the sources.

• The tech report name should not only contain the year, but also the month. We came up with YYYY-MM-NN, which, in retrospect, could easily be confused as an ISO date. Maybe we should rather use YYYY-MM-NNN or YYYY-MM/NN.

I'm going to start converting old tech reports into the new format and will send them to tor-dev soon.

Trac:
Status: new to assigned
Owner: arma to karsten

Replying to karsten:

• The tech report name should not only contain the year, but also the month. We came up with YYYY-MM-NN, which, in retrospect, could easily be confused as an ISO date. Maybe we should rather use YYYY-MM-NNN or YYYY-MM/NN.

I slightly favor YYYY-MM-NNN.

Changed and pushed to my fivereports branch.

Quick update: we now have https://research.torproject.org/techreports.html as the place for our tech reports. doc/TechReports has the list of upcoming reports. We have two Git repos for tech report sources and for the research.tpo website.

Leaving this ticket open until the reports on the wiki are all contained on techreports.html.

All reports from the original wiki:doc/TechReports wiki page have been converted to Tor Tech Reports. With that, I'll stop maintaining the wiki page. https://research.torproject.org/techreports.html is the place that has a recent list of reports. Copying the latest version of the wiki table here for reference and then deleting the wiki page. Also, closing this ticket. (Yay!)

Report title	Author(s)	Publication date	Report number	Superseded?
Pluggable Transports Roadmap	sjmurdoch, asn	March 17, 2012	2012-03-003
Datagram Testing Plan	sjmurdoch	March 16, 2012	2012-03-002
Packet Size Pluggable Transport and Traffic Morphing	asn	March 13, 2012	2012-03-004
What if the Tor network had 50,000 bridges?	karsten	March 9, 2012	2012-03-001
Five ways to test bridge reachability	arma	December 1, 2011	2011-12-001
Different Ways to Use a Bridge	Sebastian	November 29, 2011	2011-11-002
Comparison of Tor Datagram Designs	sjmurdoch	November 7, 2011	2011-11-001
An Analysis of Tor Bridge Stability---Making BridgeDB give out at least one stable bridge per user	karsten	October 31, 2011	2011-10-001
Ten ways to discover Tor bridges	arma	October 31, 2011	2010-10-002
Case study: Learning whether a Tor bridge is blocked by looking at its aggregate usage statistics, Part one	karsten	September 15, 2011	2011-09-002
An anomaly-based censorship-detection system for Tor	George Danezis	September 9, 2011	2011-09-001
Better guard rotation parameters	arma	August 20, 2011	2011-08-001
An Analysis of Tor Relay Stability	karsten	June 30, 2011	2011-06-001
Strategies for getting more bridges	arma	May 13, 2011	2011-05-001
Overview of Statistical Data in the Tor Network	karsten	March 14, 2011	2011-03-001	by the metrics website
Measuring the safety of the Tor network	arma	February 5, 2011	2011-02-001
Privacy-preserving Ways to Estimate the Number of Tor Users	karsten	November 30, 2010	2010-11-001
Comparison of GeoIP Databases for Tor	karsten	October 23, 2009	2009-10-001
Performance of Requests over the Tor Network	karsten	September 22, 2009	2009-09-001
Reducing the Circuit Window Size in Tor	karsten	September 20, 2009	2009-09-002
Analysis of Circuit Queues in Tor	karsten	August 25, 2009	2009-08-001
TorFlow: Tor Network Analysis	mikeperry	August 7, 2009
Measuring the Tor Network from Public Directory Information	karsten	August 7, 2009
Evaluation of Client Requests to the Directories to determine total numbers and countries of users	karsten	June 25, 2009	2009-06-002	by this report
Analysis of Bridge Usage in Tor	karsten	June 22, 2009	2009-06-003	by metrics website
Evaluation of Relays from Public Directory Data	karsten	June 22, 2009	2009-06-001	by this report
Simulation of the number of Fast, Stable, and Guard flags for changed requirements	Sebastian, karsten, sjmurdoch	April 11, 2009	2009-04-001	by this report

Trac:
Status: assigned to closed
Resolution: N/A to implemented

closed

mentioned in issue #6378 (moved)

mentioned in issue #6380 (moved)

moved to tpo/web/trac#5405 (closed)