Thus spake Karsten Loesing (karsten@torproject.org):
On 7/11/12 12:20 PM, Karsten Loesing wrote:
The meeting will happen
July 18, 15:00--17:00 UTC in #tor-dev.
We didn't talk about deliverable 8 at the meeting. Maybe Mike can reply here and give some quick feedback on this deliverable with respect to phrasing/interpreting the deliverable text and possible tasks to promise for the four milestones?
Sorry for missing the meeting, but we did discuss this together on the previous evening. The general plan is to hire someone new. There was some hope of combining funding from a couple different orgs to start the position earlier, but it looks like that won't be happening before SponsorL funding is inked. Instead, it looks like we'll get some general development assistence from other existing staff at those orgs.
Here's the job announcement page that needs to be updated to reflect a possible October start date: https://www.torproject.org/about/jobs-browserhacker.html.en
Action item 0 is to figure out how and where to announce that.
As per specific deliverables, can we do something as simple as "Solve the Browser-related trac tickets with keywords tbb-disk-leak, tbb-linkability, tbb-fingerprinting, and tbb-usability in trac priority order"?
The development landscape in the browser space is very much in a state of change, so I'd like max flexibility to deal with chaos over here, within reason.
tbb-disk-leak tickets come directly from new and existing violations of https://www.torproject.org/projects/torbrowser/design/#security
tbb-linkability and tbb-fingerprinting come directly from new and existing violations of our 3 privacy properties: https://www.torproject.org/projects/torbrowser/design/#privacy
I have not yet created any tbb-usability tickets, but I have a pile to file from http://petsymposium.org/2012/papers/hotpets12-1-usability.pdf, a pile of complaints from friends, and I hope to extract another pile from the support tracker, if possible.
The deliverable language must absolutely be clear that we do not expect to solve all of these tickets to meet it, however. They will appear constantly as new Firefox releases are made. Some months, I have been able to keep up with the ticket creation rate, though there is a ~50 ticket backlog from the months where I have not. It's not at all clear that one additional person for only 6 months or whatever will be able to eliminate that backlog before the end of the contract. In fact, that almost certainly won't happen on that timeframe.