GitLab Team Retrospectives, 6 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 13.4 Team Retrospective Summary

Description

Please join us for the Retrospective Discussion on Thursday October 8th, 2020 at 4PM UTC (9AM PT)

A

Hi everyone and welcome to the gitlab 13 4 team. Retrospective summary, my name is john and I'll. Be your host for this summary call, and also for the discussion call later in the week um as ever, we'll be aiming to answer three questions. What went well, what went wrong and what can we improve and there was a ton of really good feedback in the retrospective this month.

A

um I've picked some items to highlight, but I encourage you to read the whole document so, starting with what went well under collaboration thomas from secure, we executed a complicated project requiring a lot of collaboration between back end and front end teams, which was enabled in part by utilizing a weekly stand-up to facilitate deeper technical conversations and a shared understanding of the business objectives.

A

We appreciate this approach can be easily abused and we don't want to rely upon it, but to find a way, this type of approach could work in limited circumstances. Was a nice surprise in results, changjung from global search search result, page performance improvements have been successful, it's no longer a top priority.

A

One other highlight is that each release we're also improving the quality of the code base that makes working on the code more enjoyable and more efficient too also, we've enabled search hyperlog log usage, ping metrics in thirteen four we'll start receiving metrics from self-managed customers soon, john from package, we're noticing an increased amount of questions, feature requests and bugs which can be overwhelming at times, but it means that folks are using the project the product and pushing its limits.

A

Everyone in the team is doing a great job of triaging questions in slack and in issues, and this is echoed in clement's comment number two here in the slide as well under efficiency, craig from the database team. We have new migration helpers that allow us to safely finalize partitioning migrations and could also be the basis to add new migration helpers and follow the same process in future for all long long running background migrations under diversity, inclusion and belonging craig. On behalf of the memory team.

A

This time it was mentioned in a couple of comments that it was great to be able to explore new languages in this case golang and work with teams across the organization in pursuit of the image scaling. Epic.

A

And in transparency, cheryl from verify, ci feature flag, roll light issues have steadily increased on ci, which means increased visibility and communication for all our teams, our group's team members. So what went wrong in collaboration thomas from secure? We have one front-end team which works against four back-end teams. Each team works in ways which are unique enough to make it really hard for team members who have assignments spanning multiple teams in one iteration.

A

Labels involved issue sizes time available for planning breakdown and how issues are linked together can all differ in results. Clement from monitor, we had a bug that was impacting a feature in foss, because we did not verify a feature in fast mode. We've sent a reminder to everyone on the team and shared it in the wider slack channels, so that reviewers and maintainers can also help.

A

Keep this in mind when reviewing emerging code inefficiency, james from fulfillment setting up the subscriptions app is still difficult for non-backend engineers. Creating a development kit or a basic development kit will help a lot with this and inefficiency ricky from verify testing for the second milestone in a row, we've added uh 10 or more issues into the milestone after planning, we will start using labels to track where these midi iteration issues are coming from, based on manual analysis.

A

It looks like a combination between follow-up issues from mrs and issues that had unknown unknowns, leading to issues requiring splitting mid-milestone and nicole from release management. The security backboard process was identified as a burdensome task for our team in 13 4.. The code change was very simple, but the back ports took a lot of effort. We're looking forward to seeing if the new updates to the security mr process will help moving forward.

A

So how can we improve, in collaboration lindsay from threat management? Noted participation in our team retrospectives have declined over recent milestones. This includes comments in the issue and participation in the synchronous discussion items we chose to focus. Improvements on include we're spending a lot of time reading everyone's feedback during our synchronous discussion. Instead of discussing as a group, we plan to vote on items to discuss using the microphone, emoji and focus on these topics during our synchronous discussion.

A

Getting more team input about what to share in the larger company-wide retro will hopefully drive more participation too. Our plan is to vote on items to bubble up using the up emoji inefficiency, jean from static site editor. There are areas of our code base where there's no clear group responsible for it and it's difficult to find out who might be a domain expert in that area.

A

For example, the internal config file api is complex and, as far as can be determined completely undocumented, some of it can be figured out by looking at the code, but in many cases it would be very useful to ask someone with experience and knowledge about its use uh so that about wraps up the summary I'd invite you to participate in the discussion, which is this friday october, the 8th at 4 pm, utc or 9 a.m.

A

Pacific, if you're an internal gitlab team member, you can use the internal zoom link to partake um if you're, not you can follow along on our youtube channel as it'll be live. Streamed. I've selected two topics for discussion, both of which come from items in the retrospective document. uh The first relates to lindsay's comments. uh How does your group encourage participation in retrospectives?

A

um How do you ensure that retrospectives are an inclusive place? That team members feel heard that the quality and quantity of information is maintained over time and the second discussion topic is related to jean's comments?

A

How do we make it easier to work on areas of code which are not the responsibility of a specific group and he's given the example of the internal config file api, I would add the example of graphql which in fact nominally nominally does have ownership by a group, but changes to graphql code usually involve domain experts from multiple groups, multiple stages and across multiple disciplines.

A

So those are our two topics. We also have other topics in the retrospective document, which I would encourage you to check out and if you'd like, to contribute to the discussion. Please add items for each of these topics in the document and you can verbalize them in the call.

A

So thanks very much and I look forward to seeing you on thursday.