18:02:27 #startmeeting browser-team-task-reorg 18:02:27 Meeting started Thu Aug 1 18:02:27 2019 UTC. The chair is pili. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:27 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:02:41 fun fact reorg is an anagram of georg :P 18:02:49 not quite 18:02:53 :) 18:04:00 ok, let's pull up the pad 18:04:25 https://pad.riseup.net/p/zZXcPo4EZ4UJE6b8a9ef 18:05:01 GeKo: how did you want to do this? we just go down the pad and confirm we're good with the tasks and owners? 18:05:20 works for me 18:05:35 ok, so let's start with triaging tickets 18:05:39 i think the items on the pad could be a first try to make general tor browser work visible 18:05:48 not just what i am doing now 18:05:49 how do you do this right now? do you respond a couple of times a day? 18:05:59 yup, that's a good idea also 18:06:06 i wonder whether this would be useful for everyone to do 18:06:09 so everyone should feel free to add tasks that they do? 18:06:14 and then we could see where the gaps are 18:06:15 that are not "coding" 18:06:44 or even coding (like in particular areas) 18:06:47 right 18:07:00 so we could figure out review expertise etc. 18:07:13 okay, ticket triage 18:07:27 i usually triage tickets as they come in 18:07:38 at least once a day i think 18:07:49 it's one of my tasks in the morning 18:07:54 ok 18:08:05 so any tickets that have built up overnight you'll respond to? 18:08:18 i try to understand what's going on and figure out whether that#s something new 18:08:19 yes 18:08:26 and then dupe things over or not 18:08:31 Do you look at all new tickets in trac? 18:08:38 (not just Tor Browser?) 18:08:41 yes 18:08:50 That’s what I guessed 18:08:53 but tbb bugs closer 18:09:22 but i get all the reports and figure out whether they are relevant for the browser or not 18:09:23 :) I've started doing that too since _someone_ pointed out that there was a tor-bugs list 18:09:31 :) 18:09:56 then i try to get back to the user immediately either by requesting more info 18:10:07 or at least by categorizing the ticket with keywords 18:10:08 ok, so what I can do is, as part of my email backlog clearing every morning is to take over this routine 18:10:20 and maybe mcs you can also do that at the start of your day? 18:10:30 and escalating it if needed into either our monthyl ticket pile 18:10:37 and I can ask boklm if I'm not sure about something 18:10:38 or higher in the sense that i start working on it 18:10:47 Sure. It would be good to have people to “cover” when we know another person is going to be away too. 18:10:51 and while doing so whether i can pass on the bug to someone else 18:10:54 as he's most likely to be around at the same time as me 18:12:18 any other points on triage? 18:12:35 shall we move on to roadmapping? 18:12:50 i think it's whorthwile thinking about backup during vacationtime 18:12:54 yup 18:12:55 *vacation time 18:13:00 * boklm usually watch the #tor-bots channel for tickets updates during the day 18:13:02 any volunteers? ;) 18:13:11 or do we want to do it ad-hoc? 18:13:23 i guess ad-hoc depending on who is afk 18:13:39 i'd be willing to help triage 18:13:40 i.e I guess boklm can be my back up if we're not on vacations at the same time 18:13:57 yes 18:14:05 might be helpful to clear out the list at the end of the day since I'm west coast 18:14:44 Should we have a goal for initial response time? 24 hours or less? 18:14:55 (or even shorter?) 18:15:06 I think 24hours is more than reasonable :) 18:15:11 I think that would depend on priority 18:15:20 Is it critical or major? 18:15:21 we should have coverage to be able to do that anyway 18:15:24 sisbell: true 18:15:49 well you need to triage in order to figure out prio :) 18:16:22 the only gap will be the weekend 18:16:28 but we can try it and see how it goes 18:16:39 when should we switch over the triaging responsibilities? 18:17:33 * GeKo stays silent 18:17:59 :) 18:18:04 but i am fine waiting with it, say, after 9.0 18:18:11 or we could try things out next week 18:18:14 while i am afk 18:18:31 ok, I can do it while you're afk "informally" ;) 18:18:38 which will be from 8/7 8/17 18:18:39 and we'll start more formally after 9.0 18:18:47 wfm 18:18:48 although I'll be afk for some of that also... :/ 18:18:50 I forgot, sorry 18:19:11 but that's good because we can try out the back ups ;) 18:20:15 ok, I think we're good 18:20:20 let's move on to roadmapping 18:20:53 so this probably needs to be done once a month before the next month 18:21:04 and we can also build in the estimation process at this point 18:21:21 so maybe everyone should be involved? or is that too much? let's discuss.... :) 18:21:33 yes, i feel we can adjust that process while doing the team capacity estimation 18:21:38 e.g last monday of the month we roadmap for next month 18:21:43 I think you (pili) need to take the lead but all need to help 18:21:54 mcs: yup, I'm happy to do that 18:22:41 any other comments on roadmapping? are we ok if I bring a preliminary roadmap to the last meeting of the month 18:22:46 then everyone helps to fill in points 18:22:55 and we check that we're not overcommitting? 18:23:10 I will also check how the network team does this 18:23:19 sounds good 18:23:22 in case they have a better way 18:23:39 ok, 1:1s 18:24:00 yeah, i am behind on that mainly because of the time-consuming feeback process 18:24:13 it was meant as a way to compensate the lack of it 18:24:18 *feedback 18:24:24 I can do them and it might be good if sysrqb does them with me too? 18:24:39 i am not sure how we should reorg that taking the org-wide feedback process into account 18:25:11 well, it depends, maybe some people would like more regular 1.1s 18:25:18 and if so we should negotiate this :) 18:25:42 yeah 18:26:09 ok, but in any case, I think if sysrqb doesn't object we can take this on jointly 18:26:21 he should be at least part of it 18:26:30 next one is feedback on different channels, e.g irc, blog, etc... 18:26:42 I feel this is part of triage 18:26:46 I can take on looking at android reviews 18:27:11 thanks sisbell that will help 18:27:12 I'm doing that anyway just to get a sense of bugs 18:27:31 I can open issues in trac for what I see in the reviews 18:27:38 great :) 18:27:52 feedback ie responding to user feedback? 18:27:54 pili: it is 18:27:59 so I think if we make this part of the triaging routine we can use the same people for this 18:28:09 + sisbell for android 18:28:14 which is why looking at blog comments is part of my morning routine as well 18:28:23 (+ all the other channels we have) 18:28:59 I think it will be more difficult to share the feedback task among several people. 18:29:10 yup 18:29:24 With Trac we can see from bug activity whether someone else looked at an issue (usually). 18:30:01 maybe we can make it more visible somehow 18:30:22 for irc you can see if someone has replied already 18:31:13 for the blog, if a ticket is raised as a result of the blog comment, there should be a reply stating this fact 18:31:18 I guess the problem could be consuming lots of noise to find out someone else has already done it? 18:31:45 yup 18:32:15 so, in general, I think if feedback is actionable then we should create a ticket and respond to the feedback with the ticket number 18:32:31 what we need is for other team members doing triage to be aware that this has happened 18:32:33 right? 18:32:42 yes 18:32:47 agreed 18:33:04 Maybe just put that on the weekly standard up board 18:33:12 Right at the top 18:33:54 we can try that and see how it goes, hopefully it's not too long to wait :) 18:33:57 Then we can pull those items if needed into our todo for the next week 18:34:50 if needed :) 18:34:51 for the blog, you can see if a comment has been approved, and assume approved comments have been looked at 18:35:18 history tells that we get way more valid bug reports than we can put into our next week todo 18:35:59 boklm:+1 18:36:22 GeKo: yeah the bug reports need to go into a backlog for inclusion in future roadmaps 18:36:29 also depending on the time estimation 18:36:44 if it's only a quick change (doubtful) maybe it can be sneaked in more easily :) 18:37:10 any other points on feedback/triage? 18:37:21 shall we move onto sync with Pili? :) I think that's an easy one 18:37:25 there is the concept of a "fast fix" that the network team has 18:37:28 which i like 18:37:32 Maybe during weekly standup, we can get summary of triage 18:37:44 which means if a fix does not take more than say 15-30min just do it 18:37:55 as the overhead to re-look at it is not worth that 18:38:04 we could think about such a thing for us as well 18:38:15 yup 18:38:18 one of the big barriers here, though is the build and test time 18:38:35 which often makes me hesitating to pick possible candidates up 18:39:52 yeah even simple fixes take a bit of build and test time :/ 18:41:57 let's park the fast-fixes for now then :) 18:42:08 regarding syncs, happy to have syncs with others if they want to also, just send me an email 18:42:35 moving on to monthly syncs with mozilla 18:43:10 antonela, pospeselr and myself are already going 18:43:25 it probably makes sense for mcs or sysrqb or both to start attending also 18:43:56 or maybe it's enough with the people that are going already? 18:44:01 * mcs is trying hard to not add too many more meetings to my schedule :) 18:44:09 mcs: that's fine, I understand :) 18:44:18 we can leave it as is for now 18:45:10 leading weekly tor browser meeting 18:45:11 I can do it, but it's a tricky time of day for me, so I would prefer if someone else could do that :) 18:45:31 as in, I'm around but with interruptions and tired as it's the end of my day :) 18:45:32 i think sysrqb is a good choice 18:45:47 * GeKo quick he is not here it seems :) 18:45:55 moving on... ;P 18:46:43 default contact with stakeholders/external partners 18:47:12 it seems sysrqb or someone else added them there also :) 18:47:15 that's a sysrqb thing i think 18:47:33 let's move on then, we're getting close to the hour 18:47:42 release schedule 18:47:51 brade mcs sysrqb 18:47:56 makes sense to me 18:48:01 +1 18:48:12 firefox security bugs contact sysrqb 18:48:19 (good thing he's not around... ;) ) 18:48:38 yeah, keep moving :) 18:48:39 hackerone... sysrqb and tjr has also volunteered 18:49:10 GeKo:what's the workload on that? 18:49:11 does it make sense to have tjr as backup? 18:49:15 yeah, I figured I have a pretty good handle on outstanding fingerprinting issues and what's going on mozilla vuln-wise if desired, I could help there. 18:49:20 tjr makes sense 18:49:33 as it is sometimes firefox bugs that get actually reported 18:49:40 cool 18:49:45 What is the frequency for new reports? 18:49:45 or bugs that should get filed at mozilla's bugzilla 18:49:48 so, back up or joint responsibility? 18:49:55 depends 18:50:10 currently h1 has a triage team doing the bulk of the work for us 18:50:15 which is good 18:50:43 so it should not be too much work looking at browser issues once they get passed onto us 18:51:19 ok, so we can give both sysrqb and tjr access anyway and see how it's working :) 18:51:22 If I can get email notifications for stuff (instead of having to login to a portal) I'm happy to be first line and can pass stuff on. I am; however, pretty reliably restricted to business working hours though. 18:51:33 yep 18:51:38 you'll get emails 18:53:11 shall we move on? :) 18:53:12 I think we can skip dev work since ideally everyone should be reviewing code and writing patches, but in future it might be good to look at areas of expertise and who are good people to review certain areas and where we have gaps 18:53:22 so if no one has any comments we can move to release work 18:53:42 who should decide who reviews what? 18:53:49 It might be good to think about how reviewers get assigned (currrently, GeKo asks soon if time critical or if no one steps forward) 18:53:56 acat: +1 :) 18:53:59 :) 18:54:43 so maybe we need to be more formal about assigning reviewers 18:54:54 maybe that is something to discusss at a Monday meeting? 18:55:10 +1 18:55:11 ok 18:55:12 happy to do that then 18:55:23 releases: who is going to take over building releases? :) 18:55:42 Is there an issue of shared machine resources? 18:55:50 or should we have more than 2 people overall? 18:55:54 * GeKo has a hard stop in 4 minutes 18:56:09 More machines to use == faster builds, overall. 18:56:09 we might need to do a part II :) 18:56:10 we tried to have more than 2 people in the past 18:56:19 let's end with discussion on releases 18:56:28 and i think it's a good idea in general 18:56:45 and continue with the other items either on Monday or another meeting after GeKo and I are back from vacations 18:56:48 could we rotate the release manager each release? 18:56:51 we have a shared build machine on tpo infra which i usually use for releases 18:57:04 antonela: you mean the builder? 18:57:24 yes, so is something that is not done by one person 18:57:47 we need two at least for each release 18:58:08 (if is very painful and draining) 18:58:17 i think starting with a second one for me 18:58:32 and then a third one as backup seems like a good way forward to me 18:58:45 ok, I think we have pospeselr as a volunteer 18:58:48 I have some hardware becoming available soon that could be used for builds. Just throwing that out there. 18:59:00 a non-shared machine is better, so that one single person does not have access to both build machines 18:59:13 and sisbell as a potential candidate? :) 18:59:14 hey Phoul ! :) 18:59:27 Sure, I can help 18:59:28 any last minute questions for GeKo on releases before he disappears? 18:59:43 thanks sisbell we can discuss the specifics further 18:59:47 and I have an extra machine at the tor office that I can use for builds 18:59:52 maybe we just need you as a backup 19:00:05 on top of my usual dev machine 19:00:06 sounds good 19:00:51 ok 19:01:12 let's leave it here for today 19:01:13 thanks everyone I think it was a really good discussion 19:01:21 indeed, thanks! 19:01:23 o/ 19:01:24 we <3 GeKo 19:01:25 #endmeeting