17:01:45 <hellais> #startmeeting
17:01:45 <MeetBot> Meeting started Mon May 16 17:01:45 2016 UTC.  The chair is hellais. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:45 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:01:57 <anadahz> let's start this meeting :)
17:03:01 <hellais> sounds good
17:03:18 <hellais> so we have some agenda items from last week that didn't get addressed and I suggest we go through them
17:03:38 <willscott> can you remind me what they are?
17:03:39 <hellais> #topic Discuss the possibility of changing the behaviour of ooniprobe on first run
17:03:45 <hellais> willscott: https://lists.torproject.org/pipermail/ooni-dev/2016-May/000425.html
17:04:25 <hellais> so basically what I am thinking here is that a lot of people seem to be a bit confused as to how they should be running ooniprobe. Having a bunch of different commands to get it setup in a way that is useful makes things also even more complicated.
17:04:30 <willscott> yes. having oonideckgen and resources go automatically on first run would be much less confusing
17:04:58 <hellais> already since 1.4.2 ooniresources is actually no longer necessary and is already part of running oonideckgen.
17:05:22 <hellais> I am thinking of going even one step further by having the first time you run ooniprobe be an interactive prompt of some sorts that tells you:
17:05:45 <hellais> 1) What are the risks of running ooniprobe and that you should be aware of them before proceeding
17:06:30 <hellais> 2) Asks you if you would like to generate a deck and if you would like to specify the country or ooni should guess it for you
17:06:45 <hellais> 3) Asks you if you would like to configure a cronjob to run daily measurements
17:07:34 <hellais> (possibly in 2) there could also be something where you can select the tests that you should run)
17:07:43 <willscott> that seems like v2
17:08:08 <willscott> getting just that seems like it would get people onboarded much faster
17:08:25 <hellais> my only concern about this is that if there are people that are scripting ooniprobe this will break it for them unless they are aware of some option we could add to disable the interactive prompt on first run
17:08:38 <willscott> the only other thing i can imagine in that setup is checking you've got a working tor configuration (point to bridges / control port if needed, etc.)
17:10:09 <agrabeli_> I would suggest adding whether users would like to specify their tests in step 2, and adding the question of whether they would like to specify their country in the following step
17:11:08 <willscott> we can probably grab the simply secure / other usability people's time at some point to get input on what an appropriate user flow would be
17:11:54 <willscott> eventually this can be intuitive, i'm happy with a first version that asks whatever questions as long it's at a point where a remote user can start it up while on a chat with someone who knows what's going on
17:12:09 <willscott> i think manually entering cron-jobs pushes that limit :)
17:12:42 <anadahz> hellais: we can add a non-interactive detection check to ooniprobe so when there no shell prompt to run non-interactively and thus not breking scripts or cronjobs
17:13:10 <anadahz> s/breking/breaking
17:14:48 <hellais> willscott: yes we should try to minimise the user interaction to the least required
17:14:50 <anadahz> for the prompts 1-3 ncurses will be a nice fit
17:15:20 <hellais> anadahz: I am not sure it's really possible to detect reliably if you are inside a non-interactive environment.
17:16:21 <willscott> there can be a flag that forces non-interactive. non-interactive usage should be able to set that
17:16:22 <anadahz> hellais: I think it's working quite well, many linux daemons do this check upon first start
17:17:06 <hellais> ok it's worth investigating, but I think having a non-interactive mode is perhaps more robust.
17:17:29 <hellais> I would say we agree that this is a neat thing to have and move discussing the implementation details to a ticket
17:17:39 <hellais> #topic Discuss deprecating dns_consistency, http_requests and tcp_connect once web_connectivity is merged
17:19:16 <anadahz> Shall we postpone this since andresazp is not around
17:19:18 <anadahz> ?
17:19:56 <willscott> i imagine this will be an ongoing thing for a while?
17:19:59 <hellais> I think we can talk a bit about it now and perhaps when he will be here we can talk more about it
17:20:04 <willscott> are there reasons not to do it?
17:20:46 <anadahz> willscott: only backward compatibility
17:20:47 <willscott> or (put differently) can we migrate past tests to back-fill results of what we expect to get out of web_connectivity from those previous tests
17:20:51 <willscott> yeah, that seemed liek it
17:20:52 <hellais> so the rational behind this is that dns_consistency, http_requests and tcp_connect generate a lot of data that is very hard to cross correlate amongst different test runs.
17:22:00 <hellais> since web_connectivity includes all of these features I for things that are aimed towards port 80 and 443, with the added advantage of being able to actually map properly between input and specific reason for failure I think we should drop the other 3.
17:22:53 <hellais> new tests that are interested in testing things that are not web related should be implemented as new tests and have their own tcp/dns/whatever layer 7 protocol tests be part of their test
17:24:39 <anadahz> I agree with deprecating the old dns_consistency, http_requests and tcp_connect tests. Though we should keep accepting reports from these tests since we have a big amount of older ooniprobe versions submitting reports.
17:27:47 <agrabeli_> agreed
17:27:58 <hellais> indeed, currently our collectors don't enforce any policy on the types of measurements that are being collected
17:28:59 <willscott> so this seems good
17:29:25 <willscott> we should ask andresazp for comments on the move as well
17:31:04 <hellais> so these were the two things we had on the agenda, are there any other things you think we should be discussing?
17:33:15 <willscott> it looks like there's an ooni job post up: https://www.torproject.org/about/jobs-ooni.html.en
17:36:05 <hellais> willscott: I think you are right :)
17:40:09 <hellais> is there somebody else here that is not anadahz, agrabeli_ or willscott that would like to ask questions about the job posting?
17:44:09 <meejah> FWIW, the posting doesn't say if it's full-time etc
17:46:08 <willscott> yep. arma also noted that it might be worth explicitly stating salary since it's pre-set and not something we probably want to negotiate on
17:46:42 <meejah> that sounds like a good idea, esp. if it's non-negotiable ;)
17:47:29 <meejah> (or, if you want to be cage-y like most employers, ask applicants for saraly expectations to see if they'll be "really sad" or "really happy" w/ wage ;)
17:49:08 <willscott> i guess a lower salary might help support the grappa fund ;)
17:49:27 <meejah> personally, i hate that behavior of employers, so just stating it is a) better and b) looks more progressive ... :)
17:50:26 <meejah> obviously i don't know what flexibility you have, but perhaps you could change the *term* of the contract if you wanted? e.g. with funding X, it could be 12 months for "more junior" devs, vs. 8 months for more-senior...?
17:51:27 <hellais> meejah: yes that is a very good point, we should absolutely add a mention to the fact that it's full-time.
17:52:17 <hellais> I think we mention it in the blog to be posted, but it should also be put in the posting.
17:57:29 <willscott> anything else?
17:57:41 <willscott> otherwise we can end in 1hr, which i believe is stated meeting length :)
17:57:54 <hellais> that sounds good to me
17:58:13 <hellais> thats all folks, thanks for attending
17:58:24 <hellais> #endmeeting