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