18:34:21 <sysrqb> #startmeeting Tor Browser Team 12 November 2019
18:34:21 <MeetBot> Meeting started Tue Nov 12 18:34:21 2019 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:34:21 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:34:29 <pili> o/
18:34:31 <boklm> hi
18:34:36 <mcs> hi
18:34:39 <sysrqb> (sorry, had a slow internet connection, had to reconnect)
18:34:40 <sysrqb> hello everyon!
18:34:47 <sysrqb> +e
18:34:52 <Jeremy_Rand_Talos> hello!
18:35:18 <sysrqb> let's see where we are
18:35:24 <brade> hi
18:35:41 <sisbell> hi
18:35:46 <pospeselr> hellooo
18:35:51 * Jeremy_Rand_Talos confesses that he didn't actually know yesterday was a holiday (despite living in the U.S.) until seeing it on #tor-dev IRC yesterday.
18:35:58 <acat> hi!
18:37:18 <sysrqb> *waits for storm to reload*
18:38:04 * mcs added a discussion item about migrating away from Storm
18:39:32 <sysrqb> okay.
18:39:56 <sysrqb> GeKo: how do you usually update the design doc?
18:40:25 <sysrqb> do you just start form the top and update anything that is now not correct (plus add new items)?
18:41:18 <sysrqb> or do you do one pass over the entire doc and make notes of what needs updating? and then go back and update them?
18:42:04 <sysrqb> we can talk about this after the meeting, but i'm curious what process you used wiht previous updates
18:42:24 <sysrqb> (and this seems helpful for everyone on the team)
18:45:56 <sysrqb> we can also come back to this
18:46:10 <sysrqb> okay, discussion points
18:46:15 <sysrqb> 1) triaging
18:46:40 <sysrqb> recently pili, boklm, and i took  over triaging
18:47:07 <sysrqb> this includes tickets - newly filed tickets and updated tickets
18:47:10 <sysrqb> and blog posts
18:47:24 <sysrqb> plus irc channels, like #tor (in theory)
18:48:06 <sysrqb> but this is a new area for us, and the team is maturing
18:48:24 <sysrqb> so we think the way we operate and triage should change, as well
18:48:55 <sysrqb> and we should document how we triage so we can easily swap roles in the future
18:49:15 <sysrqb> or new people can step in while another is on holiday
18:49:19 <sysrqb> (as an example)
18:49:24 <mcs> +1 for documenting your procedures, at least briefly
18:49:41 <sysrqb> this question has multiple pieces
18:49:56 <sysrqb> 1) what does "triaging" include
18:50:19 <sysrqb> i mentioned new/updated tickets, blog comments, and irc channels
18:50:56 <sysrqb> for the tickets, what should be the expectations of triaging "updated" tickets
18:51:38 <sysrqb> pili mentioned (privately) looking over tickets that received an update from a non-team member
18:52:11 <sysrqb> so that we know when we receive new information from users and can continue engaging with them
18:52:19 <pili> +1
18:53:18 <sysrqb> i like this idea, and it is important, but i feel looking at every ticket updated within the last 24 hours
18:53:28 <sysrqb> is a lot of work
18:53:45 <sysrqb> is there a process  or keyword we can use that will make this easier?
18:54:11 <sysrqb> more-information is helpful, but some users don't change the status or can't change the status
18:54:26 <GeKo> ugh
18:54:29 <GeKo> i am here now
18:54:33 <pili> I personally subscribe to tor-bugs and check those emails first thing in the morning
18:54:35 <sysrqb> o/
18:54:58 <pili> it does take me between 1 and 2hrs every morning to go through those and deal with my email backlog though
18:55:07 * boklm reads the tbb-bugs list (the same as tor-bugs, but only for bugs in the Tor Browser component)
18:55:11 <pili> I find it's worth it for me to get an idea of what's going on
18:55:19 <sysrqb> yeah, i don't want to add more burden onto this process
18:55:22 <pili> might not be as useful for everyone though
18:55:49 <sysrqb> it seems like streamlining this so we know exactly which tickets we should look at will help
18:56:05 <pili> yup, the thing is sometimes people don't add the Browser component
18:56:07 <sysrqb> but maybe this isn't something we should try optimizing yet
18:56:14 <pili> so looking at tbb-bugs alone will not always help
18:56:23 <GeKo> we need to have a process for following up on tickets, too
18:56:24 <sysrqb> yeah.
18:56:33 <GeKo> like we ask users for new information
18:56:40 <GeKo> and then they provide it
18:56:52 <GeKo> and we need to make sure that we take it from there
18:56:59 <pili> anyway, I'm happy to be one of the few looking into tor-bugs though because it is very time consuming
18:57:04 <pili> GeKo: yup
18:57:16 <GeKo> and be it just setting the state to "new" again
18:57:33 <GeKo> which is essentially ack'ing that information
18:57:50 <sysrqb> those are the two cases i'm trying to solve here
18:57:51 <boklm> pili: yes, tbb-bugs is only for seeing updates to tickets already triaged previously
18:58:06 <GeKo> how are we doing with the blog?
18:58:10 <sysrqb> 1) first ack and asking for more info, 2) second ack and follow up
18:58:22 <GeKo> i saw we have dozens of unhandled comments this morning?
18:58:47 <sysrqb> i'm looking at some of them today
18:58:50 <boklm> I handled comments today
18:59:38 <GeKo> okay, good
18:59:58 <GeKo> we should make sure the important ones get tickets
19:00:25 <GeKo> i saw boklm started with it
19:00:54 <GeKo> but there was e.g. a comment about mozilla's bug 1571003 which we might want to backport
19:01:10 <GeKo> we should make sure those things do not fall through the cracks
19:01:59 <sysrqb> i'm going to review the current comments today and create follow up tickets as they are needed
19:02:11 <sysrqb> i haven't been good about traiging blog comments yet
19:02:35 <boklm> ah, I didn't see 1571003 now has a patch
19:02:56 <GeKo> sysrqb: no worries, it's a process
19:03:22 <sysrqb> yeah
19:03:26 <GeKo> boklm: what about the dozens of comments still unapproved/deleted?
19:03:51 <GeKo> i think we should not either deleted them or approve them
19:04:11 <GeKo> ugh
19:04:17 <GeKo> *should either delete
19:04:25 <sysrqb> that makes more sense :)
19:04:26 <GeKo> anyway, i am shutting up now :)
19:05:20 <sysrqb> for tickets, i like the idea of all triaged tickets having a TorBrowserTeam keyword, so we know someone looked at it and it should fit onto our roadmap at some point
19:05:40 <sysrqb> but some tickets don't fit onto our current roadmap or we will not get to it in the foreseeable future
19:05:57 <sysrqb> i see three situations, 1) it is something we should work on within the next few months
19:06:27 <sysrqb> i propose, during triaging, we assign the ticket a YYYMM keyword, depending on how iimportant it is
19:06:59 <sysrqb> vey high/high prioirty should be "this month", medium prioity should be "next month"
19:07:33 <sysrqb> tickets we should work on "soon" can have a YYYYMM three or four months in the future
19:07:57 <sysrqb> 2) tickets that are nice-to-have features
19:08:32 <sysrqb> we won't get to them anytime soon, we can use TorBrowserTeamUndefined or TorBrowserTeamYYYYMM
19:08:49 <sysrqb> showing we don't have it on our roadmap but someon looked at it
19:09:13 <sysrqb> and 3) tickets we won't get to unless we specifically receive funding for it
19:09:31 <sysrqb> basically, tor's "pony" category
19:09:47 <sysrqb> like, "i'd like a pony for my birthday" type of ticket
19:10:04 <brade> I suggest TorBrowserTriaged for ones we aren’t setting a timeframe for
19:10:26 <sysrqb> this is similar to (2), but less realistic
19:10:31 <sysrqb> while being not unreasonable
19:10:41 <sysrqb> TorBrowserTriaged is a good suggestion
19:10:47 <sysrqb> thanks brade
19:11:04 <sysrqb> pili: boklm: sounds good?
19:11:18 <mcs> does anyone know if this kind of keyword use will transition well to gitlab? (I assume it will)
19:11:37 <pili> mcs: yup it will
19:11:39 <GeKo> i heard it does
19:11:46 <pili> and there may also be better ways to do it there
19:11:57 <sysrqb> i hope there will be :)
19:12:01 <mcs> OK. I will learn more, eventually :)
19:12:12 <sysrqb> i look forward to that future
19:13:14 <pili> anyway, I'm good with the labelling process
19:13:15 <sysrqb> is it worth differentiaing between (2) and (3), where (3) include tickets that we have no intention of implementing anytime soon?
19:13:36 <brade> I’d say “no”
19:13:41 <sysrqb> maybe just tagging them as triaged is enough for now
19:13:48 <sysrqb> okay
19:13:58 <sysrqb> good
19:14:04 <boklm> yes, sounds good
19:14:09 <pili> I prefer TorBrowserTeamYYYYMM personally :)
19:14:14 <pili> but not particularly strongly
19:14:44 <sysrqb> this is likely only for a few months until we move onto gitlab anyway
19:15:07 <sysrqb> so we'll probably create a new process for that
19:15:22 <boklm> should we write this process somewhere?
19:15:27 <sysrqb> okay, i think this is good for now
19:16:08 <sysrqb> yes, i want to document it on https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Triaging
19:16:29 <sysrqb> but that's as far as i got
19:16:32 <boklm> ok
19:16:53 <sysrqb> (we can use a differnet page name, too - i don't really care)
19:17:04 <sysrqb> but i think what we discussed here is a good start
19:17:15 <sysrqb> and we can iterate on it
19:17:39 <sysrqb> the second discussion point is about mailing list management
19:18:06 <sysrqb> it seems like most of us ignore threads on tor-talk/tor-dev
19:18:17 <sysrqb> i don't know how many of us are subscribed to these lists
19:18:21 <sysrqb> which may be a factor, as well
19:18:40 <sysrqb> but we should be better about monitoring these lists for tor browser-related threads
19:19:00 <sysrqb> and responding/following up on them when there are question or concerns mentoined
19:19:41 <sysrqb> i'll start including this in my morning triaging
19:20:20 <sysrqb> and when sometihng is mentioned in a thread, i'll ping tbb-team in #tor-dev and ask someone to respond (or at least read it and decide if it needs a response)
19:20:33 <sysrqb> pili:  did you say you can do this, too?
19:20:43 <GeKo> sysrqb: sounds good fwiw
19:21:04 <sysrqb> in the future, this can be someone elses responsibility, separate from the ticket/blog/irc triaging process
19:21:15 <pili> sysrqb: I can try :)
19:21:21 <sysrqb> but we can get this going now using what we have
19:21:34 <sysrqb> if anyone else want to help with and pili with this, we'd love the help :)
19:21:38 <pili> as in I can definitely ping people and I can try to respond myself if I feel able :)
19:21:39 <sysrqb> pili: thanks :)
19:21:48 <sysrqb> yeah! that's all
19:22:34 <sysrqb> boklm: you can help if you want, or spend your time of other important things if you'renot interested in this one
19:23:01 <boklm> I can try to help on this
19:23:03 <sysrqb> i don't want to make this the same process other triaging
19:23:10 <sysrqb> thanks
19:23:33 <sysrqb> this is imply the fastest way we can start making progress on it
19:23:36 <sysrqb> *simply
19:24:07 <sysrqb> i also encourage everyone to subscribe to the different mailing lists, if you're not
19:24:17 <sysrqb> but it's not a requirement
19:24:59 <sysrqb> tor-talk, tor-dev, tbb-dev, are the more important ones, i think
19:25:01 <pili> +1 to subscribing to lists :)
19:25:25 <sysrqb> okay, and the last item
19:25:43 <sysrqb> shoudl we move onto nc for the meeting pad?
19:25:48 <mcs> the traffic volume for those lists is not too high, at least currently.  Archives available here: https://lists.torproject.org/cgi-bin/mailman/listinfo
19:26:03 <sysrqb> i'm a bad employee and i haven't set mine up yet
19:26:23 <sysrqb> but we need to move "soon", and next meeting is as good a day as any, i think
19:26:32 <mcs> I am not sure how to set up nc access, which is one of the reasons I asked the question.
19:26:58 <pili> so, I'm not sure there's a pad application yet on nc
19:26:59 <sysrqb> considering i've never used it, does anyone know of a reason we shouldn't jump straight into it?
19:27:05 <pili> so I've been migrating pads to pad.riseup.net for now
19:27:07 <sysrqb> ah!
19:27:12 <sysrqb> well, that would be a good reason
19:27:25 <pili> I think there is something available in some future nc version
19:27:27 <sysrqb> okay, should we just use riseup?
19:27:40 <pili> and it may be possible to install it in the version we currently have
19:27:54 <pili> but that's currently in discussion with the team managing nc
19:28:01 <pili> from what I understand and remember of the conversation
19:28:04 * Jeremy_Rand_Talos is apparently not in the loop regarding the migration to nc... anything in particular I need to do in order to still be able to add stuff to the pads?
19:28:15 <sysrqb> no, you should be fine Jeremy_Rand_Talos
19:28:21 <Jeremy_Rand_Talos> ok
19:28:34 <mcs> maybe someone can add a pointer to pad.riseup.net to the storm document
19:28:38 <sysrqb> pili: okay, should i just make a riseup pad and send it out?
19:28:53 <mcs> (because I will probably forget and look there)
19:28:57 <sysrqb> mcs: good idea
19:28:58 <brade> +1
19:28:59 <pili> yup, I would say so
19:29:00 <pili> until we have something in nc that can do it for us
19:29:16 <pili> related to this point, I forgot that I was supposed to remind everyone to migrate their content on storm to next cloud
19:29:23 <pili> or risk losing it in future :)
19:29:24 <sysrqb> okay, i'll send out and eamil and update the storm pad with a link
19:29:46 <sysrqb> heh. good thing to announce
19:30:02 <pili> (I have a post-it in front of me to remind me :D)
19:30:19 <sysrqb> okay, i think we covered all of the discussion topics
19:30:24 <GeKo> and a post-it for looking at the post-it? ;)
19:30:37 <sysrqb> anyting else we should talk about in our -1 minute?
19:31:16 <sysrqb> alright
19:31:19 <sysrqb> thanks everyone!
19:31:26 <sysrqb> #endmeeting