On Thu, 19 Jul 2012 12:08:28 -0700 Mike Perry mikeperry@torproject.org wrote:

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.

Action item pre-0 is to rework the content on that page. I'm currently working with employment lawyers and HR people to sort out what is "non-standard" from "illegal according to US labor laws". I'd rather spend money on hiring a person than defending a lawsuit from a bored person looking to sue Tor for labor law violations.

On Thu, Jul 19, 2012 at 09:37:46AM +0200, Karsten Loesing wrote:

here's a summary from talking about sponsor L deliverables in #tor-dev yesterday.

Thanks for working on this!

To quickly recap what what the meeting was about: Sponsor L is very likely to happen, but the contract is not yet signed. The contract is supposed to run from October 2012 to August 2013 and would have quarterly milestones. The purpose of the IRC meeting was to get some developer feedback on the deliverables before negotiating and signing the contract. The sponsor L wiki page is here:

https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorL

Note that I'd like to add the (possibly revised) paragraphs below to the wiki page, so that they don't get lost in everybody's inboxes. Please somebody let me know if that's a dumb idea.

You should definitely put them somewhere. But be sure to retain the original text too, so we can go back and compare if we need to later.

The phrasing of deliverable 1, which explicitly mentions "DNS" and "HTTP", is problematic. George thinks that DNS and HTTP are hard transports to write properly. George is okay with doing a stupid attempt at an HTTP transport, but he's not prepared to promise a "good" HTTP/DNS transport. We should try to take out the words "DNS" and "HTTP" from the deliverable text. If it's too late to do that, we should make sure that we can replace them with better transports, maybe after writing down why we think the transports we picked are better. If the focus of this deliverable isn't just on building and deploying transports, George would prefer to take care of the pluggable transport ecosystem for future deployment: develop and deploy pyptlib and a Python transport or two; develop (and potentially deploy) obfs3; keep an eye out (and help) on academic research; help Zack with Stegotorus, especially if he is interested in porting it to Python. We didn't talk about milestones, because the question of deliverable phrasing or internal interpretation needs to be answered first.

Helping with Stegotorus should count as working on an http transport, yes? There are still a lot of barriers to having a good http transport, but I think the prize is worthwhile enough that we should keep working to reduce the number of barriers.

I think it would be worthwhile to explore how much of a mess it would be to use DNS as a transport in practice. Does the bridge side need to run a hacked nameserver on port 53? That sounds like a deployment problem for some bridge operators (but not for others). More generally, this topic like a great task to write up as a research problem for some student to tackle.

For our "one more", we're already looking into pretending to be Skype video as a transport (Skypemorph). It would be great to put some effort into the deployment side of Skypemorph -- better READMEs, identify and start fixing Tor issues like #5483, etc.

All of that said, I totally agree that for #1, we need to be sure Andrew and the funder both understand that we can't promise that we'll deploy any particular transport protocol -- the first step is research, and that means step two must stay flexible.

George and Nick say that, in order to complete deliverable 2, we'll have to finish #5040 which depends on #4773 (which overlaps with deliverable 3). Nick thinks we can promise "progress towards" these two tickets for December, and aim to implement them in December, with a possibility of slipping to a March deliverable. Then we'll have some time for obfsproxy bridges to report stats, so that Karsten can make graphs for June or August at the latest.

Sounds great. We should be sure to generalize what we do with obfsproxy and metrics.tp.o, so it will be smoother to do for our next pluggable transports (e.g. the ones we mention in #1 above). I think from #5040 and friends that it looks like this is already the plan?

Is "extended OR protocol" api support part of the planned python library that Blanu and George are working on? If not, we should get it on somebody's list.

The remaining part of deliverable 3, minus #4773 which is part of deliverable 2, is to implement the safe-cookie authentication mechanism. The same milestones apply here as to deliverable 2, so "progress towards" in December and "done" in March.

Ok.

Deliverable 4 will already be done before the sponsor L contract would start. It's promised for sponsor G for September 2012. Aaron says that BridgeDB is ready, minus any tweaks we want to make, and a Tor 0.2.4 build that people can run. Aaron would like to get some public obfsproxy bridges running Tor 0.2.4 listed in bridges.tpo before end of September 2012.

I'd like to see that happen too.

We might also choose to say that "bridgedb remains running the whole time" is a prerequisite for finishing deliverable 4.

We'll probably have to promise something else for deliverable 4.

Not really. In the research world, it is totally normal to 1) do X, 2) ask for money to do X, 3) spend that money to do Y, 4) ask for money to do Y, rinse/repeat. It's the only sane way to do long-term research on predictable timelines. Or said another way, I think nobody will mind that we've made great progress on the deliverable already, given that there's plenty more work to do on the topic.

That said, now would be a great time to brainstorm some SponsorZ-style items we'd like to do on this topic next, and plan to get those started too (i.e. do the above step 3). The first thing that comes to mind is having bridgedb know when some of its bridge addresses are blocked in some countries.

Deliverable 5 is totally doable, says Runa. This deliverable involves a few substeps which we might derive milestones from: rewriting parts of the website is something we can do ourselves; planning some kind of campaign around the videos to be created and not just putting them out there is something we can do, too; writing screenplays for videos is something we'll have to do together with a partner; creating videos is something we'll have to find a partner for; starting the campaign is something we can do.

We should involve Karen in this discussion, since she's already doing some sample videos, and she's a plausible fit for parts of the "tech writer" role we describe. The question for Karen is how much of a distraction it will be for her relative to her fundraising work.

We should figure out what Runa had in mind by "partner", and how much of that we can do ourselves; there is currently no money in the 2012 budget for said partner.

Deliverable 6 is doable. Runa thinks she could either be the community manager by extending her tasks, or we could hire a new person. She also has an idea who to hire for English, Farsi, and Arabic; there was a brief discussion between Runa and Nick about making an open call for these hires vs. only asking people we know. Runa thinks that the trick for paid support is to find a way to let anonymous users pay for support and still make sure they get a reply in time according to the service level agreement we have to create.

Andrew is hoping to use this as an opportunity to explore "hire people who will do great work and not charge American prices". Apparently our current Farsi translator is one such person, and Andrew hopes we find more.

We have four separate directions in mind for this "community manager" notion (not all funded by SponsorL, mind you): 1) Relay operator coordinator. Somebody to keep relay operators happy and in touch with us, encourage people to set up new relays, organize recommended configurations, etc. Especially important in tandem with our "network diversity" work at #6232. 2) Volunteer-developer coordinator. Somebody to take incoming volunteers and help them find good existing projects to work on. Likely involves making our volunteer page more usable. Should also include knowing enough about every project to recognize and identify good low-hanging fruit, and knowing enough about our priorities to make smart decisions. 3) Blog/forum/mailinglist coordinator, to make sure our users have useful answers, and ultimately to manage and organize the volunteers who make sure our users have useful answers. 4) Social media person, to be our face on twitter, etc.

I believe the plan is for Runa to cover #4, and for us to contract somebody in our relay operator community part-time for #1 to start. I think there is no plan for #2 and #3 yet; but I'd love it if we could get somebody part-time for #2.

Runa is wondering why we want funding for languages no one has emailed us in (Spanish and French); though nobody has emailed us in Arabic, either.

Countries like Venezuela are likely to be on more peoples' radar in the coming years. As for French, a lot of North Africa can do French better than they can do English. I bet that's at least partly the case in Vietnam too.

Deliverable 7 is doable. Runa is somewhat unhappy that funding doesn't include Arabic. She says a large number of our users speak either Farsi or Arabic, so not having funding for Arabic translations (and thus relying on volunteers) seems silly; if we have funding for Arabic support, we should also include Arabic translations. Runa has an idea of who to hire for Farsi and Arabic translation, no idea about Vietnamese and Chinese (but can't be too hard to find someone).

There's totally time to write 'Arabic' into the list if we want. Note that just because we promise more languages doesn't mean we get any more money though.

Here's a list of languages the funder thought we might want to put on the contract: "Arabic, Farsi, Mandarin, Vietnamese, Burmese, Spanish".

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?

One phrasing of this deliverable I've seen is "fix top 15 torbutton/torbrowser bugs as seen in ticket system". Mike wants somebody who can jump into the Firefox code and bend it to our will. He posted a job description at https://www.torproject.org/about/jobs-browserhacker.html.en and is waiting on Andrew and tor-exec to say "yes you can announce and start interviewing". See other thread responses.

Deliverable 9 substantially overlaps with Sebastian working on Thandy in Q3. Sebastian is unclear whether his work will be funded by sponsor L money, and if not, what work remains to be funded by sponsor L.

I believe there's no funding specifically for Thandy work other than this upcoming SponsorL contract. So I would guess Sebastian's Q3 work was going to be this deliverable 9.

Sebastian's plan for Q3 is that Thandy bundles should exist and work at the end of Q3, which is probably the hardest part of deliverable 9. Deliverable 9 further requires coordination between Vidalia and Tor with respect to updating config options. Sebastian suggests to complete deliverable 9 by March 2013. December 2012 would give us just three months of testing which may not be sufficient to make Thandy the new default distribution mechanism, but we also shouldn't push it back further than March 2013. Aaron is also interested in working on Thandy and will talk to Sebastian about it.

Ok. This work does tie into SponsorJ's hopes that we'll be able to automate builds for our bundles -- Thandy deployment without buildbot and easy automated build and QA will leave us pretty frustrated. Maybe that's what Sebastian meant when he talked about Q3 above.

We should also involve Nick in the discussion for deliverable 9, since it's going to need bugfixes/etc on the Thandy code. And Tomas from the Vidalia side.

We didn't talk about deliverable 10 at the meeting. Maybe Erinn or Jake 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?

I think what we have in mind here is a harness for running TBB on a given OS in a VM, having it do some stuff, and then having an automated way to see what changed on the system.

I think the funder would be satisfied if we hack together something to do the comparison once per OS, and then write a report categorizing the traces and describing what can be done about each.

But imo that would be a waste of the time/money, since it would cost the same amount of time and money to do it a second time. Instead we should focus on building a framework for running TBB and automatically noticing regressions -- whether that's new traces left behind, or anonymity leaks when you do a websocket query, or whatever. This topic clearly ties into the "QA automation" topic.

--Roger

On Thu, 19 Jul 2012 19:55:52 -0400 Roger Dingledine arma@mit.edu wrote:

First off, let me welcome tor-dev and the world to the sausage factory of open source projects.

You should definitely put them somewhere. But be sure to retain the original text too, so we can go back and compare if we need to later.

Won't the past text and the diff be in the wiki history for the page?

All of that said, I totally agree that for #1, we need to be sure Andrew and the funder both understand that we can't promise that we'll deploy any particular transport protocol -- the first step is research, and that means step two must stay flexible.

I expect the pushback to be along the lines of "this is a deployment goal, not a research goal". If http/dns is bad, then we should figure out some way to deploy two unique transports in the wild.

Andrew is hoping to use this as an opportunity to explore "hire people who will do great work and not charge American prices". Apparently our current Farsi translator is one such person, and Andrew hopes we find more.

The language-specific support is part-time, at best.

We have four separate directions in mind for this "community manager" notion (not all funded by SponsorL, mind you):

1. Relay operator coordinator. Somebody to keep relay operators happy

and in touch with us, encourage people to set up new relays, organize recommended configurations, etc. Especially important in tandem with our "network diversity" work at #6232. 2) Volunteer-developer coordinator. Somebody to take incoming volunteers and help them find good existing projects to work on. Likely involves making our volunteer page more usable. Should also include knowing enough about every project to recognize and identify good low-hanging fruit, and knowing enough about our priorities to make smart decisions. 3) Blog/forum/mailinglist coordinator, to make sure our users have useful answers, and ultimately to manage and organize the volunteers who make sure our users have useful answers. 4) Social media person, to be our face on twitter, etc.

I believe the plan is for Runa to cover #4, and for us to contract somebody in our relay operator community part-time for #1 to start. I think there is no plan for #2 and #3 yet; but I'd love it if we could get somebody part-time for #2.

Actually, we have three roles. #4 is the same as #3. Whether it's mailing list, forum, twitter, facebook, google+, whatever, the role is the same.

...

Runa is wondering why we want funding for languages no one has emailed us in (Spanish and French); though nobody has emailed us in Arabic, either.

We have only told people we can handle English and Farsi at this point. Once we announce others, they will come.

On Thu, Jul 19, 2012 at 11:55 PM, Roger Dingledine arma@mit.edu wrote:

On Thu, Jul 19, 2012 at 09:37:46AM +0200, Karsten Loesing wrote:

...

Deliverable 5 is totally doable, says Runa. This deliverable involves a few substeps which we might derive milestones from: rewriting parts of the website is something we can do ourselves; planning some kind of campaign around the videos to be created and not just putting them out there is something we can do, too; writing screenplays for videos is something we'll have to do together with a partner; creating videos is something we'll have to find a partner for; starting the campaign is something we can do.

We should involve Karen in this discussion, since she's already doing some sample videos, and she's a plausible fit for parts of the "tech writer" role we describe. The question for Karen is how much of a distraction it will be for her relative to her fundraising work.

We should figure out what Runa had in mind by "partner", and how much of that we can do ourselves; there is currently no money in the 2012 budget for said partner.

I'd love to see Karen create the videos as she's done a great job so far. I only said "partner" because we've previously worked with other organizations on similar projects.

...

Deliverable 6 is doable. Runa thinks she could either be the community manager by extending her tasks, or we could hire a new person. She also has an idea who to hire for English, Farsi, and Arabic; there was a brief discussion between Runa and Nick about making an open call for these hires vs. only asking people we know. Runa thinks that the trick for paid support is to find a way to let anonymous users pay for support and still make sure they get a reply in time according to the service level agreement we have to create.

Andrew is hoping to use this as an opportunity to explore "hire people who will do great work and not charge American prices". Apparently our current Farsi translator is one such person, and Andrew hopes we find more.

Yep, shouldn't be too hard.

We have four separate directions in mind for this "community manager" notion (not all funded by SponsorL, mind you):

1. Relay operator coordinator. Somebody to keep relay operators happy

and in touch with us, encourage people to set up new relays, organize recommended configurations, etc. Especially important in tandem with our "network diversity" work at #6232. 2) Volunteer-developer coordinator. Somebody to take incoming volunteers and help them find good existing projects to work on. Likely involves making our volunteer page more usable. Should also include knowing enough about every project to recognize and identify good low-hanging fruit, and knowing enough about our priorities to make smart decisions. 3) Blog/forum/mailinglist coordinator, to make sure our users have useful answers, and ultimately to manage and organize the volunteers who make sure our users have useful answers. 4) Social media person, to be our face on twitter, etc.

Which ones are funded by SponsorL?

I believe the plan is for Runa to cover #4, and for us to contract somebody in our relay operator community part-time for #1 to start. I think there is no plan for #2 and #3 yet; but I'd love it if we could get somebody part-time for #2.

Like I've told Andrew already; I am willing to extend my tasks to also include #2 and #3.

...

Runa is wondering why we want funding for languages no one has emailed us in (Spanish and French); though nobody has emailed us in Arabic, either.

Countries like Venezuela are likely to be on more peoples' radar in the coming years. As for French, a lot of North Africa can do French better than they can do English. I bet that's at least partly the case in Vietnam too.

Makes sense.

...

Deliverable 7 is doable. Runa is somewhat unhappy that funding doesn't include Arabic. She says a large number of our users speak either Farsi or Arabic, so not having funding for Arabic translations (and thus relying on volunteers) seems silly; if we have funding for Arabic support, we should also include Arabic translations. Runa has an idea of who to hire for Farsi and Arabic translation, no idea about Vietnamese and Chinese (but can't be too hard to find someone).

There's totally time to write 'Arabic' into the list if we want. Note that just because we promise more languages doesn't mean we get any more money though.

Here's a list of languages the funder thought we might want to put on the contract: "Arabic, Farsi, Mandarin, Vietnamese, Burmese, Spanish".

Sounds good!

On Tue, 14 Aug 2012 10:09:39 +0200 Karsten Loesing karsten@torproject.org wrote:

Mike, Andrew, Roger, Runa: please update the wiki page with your feedback in this thread. Please keep the developer feedback per deliverable as short as possible, ideally in a single paragraph.

We need a better way to have a conversation about these deliverables, for SponsorL now, and in the future as more of these situations come up. My only suggestion is to not use trac wiki and write endless replies in text over or under previous text, maybe riseup etherpad, an actual trac discussion plugin, gobby session, or something else similar.

As much as I dislike IRC as a decision medium, should we have another IRC meeting to discuss current state?