GitLab Digital Experience, 16 Dec 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Digital Experience Iteration Retrospective 2021-12-16

Description

The digital experience team's retrospective for the iteration ending 2021-12-16.

Agenda: https://docs.google.com/document/d/1kMNiUF2UDuSrMDuzLyRi8OEhVxry_MJoYi38RmmWafY/edit?usp=sharing

A

Hello, welcome to the digital experience uh retrospective on the last iteration, it's thursday december 16th of 2021, and um I think we can hop right into it with things that went well, uh so miguel do you want to start.

B

Yeah sure uh I just wanted to verbalize uh the fluid conversation that I had on the on my merch request.

B

It was great to have lots of help and everybody jumped on to um do some recommendations and stuff, and I think it contributed a lot on the on the good result in that component and yeah. Thank you, everybody that helped me help help me, and next is just.

C

Thanks um so I just started: taking this design system, slash figma class from a company called memorizedly um started last week, and it's like a once a week for five weeks boot.

C

Camp kind of um I already feel like I've learned a ton and I like kind of knew things peripherally, but just like deep diving into things like one thing at a time each week and it's been amazing, um I uh had a chance to audit the slippers colors this week and just found some errors and some places where we could update to make them better and you know doing type next week and all this stuff- and it's just been great- that's a great way to kind of audit our system while taking classes so super stoked about it.

D

Yeah, the buyer experience migration's been cooking, slinging pages left right, really exciting great job.

A

Awesome plus one and anyone else on things that went well, so we can move on to things to improve on uh miguel. You've got the first one as well go ahead.

B

uh Yeah well, this iteration. I had a bit of uh over uh underestimation of the work that I needed to do uh so as a lesson learned, uh I will on the promise and I will deliver and yeah that's it.

E

I added a point there. I I underestimate um by 30 or 45.

D

At least because always stuff always comes in under promise over deliver.

B

D

um Right, I have the uh the second point here um and after working with the product, it's it's really highlighted how much more work we have to do in documenting and evolving our engineering processes, and I actually want to share my screen and highlight something um in particular.

D

Let's do this all right. Here's, our team, dang, that's a huge engineering team. I mean come on and if you look over at the product, their engineering teams are like that big, so yeah we gotta really evolve our processes and like get in line, we need to start acting like an engine. We are an engineer and we are acting like it but like we need to, like I don't know of all um so some good documentation.

D

I found there that I think we should all read before the the year is over about commit message, guidelines, code, review, testing um and coming back in the new year and starting to to build that for our team, like that's, the product is probably like way overboard for us, but get some background information to start.

D

um That's all I got there.

B

Yeah, I I think uh I have uh two suggestions. I I guess um I know that, uh for the documentation, we're going to uh be a build, the storybook inside of the bioexperience repo, uh but in the meantime maybe will be help helpful uh to do some kind of documentation of the components- and uh you know comment a bit.

B

How is it is it used and everything, because I I I guess that it will be very helpful to have those things when building these storybook components and also I wanted to ask if it makes sense to define like a testing strategy with uh you know. We have different goals uh than the product team, for example.

B

So maybe we can combine some light, testing and stuff that, uh for example, the visual regressions and maybe unit tests on some specific components uh it will. It will help a lot in the future. I think I think.

B

Especially doing the migration stuff, uh because we are not in the final stage of our components and they will be evolving, so I don't know why you why you think about it.

A

um We should do all these things, uh we need, it needs to be a priority and it needs to be a priority at all levels. uh I don't know if it is, I don't know if it ever will be. We've talked about this a bunch in the past and so like.

A

I think that the thing to do is to like build a business case for this.

A

We took like michael brought us up at the beginning of the quarter like being really like um analytical about all of our decisions, and I think that before we like all of these things are really aspirational and then they get hard when things get hard and the only way that people like ourselves included, like every single person, has to keep doing it all the time and it needs to be rock solid and the only reason that people do stuff is when it like solves problems for them and makes sense to you so like we need to, like, I think, before our like, before we set a testing strategy before we set our processes, we should think about measuring what's wrong and we should solve problems with it.

A

So, like barker, you brought up how big the team is. It's huge, so much complexity, so many things moving around stuff breaks. All the time like and like I see like just seeing just like looking at slack like how many 404s have we had because, like something went wrong with migration. This is not like a comment on because, like someone made a mistake, it is because the process didn't catch something happening and so before we before we propose. How do we fix this process? We should measure how bad is it really?

A

Because if you have like five 404s in two months- and it takes a total of like 45 minutes to fix, do you really need a process to solve that right? Do we need to spend and even like, if we spend even an hour making a process to solve it, then we've wasted 15 minutes because we could have just kept fixing. I mean like. I would bet that process wins out in the long run, but we need to know it for sure, which means we need to know what the problems are.

A

So, like I love testing and we should do it, but I don't think we should develop a strategy until we know what we're solving for, and we won't know what we're solving for until we can define it so like. I think the first thing to do is like get better at understanding like the root cause of when things go wrong and then right, like writing it down in the handbook and saying like how many 404 incidents have we had? How many times have we knocked out the pipeline?

A

How many times have we knocked out the website? How many hours did it take to resolve all these things, put it in one place, and then we can identify like what's actually costing the company money and like, what's maybe just annoying to us right because, like I don't love fixing it 404. But if it takes me five minutes to do like, I can't justify spending time building a better process because, like it just doesn't make sense.

B

Yeah sure I I also wanted to guide it also about the goals that the company has and we, as a team have so maybe the the visual regressions are a good idea, because something can go wrong, so we can still do it manually and yeah. I agree completely.

A

You should record how much time it takes to do the manual stuff right and then you can like report out and say, like I took five hours manually, checking for visual regressions right and then after a couple of iterations you'll, be at 20 hours of that, and if we have two or three people with that. Like all of a sudden, we start to have a really compelling case for what. If we spent like five hours automating, it.

B

D

Great great discussion there um move on to the next one, all right, let's define or start thinking about process for asset management, um something that's really gotten annoyed me since I've been here is like how large our image library is and which is why our pipeline takes so long and we're starting with a nice clean slate over in the buyer, experience repo, and should we just start dropping all our images in there?

D

Maybe not I don't know john. I see you got got a good point. There.

F

Yes, so um initially we have been taking the urls from the that that repo, but I don't know if that repo will be forever and those links will be active forever. So we started to to take those images to the buyers experience, but it's a good point that it will increase a lot.

B

F

We will have like a big pipeline, so if it's possible to have a bucket or something to store, these images will be like a a good good thing for us for the future right now, it's not slow, but with all the images that are going in in the future, I think it will be slow in the future. So uh right now, uh I think a bucket or something to store. The images would be like uh a.

B

D

Miguel, what are your, what are your thoughts there.

B

Oh yeah, no, basically that yeah the bracket idea is a great idea and uh linking back to the dot dot. Repo might not be a good idea, because there are some images that need so much adjust adjustment so yeah. I think the idea of the bucket it's a great idea.

A

I want to make an action item here. um I think we should um uh someone. I don't know who I guess I'll just do it. uh uh We use google cloud, so we won't, uh it doesn't make sense to do s3, um but we should uh get um infrastructure to provision us um like uh a bucket, but then we should probably just like slap it behind fastly for a cdn on some of the stuff um so we'll need to like.

A

I think the real solution here is the digital asset management platform, but that's going to take like a year if ever to get, but we can do something a little simpler with like putting stuff into a bucket instead of into the git repository.

A

So I will take an action item to see if I can provision some infrastructure there and then we're gonna have a problem where and it's fine, it's not a huge problem, but will um a pain point we'll run into is that the google cloud bucket will be like will never be in sync with well or like? There won't be a deterministic way to like sync up your changes with how the state of that changes right so like we'll.

A

Just have to we'll probably have to come up with a process to make sure that we don't like move images, rename them, etc, right and like and like overwrite people's work, because we can't manage it through like get strategies there. So, um but I don't know what that problem is yet, so I'm not gonna try too hard to solve it until we know that that's actually an issue. So I'm just gonna add an action item for me to see. If I can provision us a bucket.

D

All right, I think, we're gonna skip over the next item: hop yeah, yeah, no yeah, okay, we're gonna hop down to.

D

My item yeah um about uh things we could work on, is re-boarding to communication at gitlab. They have a great handbook, page lots of awesome information on how to use our tools for communicating like git lab slack. Google work happens in gitlab, not slack. We use our issues and our mrs for organizing work, because that is the inclusive way, so everyone can work asynchronously and to avoid direct messages in slack and for transparency to have our conversations in public channels.

D

I love our water cooler channel, but if it's a conversation about work, it should go in the public channel um more of an fyi unless anyone.

E

D

Anything else to add there not we'll pass it over to mateo.

G

Okay, so I felt this print. We were flooding lauren with all the review requests for the migration pages, and I know she has been pretty busy lately. So maybe we should split these review requests across the team if anyone is available. Take those.

A

Yeah, I think um and berger correct me if I'm wrong, but I think, like you and I operate in basically like a similar role, and we do the thing that, like um they have in the engineering handbook, I always forget the title for it, but like uh two people who can activate the same role so that there's a good amount of redundancy um so like if you're looking for, if you've got an mr, that you're, like oh, I think like barker, would be the best person to review like admits that lists you sort of like interchangeably, so that we can like, at the very least like split that load in half um and I'm sure, like nate, also can like take on a bunch of that too.

A

So maybe in thirds- and you know um kind of like down down the the latter- a seniority there right so, like I say just do it like here's. The other thing too, like ask for a review and like reviewers should, like feel free to like say no and be like. I can't get to this find someone else right like that. I think that's, that's an appropriate! It's in the handbook, like that's an appropriate response to say, like I basically like your. If you can do a review within two days, you should do it.

A

If you can't do it within two days. You should let people know immediately and acknowledge it. They can find someone else um so one just like yeah, spread it out and toss it around to other folks, especially people who've, been here longer and are just like. You know, probably gonna be a little faster to review, stuff, anyways and then two for people who get tagged for reviews just like. If you can't do it like, let let the person requesting no and then just be like go, find someone else and then go. Do it.

E

G

F

Yes, maybe we can uh do some like a strategy next spring like uh tag into reviewers, and one of those can say yes and the other no, and we remove the one of those two reviewers from the mars, because in this spring we send a lot of hammers to to lauren. So she's she's blood with the mars.

D

I, like I like looking at them, they've all been great.

H

I think there's also like domain specific expertise that people have so it's like certain people, just like you know, know about certain things more, so it's like you can also think about it. That way, it's like oh, like who has specific expertise.

A

I think our team will get better and stronger if you do the opposite of that and if you send it to someone who's, not a domain expert like if you need a domain expert, because something is like really challenging and you're like I'm stuck. Then of course go to the domain expert for help.

A

But if, like someone's a domain expert on it, I think we should find someone else so that they can begin to build up the muscles to be just so that we're not what we don't want to do is be in a position where, like only one person, knows everything about like this one aspect of things and then, if they're out, we like lose a ton of cadence on that. So like like. I like. I totally hear you like.

A

It makes sense, especially for the for the tricky stuff, but like even with the tricky stuff, though I think like spreading out the opportunity for other people to become domain experts, because, like you mentioned somewhere in a thing that, like you've, suddenly become demanding for it on docs and like just because like when I like, because I think I'm like oh javi's, working on docs like I'll, go to I'll go to him on this, but like only because you keep on getting asked for it.

A

So, like the first couple times you get asked on it, you might not feel like an expert, but by like the fifth time you will so like just start asking other people.

A

Cool anything else, I've got an action item. I will do this uh sometime shortly. I have no idea what that process looks like and so like. I think for now, like I don't think it's too risky to keep putting stuff in the repository, because it's still early yet and when we do get the bucket, it will be like the reason to like fix.

A

Our images in like one place is like we will keep on outgrowing it like right now we're about to outgrow managing it in git, but at least, if we get it all in git, migrating from git to a bucket will make sense. Eventually we will probably out grow using the bucket, but if everything's in the same place, then migrating to the next solution will be much easier uh rather than like spreading it out. So like keep doing what you're doing put stuff in the buyer.

A

Experience repository because, like I'll, probably just literally copy static into whatever we end up with- and I don't know what the timeline on that is, but like stay the course and then we'll fix it and we'll like broadcast that when it's fixed.

B

Maybe a good practice we can do in the meantime is to compress the images and also make them shorter.

A

uh Nothing else um good talk, I'll post these I gotta run for a little bit but I'll post. These meetings up uh later this afternoon, so yeah.

G

Thank you. Thank you. Everyone.