23:00:08 #startmeeting network team meeting, 2 April 2019 23:00:08 Meeting started Tue Apr 2 23:00:08 2019 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 23:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic. 23:00:12 hello folks! 23:00:17 hi 23:00:59 hi! 23:01:22 https://pad.riseup.net/p/tor-netteam-2019.1-keep is the pad 23:01:37 thanks for sending last week's notes, teor! 23:01:52 no worries 23:02:48 I've seen catalyst, gaba, teor4. ahf plans to be offline, and I bet asn does too. 23:02:51 any word from mikeperry ? 23:03:49 I talked to mikeperry yesterday, he said he is very overloaded and so it's easy to miss things 23:04:01 I meant, is he likely to be at this meeting? 23:04:27 If not, it's just the 4 of us, with dgoulet on break and juga likely asleep too :) 23:05:13 Let's look at the 040-must page 23:05:33 I think it's likely that mikeperry will miss the different meeting time, or meetings in general 23:05:40 I see two tickets assigned to me, but I think I can remove "040-must" from #29819 23:05:43 ah :/ 23:05:46 (with Europe in DST, it's even more likely people in Europe will be asleep at this hour) 23:05:49 (since it is a libseccomp bug) 23:06:38 mikeperry asked me to reassign all his 040 bugs and reviews, how should I distribute them? 23:06:51 let's do reviews first 23:07:00 I could do #29527, if it's an easy review 23:07:07 I can't do #29357, since I wrote the code 23:07:35 * nickm also just closed #29986 as 'invalid' since it appears to have been created in error 23:08:01 * nickm assigns self as reviewer on #29527 23:08:37 teor, catalyst: either of you have time to review #29357? Otherwise I can ask asn and ahf in the morning. 23:09:12 I always have time for high-priority things. But it's the roadmap coding that suffers. 23:09:48 I can do #29537 23:10:00 #29375 23:10:05 #29357 ? 23:10:06 oh dear 23:10:16 yes, that one 23:10:21 thanks; setting you as reviewer 23:10:34 now let's look at the unassigned tickets in 040-must... 23:10:55 question 1 is "are these all truly release blockers" 23:11:28 I hate leaving in CI failures 23:11:58 I can do a quick fix to #29500 23:12:12 changing ticket now 23:12:17 that would be lovely; feel free to set me as the reviewer 23:12:31 For #28223, I'll have a look though I can't promise much. 23:12:47 I don't think #29034 is a release blocker: It can be done in 0.4.1 and backported 23:13:17 since it's an 035-backport and it didn't block 035, I don't see why it should block 040 23:13:26 We don't have 3 points of time before 040 23:13:42 * nickm removes 040-must from #29034. 23:15:27 yeah. But at least this release is on track to come out _closer_ to "on schedule" than previous releases 23:15:32 and that's real progress 23:16:20 nickm: do you think that #29875 and #24367 are release blockers? They stop users changing bridges at runtime. 23:16:43 (ahf has his 040-must ticket listed on the pad. good; thanks, ahf!) 23:16:51 teor: when did they break? 23:17:31 teor: it looks like these have been broken since 0.3.2.7; they don't block 0.4.0 23:17:44 When we patched #24367, they broke 23:18:01 teor: if that's so, we can/should fix them post-release and backport carefully 23:18:10 Ok. Do we want to mark them as Sponsor 19 must? 23:18:11 (depending on usual backport factors) 23:18:12 IMO 23:18:20 teor: sure 23:18:55 i can do some reviews in the morning if that will help others! 23:18:57 and hi o/ 23:19:04 ahf: hi! We thought you would be asleep! 23:19:09 (Sleep is good) 23:19:22 i should be, but my sleep schedule is being off a bit :-) 23:19:47 still on mexico timezone? :P 23:19:55 gaba: yep! 23:20:00 i've decided that i like that one 23:20:05 :) 23:20:33 Ok, so I think 040 is pretty reasonable now. 5 fixes needed, 5 reviews needed. 23:20:45 on to the kanban! 23:20:59 I'm on #29210 and meaning to do #29223, so my part is accurate 23:21:25 everyone else, please make necessary kanban updates 23:21:55 * gaba added all the april tickets to the backlog (moved them out of the icebox) 23:21:56 Weird. I keep changing my part of the kanban, and it keeps changing back. 23:22:11 ha! what is your part of the kanban? 23:22:20 gaba: we are going to move anti-censorship items away from the network team roadmap, right? like, not the little-t-tor tickets, but all the snowflake/pt/bridgedb stuff? 23:22:28 yes ahf 23:22:29 The tickets assigned to me 23:23:04 you should have something in progress teor? 23:23:07 teor: btw, how far are we from merging #29267? Is it just waiting for you to have time for another review, or is it blocked on something else? 23:23:13 oh wait 23:23:14 never mind 23:23:17 I misread that ticket 23:23:19 I meant: 23:23:38 How far are we from merging #29280? 23:24:22 catalyst: let's check in briefly about #29210 23:24:46 gaba: If I want to have a roadmap task in progress, I need to stop doing merges, CI fixes, 040 fixes, sbws reviews and fixes, backports, and reviews. I have been doing those things for the last 2 weeks. 23:25:02 I'm planning to spend this week refactoring the API by which commmands work, so that parsing and execution are separated. Then we're in good shape to move the commands to more logical places in the code. 23:25:11 which one is the card that moved back? teor 23:25:29 But before we do any movement, it would make sense to merge your patches that refactor how replies are sent 23:25:40 So I'll hold off on movement 23:25:45 #29005. Which I am definitely not doing right now. "gaba moved this card from BACKLOG to IN PROGRESS. a day ago" 23:26:06 nickm: yes, that would be good. did you look at my branch? i think i'll have to redo parts of it though 23:26:49 * catalyst starts making a new child ticket 23:27:31 Yes, some of it, last week. I think that the part about changing the output functions could be separated from the work with pubsub+events refactoring, or at least merged independently 23:27:54 yeah the pubsub+events refactoring should be a separate child ticket probably 23:28:21 maybe we can do review on a single event first, to make sure we like the patterns, and then move on to the rest? 23:28:27 up to you 23:29:08 gaba: I haven't been doing roadmap coding, because I have always had higher-priority tasks. I need to know which high-priority tasks to stop doing, so I can do roadmap coding. 23:29:45 I also need to know if you want to manage my tasks on the kanban, or if I should? 23:30:22 gaba: On the kanban, where should I put stuff that I am _not_ able to work on right now? 23:30:28 It would be better if you can manage them yourself. We can do it in the weekly meeting. No need for other tieme. 23:30:29 Is there a "stalled" category? 23:30:33 nickm: back to icebox 23:30:37 i mean backlog 23:30:38 sorry 23:30:47 ok 23:30:51 nickm: they shoulsd be back to backlog and we prioritize them 23:31:08 I've moved #29269 where I think it would be better to pass it to metrics/anticensorship... 23:31:28 and #28878 where I am waiting for review on one ticket so I can finish another 23:31:32 speaking of... 23:31:51 ok. You want to be removed from #29269 ? 23:32:15 gaba: I want to pass it on to metrics+anticensorship. metrics has all the stats; anticensorship knows what they need 23:32:53 so somebody from those teams do it, right? (i want to be clear I understand what you mean) 23:32:58 catalyst: Are you blocked on reviewing #29668? It's blocking #26288, which is blocking #28878 23:33:22 nickm: we can talk about it at the meeting on thursday 23:33:23 It's mostly a thread thing instead of a crypto thing, so it doesn't need a crypto person to review it 23:33:29 i'll add it to our discussion list 23:33:38 ahf: if you remind me I'll be there to answer questions 23:33:56 nickm: sorry, i keep forgetting that it's blocking stuff. feel free to reassign the review 23:34:09 ahf: you asked for a review. Want #29668 ? :) 23:34:10 cool! we can also talk about it prior to the meeting if you have something that is colliding that day 23:34:22 nickm: it touches thread stuff i'm less familiar with so reviewing it will be slow for me 23:34:44 nickm: i can take that one, i did my (very easy) reviews for this week yesterday and they took ~20'ish min in total, so i can take one more this week 23:34:55 ok, reviewer changed 23:34:57 thanks! 23:35:06 will look at it after i've slept 23:35:09 good idea 23:35:17 could i suggest bumping up priorities on stuff in needs_review whose review is blocking stuff? 23:35:30 done 23:36:02 we have 25 minutes left, and I'm afraid I have a hard-stop tonight. 23:36:17 everybody please take a look at rotations and reviews, and we'll move on to discussion? 23:36:36 ok, added #29269 as discussion point for anti-censorship team meeting 23:36:41 ahf: ty 23:36:44 yes catalyst 23:37:09 mikeperry is unlikely to do CI + Coverity this week 23:37:46 I'll try to keep an eye on them 23:37:51 Our review backlog goes back at least 5 weeks 23:38:20 well, #26288 is backlogged on purpose -- I'm going to look at it again when dgoulet is about to get back, so I can remember whatever I said 23:38:41 but yeah 23:39:29 Ok, so most reviews are less than 2 weeks old 23:40:20 We have 20 minutes left, and I want to talk about how we deal with people getting overloaded? 23:41:16 So for me in the past, my biggest cause of getting overloaded was that I decided that everything was my responsibility and I was going to make it all work 23:41:37 That was a cool theory but it meant that I drained myself and burned out 23:41:56 I think we need to work hard on respecting our capacities and advertising _early_ when we're over them 23:42:01 +1 nickm. I had the same in the past 23:42:35 We each have 35-40 working hours each week. We shouldn't allocate more. We're not getting more people for a while... 23:43:00 so holding work capacity constant, the only flexibility we have is in what we prioritize. 23:43:17 I used to burn out by going over 40 hours a week. Now I don't do that, but I still find particular tasks very draining if I do them for a week or two in a row. 23:43:38 teor: like, a single ticket, or a release focus, or just tasks in gneral? 23:43:59 gaba: Would it be worthwhile to revisit the roadmap and figure out how to revise it soon? Otherwise we're going to slip more and more and not update it 23:44:12 hm 23:44:35 Sometimes it's a single ticket that I'm stuck on. Recently, it's been a lot of very small tasks, including a bunch of necessary admin and HR tasks. But also I have been managing backports and 040 bugs, which is a bit tiring. 23:45:11 teor: Another way to look at it is to realize that those 35-40 hours are not uniformly useful. If you're burned out on something that should theoretically be a high priority, there's no guilt in working on something fun for a few hours instead. 23:45:12 So maybe I shouldn't be managing any more than backports. (I'm happy to keep an eye on 040, but I'll need help with that.) 23:45:44 I think 040 is supposed to be my responsibility; I'll try to hold it up to your high standards. 23:45:50 nickm: yes, we may need to do that with s19 too (bridge has some tickets without owners). We can do that after I get s19 out fo network team roadmap 23:45:58 I _like_ the wiki page approach you made; I think it will help me manage the rest of 040 23:46:20 nickm: I think managing a release is much easier when we have a shared view of the tasks that are in and out of the release. 23:46:33 (And where they are at.) 23:46:58 nickm: we can schedule a session at the end of April to revisit the roadmap (once dgoulet is back and we have sponsor 27 roadmapped) 23:47:12 nickm: you might also want to take a look at https://trac.torproject.org/projects/tor/wiki/user/teor 23:47:25 could we do it maybe a bit earlier in relationship to dgoulet's return? s19 ends in end of may iirc 23:47:37 or maybe we should just do s19 with anti-censorship team meeting instead from now on? 23:47:41 and not have the odd split 23:48:16 I probably need to split my user tasks page: it started out small, but now it is huge. So it's hard to get an overview. 23:48:29 yes ahf 23:49:17 People in the team deal with overload in different ways. And that causes conflict. 23:49:41 I tend to focus on the tasks that help the team. But that gets exhausting after a while. 23:49:55 Other people tend to focus on roadmap tasks. But that slows other people down. 23:50:12 And when we don't communicate what we're doing, then people don't know why. 23:50:32 teor: i agree with a lot of this 23:51:05 teor: unfortunately IRC seems like maybe a not-great medium for this conversation to me? 23:51:08 Long-term, I want us to plan better so overload is rare. 23:51:58 Ok, I just want to say two more things, than we can decide how to progress the conversation? 23:52:07 teor: yes. there are hidden costs to overload... 23:52:14 teor: sure 23:52:15 but, can we identify these periods? is the current thing related to the common thing that we will do twice a year with alpha->rc->release stabiliziation? 23:52:34 Short-term, I want us to decide on a shared set of priorities, and actually stick to them. 23:52:35 and/or is it related to that we are (maybe) too few people right now? 23:53:12 how does people priorities here? the last couple of weeks i've tried to prioritize "weekly tasks" such as reviews, then 040 related $things, then roadmap 23:53:20 Because we reward large roadmap tasks as a team. So I am concerned that working on too many small, shared tasks is bad for me long-term. 23:53:22 (done) 23:53:53 (not arguing, but seeking more information) in what way do we reward large roadmap tasks? 23:53:56 teor: yes, i've definitely felt that pressure 23:54:13 I was looking today at all the tickets that were closed in March (to check on velocity) and most of them are not sponsor related. 23:54:28 ahf: I think I have been working on CI, sbws, 040, merges, backports, and then reviews, and then never getting to roadmap. 23:55:01 teor: also CI focus outside of the periods where you have had the CI role? 23:55:20 Yes, because it's hard to merge and backport when CI is broken 23:55:35 right 23:55:36 ahf: same for me 23:55:45 (t 23:55:51 (though for me it's that it makes reviewing harder) 23:55:56 ahf: I think we also have a big roadmap, and not enough people 23:56:08 I also find reviews and new code hard when CI fails 23:56:09 (and there's a lag after we fix CI, because people have based their branches on master with broken CI) 23:56:53 nickm: we reward large roadmap tasks by recognising people who complete them as competent engineers, and rewarding them with more large and interesting tasks 23:58:06 I also think we reward people by working with them, but I also think there are many more factors that make teamwork easier or harder 23:58:12 teor: +1 23:58:55 And I am concerned that our feedback, promotions, and raises process will skew towards large tasks. But I don't know that for sure. 23:59:46 I think is very hard to have this conversation over irc. I'm reading what you are all saying and still not sure how we would move in. 00:00:07 I was just typing an answer to that 00:00:18 yeah, i also see the data points in this, but i have a hard time thinking of good solutions :-/ 00:00:33 well, it's a peer feedback process. If somebody is charging ahead on the roadmap while not meeting their responsibilities to other people, I hope that their peers will tell them 00:00:38 We make it easy for people to focus on roadmap tasks, because we don't check progress on weekly or long-term tasks, and do handovers on those tasks. (Or offer help when those tasks are slow.) 00:01:03 i think right now the network team is affected negatively by being one person down and many of us also trying to startup the anti-censorship team, but those things are temporary and should go away at some point 00:01:33 I agree that it's harder now. But I think these are systemic issues. 00:01:43 nickm: yeah, i also feel that the peer review process would be an opportunity for spotting important non-roadmap duties that some people are very good at and telling people that they are doing a good job with that 00:01:52 like meta-development skills or whatever you'd call them 00:01:55 That as well 00:01:58 For example, we don't know if the people doing last week's rotations actually did anything. Or if they were too busy, and left a big backlog for the next person. 00:02:18 None of these things are about blame. But if we don't monitor, we can't help. 00:03:01 network-team: if you're not here, please read the above discussion. Ther are a lot of important points in it 00:03:25 teor: do you have any suggestion on how we can move this to a way that it can resolve sytemic issues? 00:03:26 I'm trying to brainstorm what we can do in the next negative-three minutes left in the meeting... :( 00:03:31 So gaba, I suggest we track progress on all of our tasks, rotations, long-term roles, so we catch things early. 00:03:46 not only on roadmapped sponsor stuff 00:03:52 Yes 00:03:57 teor: it's definitely a systemic thing in my view, and hardly unique to our team 00:04:06 teor: how? with points or? 00:04:13 like "today i've spend 0.4 points on CI" ? 00:04:18 With pages like this: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases/040Status 00:04:25 I think we need to keep talking about this in future meetings too; we're not going to solve it tonight. Maybe we should brainstorm a bunch of ways to keep track of this stuff, and see what's a good fit? 00:04:31 And queries like this: https://trac.torproject.org/projects/tor/wiki/user/teor#Backports:0.5daysperweek 00:04:37 nickm: yeah 00:04:44 Maybe assembling a bunch of ideas will help us 00:04:48 I agree that we need to make all the work visible 00:05:08 Some tasks aren't in tickets, so that's harder. But 80% is probably good enough. 00:05:16 teor: I am super sorry, but I need to go. I'm going to #endmeeting since I think it needs to be the meeting-starter who does that, but everybody who is still here should feel free to keep talking... 00:05:29 thanks nickm 00:05:33 thanks nickm 00:05:34 teor: and thanks again for bringing this up. we need to hear it. 00:05:37 #endmeeting