14:29:55 #startmeeting metrics team 14:29:55 Meeting started Thu Jan 18 14:29:55 2018 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:29:55 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:30:25 https://storm.torproject.org/shared/Oh4g0hNenh65QZNWRsIe5zxpB3e0axASeSgo5hKOp2A <- agenda pad 14:30:55 * iwakeh disconnected from storm again, sigh 14:31:00 :( 14:31:46 so, we started collecting ideas related to the metrics team priorities thread on the pad. 14:32:04 irl, want to review what's there, and maybe add something else? 14:35:02 * isabela is around 14:35:07 hey isabela! 14:35:09 hi! 14:35:13 * isabela read karsten's email but havent had the time to reply yet 14:35:15 :) 14:35:15 we're on the pad, want to join us there? 14:35:20 sure 14:35:25 https://storm.torproject.org/shared/Oh4g0hNenh65QZNWRsIe5zxpB3e0axASeSgo5hKOp2A 14:35:44 tx 14:37:06 so i have answers or comments on some of those items 14:37:11 should i write it at the pad? 14:37:21 fine question. 14:37:32 we could also discuss here and update the pad in parallel. 14:37:40 do we have a completeish list? we could take them one at a time here 14:37:44 it was useful to collect some ideas prior to the meeting. 14:38:08 yes 14:38:09 a list of ideas? just what's on the pad. 14:38:27 i mean, do people have lots more to add or are we ready to discuss them? 14:38:33 aha! 14:38:35 ok 14:38:42 The list looks complete. 14:38:43 so i will leave it for the discussion here ;) 14:38:57 I think the list looks good enough. 14:39:03 we could go through it now, if we want. 14:39:13 we should ;-) 14:39:14 ok 14:39:21 ok! 14:39:21 1) borrow people from other teams for specific tasks (teor) 14:39:32 i think 1 will be hard as other teams are still overwhelmed (so that will depend on their priorities too) 14:39:34 this came up in teor's response to the list, and it sounds like a good idea. 14:39:52 ah, hmm. 14:39:59 right now i am having to make a decision regarding that for another task (not related to metrics) 14:40:04 and is being a hard decision 14:40:11 it doesn't have to be for the whole task, like the ooni stats, where they do most of the work and we just finish it off to integrate 14:40:32 yes, i would say it would depend on case by case 14:40:45 maybe this is something where we come up with possible tasks that we could give away, and then we ask. 14:40:50 where no is a valid answer. 14:41:08 but I see how others are overloaded, too. 14:41:35 my question would also be, is this task a feature request from another team 14:41:46 or is it a dependency from a feature metrics is doing 14:42:00 true, ask for support when supporting other teams. 14:42:03 things like that makes a difference 14:42:27 if a team is asking metrics for something - they should indeed carry on whatever they can from the work to get it done 14:42:45 and has the minimum part that is metrics team only done by metrics team 14:42:46 yes, that is already happening, I'd say. 14:43:13 but if metrics team has tasks of their own that can't be done because of lack of people 14:43:50 we need to prioritize the team capacity rather for a longer term solution 14:43:58 yes, that is true. 14:44:02 that would be 6). 14:44:09 yes 14:44:13 I think 1) is mostly a short-term thing. 14:44:23 or, casual thing. 14:44:48 have you done an exercise with the current tasks (that is overwhelming the team) where this can be applied to? 14:45:06 not really. 14:45:12 maybe leave it as a homework then 14:45:32 one example where this would be useful is that teor could help out with reviewing the documentation for sponsor 13 for the ipv6 stats feature he asked for. 14:45:42 but we don't have a list yet. the idea is just too new. 14:45:48 :) 14:45:51 understood 14:45:57 should we drive this by you before we reach out to other teams? 14:46:13 and you tell us if this makes sense or overloads other teams too much? 14:46:31 i dont think is needed.. just hope others will know how to balance their priorities too :) so it doesnt start a snow ball effect hehe 14:46:37 hehe 14:46:39 okay. 14:47:07 so 14:47:10 that makes me think of point 2 14:47:20 yep 14:47:23 2) improve communication with other teams: when they need something, how important is it, etc. (teor) 14:47:26 because after montreal i tried to get communication improved 14:47:29 specially on this point 14:47:40 and i would like feedback from you on how that can be improved 14:47:45 if it helped, or not really, or 14:48:20 I think we have a rough idea about these things. 14:48:23 i also do plan on having in febrauary another round of checking roadmaps etc with all teams 14:48:26 before rome 14:48:57 i think our roadmap was longer term than other teams 14:49:10 that is true. 14:49:19 but it does contain some tasks that others requested from us. 14:49:35 we could revisit these tasks. 14:49:40 I wrote some homework tasks on the pad. 14:49:51 maybe we can say the roadmap is good for the first 6 months, advisory after that and subject to change 14:49:51 https://storm.torproject.org/shared/q_p0wEV7Nh1vlLHJEtogtiT--AgDX1nKBu04Bo9z4Ib 14:50:03 https://storm.torproject.org/shared/q_p0wEV7Nh1vlLHJEtogtiT--AgDX1nKBu04Bo9z4Ib 14:50:13 @irl +1 14:50:14 both links are not necessary for now, but maybe could be used as retrospective 14:50:26 irl: +1 14:50:37 i am suggesting to teams to plan from dev meeting to dev meeting 14:50:38 irl: yes, sounds about right. 14:50:54 so in rome roadmaps are from april till november 14:51:05 in montreal most folks did from november till march 14:51:07 our sponsor commitment is longer than the dev2deev interval. 14:51:24 is ok 14:51:31 you can still map it 14:51:54 okay. 14:51:56 but i would say to focus on that timeframe and make sure that planing is good - is easier 14:52:13 network team mapped longer than march 14:52:25 but the meat of it was the 6 months time frame 14:52:32 this roadmap was also a bit harder to write, not only because it was for 12 months, 14:52:49 but because we did a vision experiment where we took a step back and thought about what we want to achieve. 14:53:00 not directly related to months 1-6 or 7-12. 14:53:01 (which is good too!) 14:53:23 yes, I think so, too. 14:53:34 on to 3? 14:53:44 3) be clearer who in the team works on what and how long they expect it to take, possibly using Trac (karsten) 14:54:01 yes 14:54:05 this just came to mind. it would be nice to have a better idea on who's working on what. 14:54:24 in particular if we add more people (1 or 6). 14:54:31 yep. 14:54:41 what do you think about the suggestions on the pad? 14:54:54 we use 'assigned' and set reviewer here and there. 14:54:56 and that follows roadmap planning, like when you have a month full of tasks, doing a bit of capacity exercise to see if you aren't over promissing will help avoid getting overwhelmed 14:54:57 i already accept tickets i'm going to work on, but not necessarily in the next week 14:54:57 that is, accepting a ticket means there will likely be progress within 1 week. 14:55:13 accepting the ticket and being the owner means it gets pulled into my task queue by a cron job 14:55:32 do you use points ? 14:55:33 in july though, it probably would mean in the next week for me 14:55:40 or time estimation for a task 14:55:49 no points? 14:55:52 isabela: no, we don't. 14:55:58 * irl doesn't know what the points do 14:56:07 maybe we can also pick something else than assigned. 14:56:14 accepted 14:56:17 so 14:56:18 yes, that. 14:56:23 is more than assigned right? 14:56:33 well, agreed assignment 14:56:37 (are they different? ...) 14:56:39 like karsten can have 10 tasks that takes him 3 hours each assigned for the month 14:56:50 or 1 task assigned that will take him 3 weeks 14:57:03 assigned doesn't have a time frame attached. 14:57:24 so points is just a way to calculate how much of your time you are committing to at the end. 14:57:32 maybe, we should do a homework about the trac process? 14:57:37 random thought: if I have a ticket assigned and am not making progress within a week but plan to do so very soon, I update it saying so. 14:57:46 you can create a table fo that, the team decides it, like one point means a week of work 14:57:57 regarding points, I'm not sure whether that will not create more work in the short term. 14:58:22 karsten: afaik that is the best solution to know if you are overcommitting 14:58:33 just having tasks assigned doesnt give you that 14:58:36 yes, and maybe that's something we should do before rome. 14:58:41 true. 14:58:49 makes sense. 14:59:01 i can help you all with it and over time it gets better 14:59:09 also, you dont need to be precise 14:59:37 still, it seems less lightweight as the minor changes I suggested. 14:59:43 more heavyweight* 14:59:48 is ok not to be - is better to have any data at all to guide you and then you learn over time how to better estimate work 14:59:50 I used planning poker before, it was useful. 15:00:05 https://en.wikipedia.org/wiki/Planning_poker 15:00:10 for big tasks, i tend to split these into smaller tickets as i use burndown charts to see whether i'm winning or losing 15:00:12 karsten: is not as heayweight as you might think 15:00:21 see! 15:00:25 yall doing it already 15:00:25 hehe 15:00:51 okay, what should we do in the short term? 15:01:02 to ensure that we're soon making progress on sponsor 13. 15:01:06 wait for a little room iand 15:01:09 i also would be happy to be around in rome and see if we can get it done for the roadmap you create 15:01:15 without leaving everything else behind. 15:01:24 revise the process on trac a little to also include estimation. 15:01:46 the planning poker is quite helpful 15:01:51 and not too demanding. 15:01:53 and do that in rome? 15:02:08 there too but 15:02:14 already before. 15:02:15 karsten: you should triage everything else and start making call of what you can move for latter in order to prioritize sponsor13 15:02:33 iwakeh: +1 15:03:35 ok. 15:03:45 please add things to the pad that I'm otherwise missing. 15:04:23 isabela: what you're saying sounds like it would fit into 4. 15:04:27 4) be clearer to people outside of the team what our priorities are, possibly using metrics-2018-q1 etc. keywords (karsten) 15:04:40 yes 15:04:41 which includes people inside the team, too, of course. 15:04:43 indeed 15:05:35 for that triage, would it help to do another round of keyword assignments as we did in berlin last september? 15:05:40 just, virtually? 15:05:45 so, with the ux team, every week we open our roadmap and go item by item of that month 15:05:59 so we are always reassessing things 15:06:04 how... organized. :D 15:06:26 ;) 15:06:27 * karsten has to admit that he hasn't looked at the roadmap for a while.. 15:06:31 yeah 15:06:39 * iwakeh neither 15:06:39 so i would suggest that 15:06:55 because if a task created tons of bugs and that is taking more time than expected 15:07:06 you know things will need to be readjusted 15:07:18 yep. just happened with the onionoo graphs. 15:07:25 well, tasks usually disclose bugs they don't create them (nitpicking). 15:07:32 hehe 15:07:36 fair :) 15:07:50 we create the bugs, not the tasks 15:07:54 but yeah, always reviewing yoru plan make sure your plan is reflecting reality 15:08:17 reality is reflecting the plan. 15:08:25 at some point in time :) 15:08:38 yep - so that is my suggestion for 5 15:09:16 wait, with the accept-> new 15:09:29 clearing bugs before taking on new enhancements should also reduce technical debt 15:09:40 irl: +1 15:09:43 meaning that when we do get to the enhancements, they'll take less time 15:09:45 we also use accept b/c one person is goind to work on that 15:10:03 and knows more about the task at hand 15:10:25 yes, but if it takes them weeks or months to do it, maybe somebody else should do it. 15:10:28 iwakeh: we could use assigned (you can also self-assign) 15:10:31 thus, it might introduce more work if someone else takes over. 15:10:32 (and I'm totally including myself there.) 15:10:53 true, too. 15:11:26 fine. 15:11:28 and again, it would be fine to reset the timer by saying on the ticket that one is still planning to work on something. 15:11:56 would that be a use-case for points? 15:11:56 I could imagine that after the 3rd such message, one would realize that things might not work out as planned. 15:12:06 how? 15:12:25 I thought, points are reflecting the time left? 15:12:36 left to work on a task. 15:12:53 or, should they stay fixed? 15:12:58 maybe, but not sure. 15:13:08 I'm mostly thinking of tasks that take less than a week to complete. 15:13:23 ah, ok. 15:13:23 and the reason for not making progress is being busy doing other tasks. 15:13:40 (but even if is less than a week points should reflect that) 15:14:02 what is 1 point? 15:14:03 yes, I could see how points could help us, in addition to the assignment part. 15:14:05 (ideally tasks are break down) 15:14:19 irl: that is decided by the team 15:14:28 so capacity calculation is like this 15:15:18 the team has to think how much in a week a person is actually doing code for a task? (because a person has other stuff too, they dont code all the hours they are working, like they are also doing code review for others) 15:15:24 at network team when we did it 15:15:41 we decided taht is actually something around 3 days out of the 5 days of the week that someone is working on a task 15:16:23 then we created a scale like 1 point == 1 day of work (let me find our scale) 15:16:41 so 3 points would be a week? 15:17:21 https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/ReleaseGuidelines#TeamCapacity 15:17:35 irl: you do the values that makes sense for you 15:17:45 or for the team 15:17:47 does trac support fractions? 15:17:49 dont need to copy network team 15:17:52 no :( 15:18:04 hmm? you cannot put in 0.1? 15:18:10 i mean 15:18:12 sorry 15:18:14 irl: we could use percentages instead. 15:18:34 just thinking a lot of the relay search and metrics-bot bugs probably will take ~30 mins 15:18:53 small tasks should be bulk estimated. 15:18:56 using the same scale as other teams might have advantages. 15:18:58 what trac wont give you is burndown chart - so the calculation to see if you going above the capacity (total of points one should have for a month or week) 15:19:05 otherwise this takes longer than the work itself. 15:20:01 anyway, 15:20:06 moving on? 15:20:07 also, for you to train your estimations over time, you should have 'estimated points' and 'real points' (how long it actually took to do the task to see if they match) 15:21:20 like machine learning for humans 15:21:33 yes 15:21:33 this points business sounds useful, no doubt. I'm just a bit worried that it will not help us right where we are now and make things even worse by focusing on process rather than on actual work. 15:22:01 ok, i understand how they would work now, but we can move on 15:22:07 you could start by just looking at your roadmap every week 15:22:25 yes. we should do that. making a note. 15:22:31 but anw :) dont want to hold the discussion 15:22:49 on next week's agenda. :) 15:22:59 we have more ideas: 15:23:00 6) add new people to the team, possibly contractors for specific tasks (web design, technical writing), not necessarily metrics developers (karsten) 15:23:24 so, I think adding a new metrics developer won't make us happy now. 15:23:25 is webdesign, design, or front end coding? 15:23:31 do you have ideas for specific things these people would do? 15:23:35 regardless of whether there's money available, which I don't know. 15:24:00 it's just a suggestion. something that we could do ourselves if we had to, but that we can do faster if we give away some of the work. 15:24:15 for example, for sponsor 13 we need to produce a lot of english text. 15:24:38 and we can write english text, but we're not excellent at it. 15:24:47 hehe, sorry, irl, excluding you. 15:24:50 hehehe 15:25:00 gotcha 15:25:07 hehe, i'm not that great at it either, considering we americanize and do oxford commas 15:25:08 this is the documentation work that iwakeh and I said we'd do. 15:25:09 so the team should come up with headcount 15:25:33 how many ppl for what - and have it listed in priority order 'must have' - 'nice to have but we can wait' 15:25:49 so tor can plan for it 15:25:51 for the fund etc 15:25:58 in debian, the translation team has english translators that translate bad english to good english 15:26:02 do we have that? 15:26:16 isabela: makes sense 15:26:20 (they also make sure it uses simple language for translators) 15:26:23 irl: that sounds very useful. 15:26:43 karsten: next thursday/frida (25/26) we are having a grant/fund meeting 15:26:49 not to rush 15:26:54 oh, good to know. 15:27:07 but if we have that by then we can start making plans for it 15:27:10 right away 15:27:51 yeah, we should have a 'headcount call' for team leads every start of year 15:27:55 another thing is what teor used for one of the community documents. 15:28:03 some tool to check complexity of the text. 15:28:04 i remember i did that once (2016 i think) 15:28:25 yes, I vaguely remember, too. 15:28:50 so, irl, we could ask the community team about translators. 15:28:57 like, colin might have ideas. 15:29:04 translation coordinator. 15:29:07 that sounds good 15:29:27 for debian it's the l10n-english team, and it's just a mailing list, i don't know how we talk to our translators though 15:29:56 yes, that's something that colin would know. 15:30:13 a few years ago I asked a friendly volunteer to review my text for the metrics website. 15:30:19 rewritten text. 15:30:22 that was really useful. 15:30:37 so, moving on? 15:30:39 ok 15:30:43 fine 15:30:45 7) evaluate whether we could get an extension for Sponsor 13 (the current deadline is September 2018? yes.) (karsten) 15:30:54 this is mostly there to have a complete list. 15:31:03 I'd rather not want to do this yet. 15:31:12 but I thought I'd add it for completeness. 15:31:29 hmm 15:31:33 shouldn't be necessary. 15:31:35 sorry got distracted 15:31:40 but for the translation coordinator 15:31:46 yes, you should go to colin for that 15:31:50 ok. 15:31:54 like colin should do this for every team at tor 15:32:05 not should 15:32:08 he is doing 15:32:09 hehe 15:32:16 you the ones that should use his help :P 15:32:25 okay, we'll talk to him. 15:32:29 :) 15:32:49 what are the consequences if we have to extend sponsor13? 15:33:01 also, if its just english review 15:33:05 same money, but distributed over more time. 15:33:06 maybe t0mmy can help too 15:33:09 ideally. 15:33:15 ah, good idea. 15:33:37 extending sponsor13 is normally an easy thing to do 15:34:21 the thing is that sponsor13 only pay us for when a deliverable is done so that means moving dates we estimated we would have certain money around 15:34:32 yes. 15:34:36 but 15:34:46 sponsor13 is not crazy amount of money either 15:35:17 so i would not worry too much on that front 15:35:18 I mean, in this case we would produce value while postponing this work. 15:35:29 good to know. 15:35:37 i would worry more on having a right estimation of how long to extend it for 15:35:45 and presenting a good reason why to 15:35:46 :) 15:35:49 for example, by enhancing onionoo we're helping folks make the tor network better. 15:35:56 yes 15:36:05 changes in the network require work from metrics. 15:36:12 also that. 15:36:20 yes 15:36:33 okay, let's try not to do 7. 15:36:36 that is good stuff to explain to them on why we are asking it for 15:36:42 true. 15:36:50 which ibelieve they will be fine with it too 15:37:01 they are very easy, i have done it other times and is not crazy process 15:37:06 okay. 15:37:20 just need to make sure too the estimation you are asking for is correct 15:37:20 moving on to 8. 15:37:23 8) have a process to provision compute resources for quick hacks that can be done properly later (e.g. some of the bwauth things) 15:37:30 to avoid getting on the case where you ask for a second oen 15:37:32 * isabela done! 15:37:34 hehe 15:37:39 irl: we do have an ec2 account that I could sign you up for. 15:37:42 isabela: hehe, noted. 15:37:46 8 is part of 3 actually 15:37:52 ah, that would be good 15:38:08 I think in 8, irl is asking for actual resources. 15:38:25 oh, then 8 is standalone ;-) 15:38:26 i had to double the size of the digital ocean droplet for metrics-bot so that's currently $10 USD/month instead of $5 15:38:30 iwakeh: do you have access to the ec2 account? 15:38:40 not that I'm aware of. 15:38:49 and then finding a place to run cron jobs and generate output for test metrics is tricky 15:38:50 ah, ec2 is mostly for one-off analyses. 15:39:08 i don't mean to move metrics-bot there, we want that on tpo later 15:39:14 ok! 15:39:22 but to host things like the fastly bwauth maps 15:39:25 I'll sign you up for ec2 then. 15:39:58 in the longer term we'd want that in onionoo but until then it just needs a quick hack to sit somewhere and run 15:40:04 perdulce 15:40:12 or, iranicum. 15:40:17 (for the running part) 15:40:25 or a new VM that we can ask for. 15:40:39 ec2 is for processing large amounts of data that we don't have a free machine for. 15:40:47 so it looks like there's lots of options, do we have some docs for this? 15:40:47 or for running simulations. 15:40:52 not really. 15:40:55 now you know. :) 15:41:20 who do i ask about VMs? 15:41:38 you'd create a trac ticket in the sysadmin component and ask for it. 15:41:50 ok, this seems like a good process 15:41:51 or maybe talk to weasel or qbi first. 15:41:55 and then create the ticket. 15:41:58 whatever you prefer. 15:42:09 last item? 15:42:12 ok 15:42:15 9) gsoc/outreachy (in my experience, this can either reduce workload or massively increase workload) 15:42:34 that also sounds like something we should be doing longer-term, not exactly now. 15:42:41 indeed. 15:42:57 i was a gsoc mentor for debian 3 times. two of those three we got useful output. one of those times we really did not and i ended up doing about half my normal output. 15:43:30 sounds familiar. 15:43:49 the idea would be "make a prototype of this idea we have" as opposed to "make a thing we can put into production when it's done" 15:43:50 but, we might do it in the future. 15:43:57 right. 15:44:11 true. 15:44:33 okay, we're way over time. 15:44:42 yep. 15:44:43 shall we talk about rome next week? 15:45:02 ok 15:45:07 yes, maybe add ideas to the meeting pad until then? 15:45:20 sure. 15:45:30 just one question: you're planning to come to rome, right? 15:45:50 sure, if possible. 15:46:02 * irl has emailed karsten some questions for this, but yes planning to go 15:46:05