15:01:59 #startmeeting metrics team meeting 15:01:59 Meeting started Thu Feb 13 15:01:59 2020 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:59 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:02:04 :) 15:02:05 thanks 15:02:28 I added a few more topics to gaba's topics. 15:02:30 do we have more? 15:03:34 hi everyone! 15:03:39 hi acute! 15:04:06 if not, shall we start? 15:04:17 sure 15:04:23 Review tasks from roadmap session (ticket creation, old cards in trello) 15:04:34 what remains to be done? 15:04:37 i see this topic is so important we will do it twice 15:04:49 just to be sure, yes. 15:04:54 :) 15:05:03 i have created the exit scanner tickets, but did not set the keyword, i can do that after meeting 15:05:11 I created tickets with the keyword. 15:05:12 I have added a topic for Metrics w.r.t network health / metrics of our metrics 15:05:19 i can st the keyword for them as I did not set the keyword for the others 15:05:21 sounds good, dennis_jackson. 15:05:25 I can do it for all of them 15:05:29 irl ^ 15:05:47 gaba: ok, but only the ones on the roadmap 15:05:54 not the extra ambitious ones we are not doing 15:05:58 right 15:06:14 I will do the tasks in that list today 15:06:36 irl: you created all tickets that says NeedsTicket in https://pad.riseup.net/p/0K2Q5uuN0CbjbOGxJQsL-keep 15:06:37 ok, i will review tomorrow and let you know if i think anything is still out of sync 15:06:39 right ? 15:07:08 sorry, that is karsten 15:07:25 I created tickets for O3.1 and O3.2. 15:07:33 acute has been creating tickets for onionperf work 15:07:43 ok 15:07:47 and updating the pad with ticket numbers 15:08:09 gaba: I have been creating tickets for O1/O2 15:08:15 but again, i suggested not to add roadmap keywords because i wasn't sure what the most helpful keyword would be 15:08:33 ok. I will go through them 15:08:37 ideally it is something that helps gaba to keep track 15:08:52 acute: did you create tickets for all lines saying NeedsTicket? 15:09:00 would it be a good idea for acute to ping you once all of the tickets are made gaba? 15:09:13 I will create tickets for the objectives and keep track of all this proposal tickets in the wiki page so far: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor59 15:09:19 yes irl, acute. thanks 15:09:35 karsten: no, not yet - it would be good to decide where we create the OP tickets (trac or gitlab) 15:09:51 i think we abandon gitlab 15:09:53 okay, that's also a topic for today, but we can talk about it now. 15:10:04 acute: for now we will do everything in trac until transition is oficial 15:10:09 we can talk later about it 15:10:10 yes 15:10:57 everything happy with this? 15:11:01 everyone* 15:11:07 \o/ happy 15:11:07 yes! 15:11:10 (: 15:11:19 great! :) 15:11:33 anything else on this topic? 15:11:48 oh, old cards 15:12:00 we should review it again next week and make sure we did make all the tickets and that gaba is happy with the keyword distribution 15:12:21 yes 15:12:33 should we clean up the trello thing and remove everything we're _not_ going to do in Q1? 15:12:48 i didn't touch the trello yet apart from existing onionperf tickets 15:12:52 karsten: yes. I will do it and we can review next week 15:12:59 ok 15:13:02 okay. 15:13:12 next topic? 15:13:18 yes 15:13:23 Check on tickets from network health 15:13:46 those tickets look like placeholders to me. 15:13:56 I want to see if there is any work that metrics needs to do there 15:14:09 this is something geko will be working on 15:14:14 the problem is that network health is still a poorly defined team 15:14:30 and we need to have a clearer idea of the demarcation line between metrics and network health 15:14:33 irl: what do you mean? 15:14:37 it's unclear from these tickets whether there's going to be something for the metrics team to do. 15:14:44 ok 15:14:49 I am curious about the overlap / split as well. 15:14:59 but should we still add more work to Q1 at this point? 15:15:11 karsten: I do not think so 15:15:30 let's watch these tickets and see what work they produce for Q2 or later. 15:15:40 ok 15:16:21 related to network health team work I think geko will coordinate but tehre is work from other teams there. like dgoulet from network team and ggus are involved in it. 15:17:32 alright. moving on? 15:17:50 yes 15:17:58 Proposal 313 - https://lists.torproject.org/pipermail/tor-dev/2020-February/014158.html 15:18:26 I replied with some thoughts. 15:18:51 are there open questions to us? 15:19:07 or what's the question? 15:19:29 mostly to see if anything related to that needs to be discuussed here or we are fine 15:19:37 I think we're fine. 15:19:41 ok 15:20:13 Metric queries for GoodBadISPs https://dip.torproject.org/torproject/web/community/issues/72#note_483 15:20:38 looks like Relay Search questions. 15:20:46 i was in this meeting 15:20:54 ah, indeed, it says irl. 15:21:06 no one has sent an email yet, so i assume they are doing other stuff 15:21:16 last update there was before the meeting, so i guess no update 15:21:42 ok 15:22:13 okay. moving on then? 15:22:13 that PR doesn't implement any of my suggestions 15:22:19 ah, sorry. 15:22:36 we need better data, not just blocks of english text 15:22:55 otherwise we have to build natural language processing and sentiment analysis systems to know if an isp is good or bad 15:23:18 but ok, this is not on our roadmap and maybe they are working on this 15:23:32 yep 15:23:36 sounds good. 15:23:39 i'm ok moving on 15:23:54 moving on. 15:23:55 Monthly reports, are they worth the effort? 15:24:16 Uh, there are monthly reports? On metrics? 15:24:27 there have been, until mid-2019. 15:24:43 they took a few hours to write. 15:24:48 i struggle to keep up with tor-project@ 15:24:52 Ah okay, I was worried I was missing a mailing list. That's exactly when I became engaged with Tor 15:25:01 i don't think i've read a full week's worth of meeting reports in over a year 15:25:28 same here, I'm not reading very many tor-project@ reports. 15:25:44 i guess we are the wrong people to know if they are useful or not 15:25:45 so, my suggestion was: 15:25:47 but I think other people are reading reports 15:25:59 and they are available online as a way to understand what metrics is doing 15:26:06 gaba and I were talking about changing the roadmap cycle from 3 months to 1 month. 15:26:31 where we would not need weeks for creating a roadmap, obviously. 15:27:03 that would be for the time after Q1 has ended. not affecting the current roadmap. 15:27:25 i think with only two people both over-capacity, 3 months is a long time to plan for 15:27:44 now, when we have a roadmap for 1 month, it might be easier to write a quick summary for that month. 15:27:55 yeah that makes sense 15:28:13 I just looked at an old report from July 2016. To me, it seems really nice to have. Even if its just tickets opened / closed / worked on (and what's coming next) It helps people find where the coal face is for the team. 15:28:51 good to hear that they have been useful. 15:28:54 yes 15:29:15 and we can add stuff to the report the last meeting of the month 15:29:23 not having to do it only one person 15:29:30 i used to do these but apparently haven't done them for a long time https://iain.learmonth.me/blog/2018/2018w33/ 15:29:54 I can take the lead on setting up the space for the report each month 15:30:15 for thiings like the feedback process being able to remember what i did and when i did it, such reports would be useful too 15:30:52 ok 15:31:07 interesting that my last weekly report was just before i did a week of travel, i guess i never caught up after i got back 15:31:10 how about we write a 3-month summary for Q1 and then monthly reports starting in april? 15:31:16 ok 15:31:20 ok 15:31:22 sounds good 15:32:12 alright. moving on? 15:32:20 ok 15:32:34 GitLab migration and whether OnionPerf should stay or not 15:32:42 already discussed, I think. 15:32:48 gitlab doesn't even work 15:32:57 you can't make merge requests 15:33:05 so i think there are no arguments for gitlab at this stage 15:33:19 okay. 15:33:41 I'm very much looking forward to a trac replacement, but I'm happy to wait. 15:34:04 right 15:34:08 hiro is working on new server/configuration today 15:34:17 thanks, hiro. :) 15:34:18 and yes, I agree that is better to wait 15:34:29 until we have something stable and migrated 15:34:32 do we need to rescue the issues back to trac quickly? 15:34:54 gitlab still has the onionperf issues 15:35:07 we are in progress of moving them back to trac 15:35:10 irl: yes, I think we should use trac still 15:35:16 otherwise it will be hard to migrate 15:35:19 i mean, is the gitlab data going to disappear? 15:35:25 ok, so remaining tickets that need to be created for OP should go in trac 15:35:26 like when hiro works on it today 15:35:30 if we have data there we will need to move it... 15:35:41 do we have hours before we lose everything? 15:35:45 is it already gone? 15:35:51 ha, no 15:36:19 acute: we might just reopen the closed issues for the ones that we migrated 15:36:26 it will not be gon w without talking with people that may be using it 15:36:32 ok cool 15:36:48 can you put the Trac component back, or do you need help with that? 15:36:51 sorry about this. I should have more clear from the beginning not to use gitlab for trac replacement yet 15:37:06 i think i can do it 15:37:12 everyone is a trac admin these days 15:37:20 makes sense, right? 15:37:31 okay. 15:37:36 next topic? 15:37:44 (component is back) 15:37:45 yes 15:37:54 thanks! 15:37:58 Alternative to MaxMind's GeoLite2 database (#32978) 15:38:10 I think I found something that we can use. 15:39:02 I did a quick comparison of our current data to the new data source, and that was promising. 15:39:23 I got feedback from a few relay operators, mostly positive. 15:39:39 now, I'm not sure about legal questions and licenses and annoyances like that. 15:40:04 I'll bring this up at the next vegas meeting to ask for legal stuff. 15:40:27 ok 15:40:30 it seems to be similar enough, i guess we will get to know where it has its pros and cons 15:40:35 if that doesn't bring up major concerns, I'll move this forward on the ticket. 15:41:03 do you have the database now? 15:41:09 yes. 15:41:22 what is 44.190.21.1? 15:41:49 750654721, right? 15:42:05 huh? 15:42:11 integer 15:42:23 just hoping I didn't screw up the conversion. 15:42:38 i have never configured an ip address by integer 15:43:11 US. 15:43:17 err no 15:43:29 wrong continent 15:43:31 heh 15:43:44 but ok this is a strange one 15:44:15 I can share details with you. I just don't want to announce this publicly until we have a rough idea whether we can use it at all. 15:44:28 ok, by email is fine and i will see if i can take a look 15:44:34 great! 15:44:51 hopefully I can move this all back to the ticket by the weekend. 15:45:06 or early next week. 15:45:09 okay, moving on? 15:45:16 ok cool 15:45:29 Onionoo 8.0 release and deployment preparation 15:45:38 we said we'd deploy 8.0 in 7 days. 15:45:55 can you review the changes before that? 15:46:02 they're small, IIRC. 15:46:11 i am working through reviews 15:46:16 i would say probably tes 15:46:18 yes 15:46:48 I'm not sure if everything's under review yet. if not, I'll prepare it for early next week. 15:46:56 cool! 15:47:15 next and last topic? 15:47:40 Metrics of Metrics / Network Health 15:47:44 dennis_jackson: ^ 15:48:03 This is in part brought on by the discussion in #33076 15:48:11 And also the earlier Network Health team tickets 15:48:58 I realise the roadmap is already pretty intense for the next 3 months - so this is more about ideas and future direction than anything else 15:49:43 So - what kind of metrics do we check about the metrics we gather? 15:50:16 do you mean like to verify the metrics, or instrumentation of the software we run to generate them? 15:50:57 Both really. For example, the uptime of the four onionperf servers is in the latter category 15:51:09 And the number of successful measurements in the last 24 hours in the former category 15:51:34 Are there targets (of any kind) for these things? Documents with the goals set out? 15:51:48 both of these are metadata you can derive from the onionperf data 15:51:58 i am a big fan of in-band metadata 15:52:17 we don't have anything that looks like an SLA or targets, other than doing the best we can 15:52:25 Yes, absolutely, my point is more about a) is anything / anyone looking at this? b) Does Tor Metrics have any kind of targets for them? 15:52:35 Ah okay 15:52:38 we have several checks in collector to warn us if anything looks stale. 15:52:44 we are working on some operations documentation that starts to document what to do when things go wrong, and what we check 15:52:52 Would something like this be helpful? 15:52:53 but, best effort, not systematically. 15:53:01 sounds like a fun grafana dashboard 15:53:03 I worry the Network Health team want to know what Metrics can offer 15:53:12 And Metrics want to know what Network Health need 15:53:45 Refining some kind of target / spec might be the way to help out both teams. 15:54:10 a way* 15:54:52 Is something that might be useful to move towards? In 3,6 or 12 months time? 15:55:20 I can also see arguments that it might be a distraction, not turn into a useful output, be quickly out of date, etc. 15:55:29 i don't think this would be useful to metrics 15:55:40 but that doesn't mean we shouldn't do this, if it would be useful to someone else 15:55:46 but they have to make a case for that 15:56:13 yep. 15:57:04 does that make sense? 15:57:16 we're approaching the 60 minutes. 15:57:20 I think it would be useful to understand how useful the data is. It is also something that may be helpful in the new metrics portal 15:57:28 Okay, I think so. 15:57:46 I am still getting a feel for how Tor works / how sub units relate / manage their time. 15:58:11 And I appreciate how hugely busy the metrics team is with a lot of asks from all over the org 15:58:39 :) 15:58:59 alright! let's end this meeting in time! 15:59:02 #endmeeting