[tor-reports] Tom's August
me at tomlowenthal.com
Thu Sep 12 18:53:22 UTC 2013
# Coordinator's log, unix-date 1378497600
## Tor Project; Location: San Francisco
## The month started in the Netherlands, at Ohm.
I hosted a meetup and information-sharing session for Tor contributors
and relay operators which went very well, and seemed to be rather
productive for all involved. I also ran a workshop on GPG best
practices. That session was even more successful, and enough folks
asked for a written version that I've started writing
Contributions, suggestions, issues, pull requests, and so on are
welcome. However, this work-in-progress is missing major elements. If
your time is precious, you should probably wait until I have a more
## Two weeks in communications limbo
I planned some time with my partner and family in a relatively remote
community. Unfortunately, the communications infrastructure was badly
damaged by Sandy, and I was not able to work very effectively. I'd
like to apologise for not giving enough folks enough warning of this.
I shall endeavor to provide more accurate advance notice of things
## An open observatory of network interference
At the end of August OONI hit the first milestone on time with full
specifications. Once the specs were done, we began feature work,
tagging a proposed v1.0.0-rc1 only a little late. While we wait for
feedback from our auditors Least Authority (yes, *that* Least
Authority*) and a start to our full code and design audit, we're
putting together the documentation, which should be ready by the end
of the month.
## Tools and processes
We have [outline requirements] for a project management tool, and I
started playing with a few fun alternatives. Trello performed best of
the bunch, and I think that an interface based on kanban or cards
would end up doing well for us. However, I haven't tried out Basecamp
in any useful way, and that's a tool which many swear by for teams of
our size. Sadly, neither of these is free software which we could host
ourselves, and neither has even-slightly-NSA-resistant designs. See my
totally different plans below.
## Where is all this traffic coming from?
In the last few exciting days, I started trying to facilitate a
sensible strategy for our unexpected increase in traffic.
# No plan survives contact with the enemy
## Nor do many bullets, but I'd still rather start out with a full magazine.
## **If it isn't in Trac, it doesn't exist**
Project-management tools: great usability; self-hostable: pick one.
I've talked about this toolbox conundrum with Andrew, and instead of
trying to find new and better tools, I'm going to try and squeeze
every last ounce of awesome out of the one we have. My goal is to use
every applicable Trac feature, and attempt iteratively discover the
best way to use it as a project/contract/deliverable-management and
bug/ticket/task tool. This means that the search for other tools is on
hiatus, but it doesn't mean that we're abandoning the user-stories we
put together. Let's just try to make them happen in Trac.
The short-term aim: everything is in Trac. If Trac says something,
that's the truth. If track doesn't know about something, it doesn't
There are some specific sub-goals here:
1. Put all the things in Trac, so that it accurately reflects the
current state of the universe.
2. Try to ensure that Trac's state is always true, but watch for ways
that it gets out of sync.
3. Find processes, plugins, and other malarkey to combat those
specific failure modes.
There's an optional sub-goals which terrifies me:
1. It might turn out that tweaks to Trac require work to maintain. It
seems reasonable that I might have to take a fair share of that work.
There even are ways you can help:
1. Tell me what's broken. If there's something about Trac which makes
it hard for you to use, a critical user-story which it doesn't do for
you, or a way that you keep seeing it get out of sync, you should tell
me about it.
2. Tell me your secrets. Do you have some neato tools that you use
with Trac, techniques for managing your bugs, or other things which
are not even you final form? I bet I don't know about them, and I bet
others could use them too.
I have documentation about who identifies as being on what team. I
need to make sure teams and projects clear, and then start clustering
into useful groups. I sure bet this effort will be involved with
I don't know about you, but I don't think that these monthly reports
are the best system for keeping each other appraised of our progress.
Our monthly week of firehose is supposed to help our community (and
others) know what we're up to. However, things like Lunar's Tor Weekly
News seem way better at that. On the other hand, these blasts aren't
great for getting and giving specific information to the people we
work with or who are affected by our work. I think that we could use
better inter- and intra- team communications than monthly reports.
Stay tuned (or tell me why I'm right/wrong, or what should be done
instead; I promise I won't say "well volunteered").
## Specific project plans
We have a big contract which starts +/- a few days from now, and has
lots of things in it. It needs to be broken into a concrete and
realistic project plan. Trac here I come.
## Hiring another project manager
This is Andrew's baby, but I think that my help might be useful,
especially with interviewing and candidate selection.
This month, OONI will complete the v1 documentation while LA performs
a code review.
More information about the tor-reports