18:01:04 <ahf> #startmeeting tor tooling meeting 13 october 2020
18:01:04 <MeetBot> Meeting started Tue Oct 13 18:01:04 2020 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:04 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:01:13 <ahf> our pad is at https://pad.riseup.net/p/tor-tooling-meeting-pad-2020-keep
18:01:22 * anarcat waves
18:02:12 <gaba> agenda in http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-tooling-meeting-pad-2020-keep
18:02:35 <ahf> #topic branch rename and ticket https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/75
18:02:47 <anarcat> alright, maybe i can talk about this a bit
18:02:50 <ahf> ye
18:02:53 <ahf> please
18:03:00 <anarcat> this came out of https://gitlab.torproject.org/tpo/core/team/-/issues/2
18:03:20 <anarcat> which is a similar idea: rename the "master" branch to "main" in the main tpo/core.git repository
18:03:34 <anarcat> what i am proposing here is not to change the core repo or any other repo (for now)
18:03:39 <anarcat> but just change the default
18:03:47 <anarcat> so that new repositories would have "main" as the default branch
18:04:00 <gaba> +1000 to change the default
18:04:03 <anarcat> there's a setting buried somewhere in the gitlab admin, it's a simple tweak
18:04:33 <anarcat> i am not sure how we decide those things inside the "tools" meeting, in TPA normally that would be a "policy" decision, i guess
18:04:48 <anarcat> but this here thing lives in somewhat of a weird "service admin" zone that is probably outside of the scope of TPA
18:04:54 <ahf> ya
18:04:57 <ahf> let's do that
18:05:14 <gaba> i would go for us making the decision in this meeting
18:05:20 <anarcat> ok
18:05:25 <anarcat> ahf: can you clarify? do what? :)
18:05:32 <ahf> ye all teams can join this
18:05:39 <ahf> let's change the default for new projects
18:05:46 <anarcat> the setting is in https://gitlab.torproject.org/admin/application_settings/repository
18:05:48 <anarcat> okay
18:06:04 <anarcat> hiro: any objectiosn to changing the default git branch name to "main" (as opposed to the current upstream git default, "master")?
18:06:42 <hiro> uhm
18:06:48 <hiro> I get why we do it
18:07:07 <hiro> but I am not sure or git mirroring is going to work
18:07:13 <hiro> s/or/our/
18:07:14 <ahf> it is for new projects
18:07:15 <anarcat> that's a good point
18:07:16 <ahf> not for old ones
18:07:25 <anarcat> important caveat if we rename existing branches
18:07:28 <ahf> so when i go create ahfswickedcoolproject
18:07:31 <ahf> it has main as default
18:07:35 <anarcat> whoa
18:07:42 <ahf> i hope?
18:07:46 <hiro> it's fine but can we not implement this this week?
18:07:46 <anarcat> i want to see ahfswickedcoolproject!
18:07:52 <ahf> it's top secret
18:07:57 <anarcat> dang
18:08:08 <anarcat> i don't mind waiting
18:08:19 <anarcat> hiro: any reason why? or when we should do this then? :)
18:08:22 <ahf> hiro: sure, what is blocking such change this week? :o
18:08:22 <hiro> there are too many websites stuff that I need to check and I don't want to have another fire
18:08:27 <ahf> ah!
18:08:31 <ahf> sure
18:08:42 <anarcat> ah
18:08:48 <anarcat> i don't expect anything to break, tbh
18:08:53 <anarcat> but i can punt this to next week, for sure
18:08:53 <hiro> ok then go ahead
18:09:05 <anarcat> i'll take the ticket and do it next week
18:09:07 <anarcat> agreed?
18:09:10 <hiro> sounds good
18:09:13 <anarcat> cool!
18:09:56 <ahf> awesome
18:10:06 <ahf> #topic * dashboard review: make sure numbers in Next and Doing are reasonable (< 10?)  https://gitlab.torproject.org/tpo/tpa/gitlab/-/boards
18:10:13 <anarcat> alright, i guess that's me too
18:10:40 <anarcat> so for context, with my "ex-TPA-team-lead" hat (whatever is left of that), i do some triage of the tickets that come in to the TPA projects
18:10:46 <anarcat> i look at that dashboard: https://gitlab.torproject.org/groups/tpo/tpa/-/boards?scope=all&utf8=%E2%9C%93&state=opened
18:10:49 <anarcat> and try to make sense of it
18:10:57 <anarcat> my idea is that tickets should migrate from left to right in there
18:11:04 <ahf> *nods*
18:11:22 <anarcat> some tickets might "jump" a column or two, e.g. a ticket might go straight from "open" to "icebox" or "open" to "doing" (esp. if it's some trivial stuff) or next or whatever
18:11:29 <anarcat> but the idea is to keep the "open" queue basically empty
18:11:49 <anarcat> and also to keep the "backlog", "next", and "doing" queues especially small, and increasingly so
18:12:01 <anarcat> ie. "doing" should be very small, backlog can be larger, but not too big
18:12:12 <anarcat> now my problem is that the gitlab tickets also show up in there
18:12:19 <anarcat> which are, naturally, see here as well https://gitlab.torproject.org/tpo/tpa/gitlab/-/boards
18:12:39 <anarcat> things look a bit better today, but last week we had lots of tickets in the "doing" that we were not really doing
18:12:48 <anarcat> so i want to see how we work with this or not
18:12:56 <anarcat> it's especially tricky with the new outreachy stuff
18:13:05 <anarcat> i can think of a few solutions for this
18:13:17 <anarcat> but i'd like to hear folks about how we manage tickets and workflow a bit before talking any more :)
18:13:18 <anarcat> .
18:14:10 <ahf> hm
18:14:34 <ahf> i think i will follow what is the best thing for you in the tpa space here. in the tpo/core thing there are a lot more things in the air i think
18:14:39 <ahf> so ours are not that optimized there
18:15:09 <anarcat> for what it's worth, this is the label workflow i proposed back in june: https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-5-gitlab#roadmap-gitlab-boards
18:16:29 <anarcat> there the idea is that the "backlog" is what happens next month, "next" is what happens this month, and "doing" is what happens right now (e.g. today or this week)
18:16:56 <anarcat> obviously, this will vary according to the iteration period, we were working on a monthly schedule back then, but since we have those weekly meetings, maybe "tools" could have a weekly schedule as well
18:17:13 <anarcat> anyways, the idea behind this point was to make sure we cleanup this queue so it represents what we're working on
18:17:21 <ahf> it seems sensible to me. i don't know if you have other admin meetings though
18:17:36 <anarcat> we don't, right now, have other tpa meetings
18:17:41 <anarcat> but we should be resuming those, i guess
18:17:50 <anarcat> i was obviously not around to organise the october one :p
18:17:56 <ahf> hehe
18:18:54 <anarcat> am i going to fast?
18:19:30 <anarcat> too*
18:20:02 <ahf> no no. i don't have anything that opposes this, i think it's a fine way. don't know if hiro and/or gaba have something here
18:20:18 <ahf> i am generally trying to crunch through my tickets and cleaning up that after the flood of outreachy folks arrived
18:20:25 <anarcat> cool
18:20:31 <anarcat> so what's our iteration size? month? week?
18:20:47 <anarcat> either way i doubt the current dashboard is realistic, tbh
18:21:03 <ahf> i think for me it will be month with all the other things going on
18:22:12 <anarcat> we're barely churning 1-5 tickets a month right now, i doubt we'll deal with the 14 tickets in "doing" and "next" un the next two weeks :)
18:23:43 <ahf> ye lol
18:23:59 <ahf> i am gonna cleanup my assigned stuff in that pool
18:24:03 <anarcat> thanks
18:24:06 <ahf> and i think i will let new outreachy tickets enter in the icebox state
18:24:21 <ahf> ideally they get picked quickly, but they are also uknowns here
18:24:24 <ahf> unknown*
18:24:39 <anarcat> i think it would be great if outreachy stuff would go to the icebox
18:24:42 <anarcat> i think it makes sense
18:24:50 <ahf> ye, i will do that
18:24:54 <anarcat> it's a (possibly) large pool of things that might not get done ever
18:25:02 <ahf> yep
18:25:05 <anarcat> if someone picks it up and actually plans to work on it in a month or two, it can go into backlog
18:25:13 <ahf> i think we will GC on those tickets post-outreachy internship discovery phase
18:25:22 <anarcat> yeah, makes sense
18:25:27 <anarcat> thanks!
18:25:39 <ahf> cool
18:25:43 <ahf> shall we take the last topic for today?
18:26:58 <anarcat> *crickets*
18:27:16 <anarcat> I'm always puzzled by tickets like this one https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/65
18:27:34 <anarcat> it feels we're replicating the gitlab.com issue tracker sometimes, it has the potential of growing with such stale issues indefinitely
18:28:05 <ahf> https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/65
18:28:08 <ahf> err
18:28:15 * ahf looks
18:28:26 <anarcat> for the record https://gitlab.com/gitlab-org/gitlab/-/issues has 34,000 issues :p
18:28:35 * gaba is around... sorry i got a phone call
18:28:52 <ahf> anarcat: yeah, there are some of those we can simply close with "Cant fix, upstream issue"
18:28:58 <ahf> we are not going to ever start patching gitlab ourseolves
18:29:06 <ahf> that is a minefield of bad ideas that lies down that road
18:29:09 <anarcat> yeah
18:29:15 <anarcat> although in this case a workaround was proposed
18:29:21 <gaba> or we can convert them into a specific action to fix the problem they have
18:29:30 <anarcat> it's just that it's been in "next" for three weeks so it's not clear to me it will ever get done
18:29:31 <ahf> yep
18:29:37 <anarcat> i have already closed a lot of those issues
18:29:37 <gaba> in that case there is a workaround but still does not fix th eproblem
18:30:04 <anarcat> e.g. https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/79 78 77, etc
18:30:32 <anarcat> so what would make this ticket be closed? :)
18:30:53 <anarcat> i mean some tickets like this can go to the icebox if we want to actually monitor upstream activity
18:30:56 <anarcat> i did that for the wiki stuff, in https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/76
18:31:06 <anarcat> because there's actually some work being done at gitlab.com on that that is promising
18:32:59 <ahf> i think we should close things that are not solvable right now. if people wants to create repos for specific confidential issue handling in their teams they can do that?
18:33:10 <anarcat> agreed
18:33:12 <ahf> it isn't something we can solve instance wide i think?
18:33:33 <anarcat> i do not think so either
18:33:55 <gaba> yes, i agree. I have on my list of things to do to add templates to projects to have more clear issues
18:33:58 <gaba> we need to be more specific
18:34:08 <anarcat> gitlab#64 is similar
18:34:11 <ahf> ok, sounds good. let's close this one then
18:34:12 * ahf looks
18:34:22 <ahf> ah yes
18:34:29 <anarcat> i'm tempted to just shift all of the backlog to the icebox, and next to the backlog
18:34:32 <ahf> #64 can be closed too - we can't solve that issue
18:34:38 <anarcat> kind of a reset, clean slate
18:35:03 <anarcat> ahf: keep in mind that #23 was closed in the same way, yet #64 was reopened because said it 'was not enough'
18:35:10 <anarcat> s/reopened/opened/
18:36:02 <gaba> there are 2 issues. We have issues that are just problems that people are presenting without a clear solution
18:36:09 <gaba> and we have issues that propose something to implement
18:36:23 <gaba> i think most of the issues in gitlab are about problems people are having
18:36:32 <gaba> and we need to figure out a work around or a way to resolve it
18:36:51 <anarcat> can we at least move those tickets to the icebox while we think?
18:37:01 <gaba> yes, let's move to the icebox, not close
18:37:02 <ahf> right, i agree with that. i think though that the feature here isn't something we can morph into something that removes the issue here without modifying gitlab code
18:37:06 <ahf> wfm
18:37:17 <anarcat> done for 64
18:37:44 <anarcat> and 65
18:39:15 <ahf> ok
18:39:19 <ahf> what else do we have for today?
18:39:29 <ahf> i'm 2h40min into meetings and my brain is running at 4hz
18:39:48 <gaba> me too...
18:39:54 <gaba> im done
18:40:44 <anarcat> i guess i'll bring this up again next week, when you folks are all fresh :)
18:41:30 <anarcat> thanks for moving the meeting
18:42:04 <ahf> oki, cool, yes, next tuesday wont be as bombed as today is monday and tuesday meeting each other
18:42:05 <ahf> lol
18:42:11 <ahf> two compressed days compressed further
18:42:16 * ahf tells the bot to stop logging
18:42:18 <ahf> #endmeeting