Opened 7 years ago

Closed 7 years ago

#5405 closed enhancement (implemented)

we need a place to keep track of our tech reports

Reported by: arma Owned by: karsten
Priority: Medium Milestone:
Component: Webpages/Website Version:
Severity: Keywords:
Cc: nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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. :)

Child Tickets

Change History (13)

comment:1 Changed 7 years ago by karsten

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.

comment:2 Changed 7 years ago by arma

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.

comment:3 in reply to:  2 Changed 7 years ago by karsten

Replying to arma:

Yes please.

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

comment:4 Changed 7 years ago by rransom

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

comment:5 in reply to:  4 Changed 7 years ago by karsten

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?.

comment:6 in reply to:  4 Changed 7 years ago by arma

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.

comment:7 Changed 7 years ago by karsten

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.

comment:8 Changed 7 years ago by karsten

Cc: nickm added

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

comment:9 Changed 7 years ago by karsten

Owner: changed from arma to karsten
Status: newassigned

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.

comment:10 in reply to:  9 Changed 7 years ago by arma

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.

comment:11 Changed 7 years ago by karsten

Changed and pushed to my fivereports branch.

comment:12 Changed 7 years ago by karsten

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.

comment:13 Changed 7 years ago by karsten

Resolution: implemented
Status: assignedclosed

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
Note: See TracTickets for help on using tickets.