GitLab Digital Experience, 10 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Digital Experience Retro Video - Feb 10, 2022

Description

Digital Experience Handbook Page: https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/

A

Hi, everyone welcome to digital experience, teams retro uh from january 31st to february 10th uh we're going to go over what went well and what we can improve on and just to start out. um It was our first iteration using boards and tracking kind of our issues through these boards, and I just want to start off a conversation of. I guess what went well and what didn't go well with the boards themselves.

A

um Is there anything we want to change? Do we like the labeling? Do you want to add more columns, remove more columns to try and make it more efficient and easier for us going forward.

A

If not, we can always add them under the the two subcategories and we can just go in order. So maybe that's a better way.

A

uh Okay, so yeah add anything about the uh the boards and I'll just go ahead and say what went well um so the first one is actually on me and I just want to say I did enjoy using the boards. I thought it went really well. I like that we're using gitlab the product itself in our day to day. uh That's all. I really wanted to say jess. I don't know if you want to vocalize that, but.

B

Yeah, I feel like we can all agree. The one thing that was like a little messy was, we didn't know who was going next, so I just threw a website in here. Random.Org list you throw in you know everybody's name and it'll randomize the list, and we can just do that each time. So it's not the same person going first, every time or last, every time.

C

um I was just gonna say I think it's great one, fewer google doc to juggle um obviously we're working out of one right now on this agenda, but google docs are good for agendas right and like less good for work management. So um I liked that there was one fewer link link to track with everything. um I still you know.

C

I don't know with anything you like you forget to to move the thing move the label like go dude, so you know it's one other thing to do outside of like doing the work which can be frustrating when you're like in a rush but um but yeah. I I think this was. I think this is the right direction um and I honestly don't have any pain points around more or l or fewer labels, um but I would be amenable to like one or two more of a label or column, but probably not more.

D

C

E

Maybe I'll able to indicate when the issue is being reviewed.

E

Yeah I'm curious if that would be a column or a label. I'm.

A

Not not sure yeah, like you said, I want to pollute it, but it also would be really nice looking at a board to see like. Maybe when we do, the definition definition of done. Maybe review is part of that um or no no, it's not okay. Definitely not lauren's. Giving me a chance.

F

Because it could get reviewed and tossed back like ten yeah.

A

F

A

We can make some magic formula, I don't know it just feels weird when you're looking at a board and everything's in doing because that could be like I just started it or that could be it's in review.

A

I don't know we can we can figure out a solution to that.

A

I think tina give the next one.

G

um Yeah, this is in regards to a slack thread from I don't know last week or something like that, where designers were wondering what to do with issues. If, when a design is done, do we create new issues for engineering or not? There was like a 26 response, slack starting. I believe that we ended on new issue, one issue for engineering when issue for design. um I did do that for one of my issues for this iteration and it seems to look better on our boards.

G

I just think that we should maybe state that this is what we're going to try for next iteration explicitly and just wanted to see if that's going. Okay, for for you folks.

G

I guess we can move on to things to improve on lauren.

F

Yeah mine, mine piggy, backs off of that. um If you want your work to show and it won't, you want us to get counted in our metrics, make sure there's a freaking issue for it, I'm a little salty about that. But that's just the way. We're gonna do it and that's great so.

C

Yeah, I think this feels onerous sometimes, um but I think that the value is like the metrics we get out of it, um but I still feel I still feel like we sh. I don't know I'm worried about the mat. I'm worried about the metrics when the um when the processes are not consistent, like how you know how many issues you.

C

How many issues we create is something that feels like it varies widely by person and so, like percentages of issues open seems like we have a high degree of variance- and I agree with michael that it'll normalize over time and that's what like not to say that we should like we shouldn't use it. Just that, like we should use those metrics to try and get us all to corral around like up like a standard like we should try and get like. We should try and reduce the variance over time.

C

I'm just like I'm worried about whether or not we will, um but uh we will try- and I think you know if we open up an issue for every like discrete piece of work, we're doing uh that'll, probably help or get closer.

A

Yeah, I just want to add on to that, because I had two. I think you ran this a bunch in the last iteration I had two issues or mrs, that were literally one line changes and the biggest pain point I had was the issue template. I'm gonna be honest. I didn't fill it out like I.

H

Just remove it.

A

Yeah, it's a joke because I can see it for for larger issues or maybe even epics, but things that we're just doing a little change like I don't need to put a dri. I don't need to put you know, there's no design needed or anything else.

A

Yeah. That's just my opinion. I just put a description like changed or fixed typo. I don't know.

C

Look at the um the one in the gitlab product code base, it's like they have one, but it's like it's. I think it's actually way shorter and like a lot of stuff, you can like delete really easily. um I think just I think, streamline it. I I think that, like, if there's a bunch of stuff to do like one of the, I think we've used, I think we have in the past, used these templates as like safeguards that a human reviewer should be the safeguard for so like there's templates, where it's like.

C

If I changed like ux did I like show a designer or whatever and like a human, should look at this and be like hey, so you wrote 100 lines of css like did tina, see it like like. Have we shown this to someone else? I think that's a human thing and I think you can cut down on the boiler plate by like we can just streamline. I think it's like I.

C

I think that maybe we should just copy what's in the gitlab product code base, because it's like what does this do and why um screenshots and screen recordings?

C

If you want to it's optional but encouraged steps to validate locally, um which again is like optional but encouraged and then like a link to their mr guidelines right- and I think we could do something like that- that's basically the same deal and it would be shorter and, like you can delete you can take what you want and leave what you don't and like we just need to have human people do better at catching the stuff that we've tried to catch via markdown that everyone just skims and deletes.

C

Which is a fair thing to do like it's a. I think. It's like a reasonable thing to skim like dozens of paragraphs of markdown.

F

I just this morning found a couple like tiny regressions and created issues, and I deleted all of them, except for the labels. Here's the thing: here's the link to the slack thread, um and that was it.

A

Yeah, it feels better billy dan. Clearly, for I don't know, the template doesn't meet the needs for what we're trying to do.

F

I have zero qualms when it's literally just a shell issue, so it shows on our boards and we get a point for it.

H

Okay, so I think I'm next um so uh I saw this iteration that um a lot of merge requests range, so lauren we're merging a lot of measure requests and some conflicts appear. So I saw uh that um some conflicts are not being done correctly and some code is being lost. So I think that we need to take care more of the conflicts and check both both code blocks and see what needs to be combined between the both the two code blocks, because sometimes we only do uh take this one.

H

That is from my measure, request or take this other that is from from head, but maybe we need to combine both codes.

H

So I think this point is to uh take very caring of the conflicts, because we are losing some code in the in the merging and right now we have like three measure requests per day, so it's a lot of code that maybe uh can be missed, and uh regarding that um other thing that I saw is that some conflicts are only indentation, so I think that maybe is better to have indentation rules for everyone and not what the ide has as in the settings.

H

So maybe we can talk about that later to have indentation rules and linkedin and all that stuff. I know that I did some things in the listing, or maybe we can add indentation rules and some other things.

H

And that goes to my next point. That is also check. Where are the regressions, because lauren found two regressions uh today that um were linked to some changes that were made to generic components, and if we do changes to generic components, we need to be sure that we are not breaking anything, because there are some components that are being used in more than 10 pages. So I think is also take very care enough regression, and that would be for me.

C

I think for the regression like you can't do we can't do regression testing without having like an acceptance like, except it's criteria right and like, like. I like, I, like you, you're you're super right, like the answer to like to catch.

C

A bunch of this is to like spin up cyprus and do visual regression like differing on all the merge requests and that's something we can absolutely do, um but it will be like wasted effort until we have like a baseline, that we don't want to regress backwards from right and there we're going to get all this like new brand updates and like a bunch of this work, that's coming like this quarter so like. I think I think we should do regression testing.

C

uh We said, but we've said this for as long as I've been here and probably longer, um we absolutely need to do visual regression testing, but I don't think we can put that we can do that until we are like at a point where we can say that we know what the right answer is right like we need to know what all of the components must look like, or you know some meaningful percentage like 80 percent of them must look like before it's worth the time to invest in regression testing, but when we go to plan this and like when we're communicating outwards on these projects, like the regression testing needs to be a part of the plan, we also can't say like oh well, we'll do it when we're done like.

C

I think that should be part of the definition of done. We just I like like this is a thing that, like I, don't think test driven development works well for for visual regression, testing for something like this, like we don't want to write these tests. First, we want to like iterate get happy with it and once like designers, stakeholders, everyone is like happy with how it looks. Then we say cool like we grab cyprus.

C

We take a snapshot of it and we say this is how it looks and like every time it changes if it changes.

C

You know we like fuzz some difference on it and if it goes beyond the threshold we say hey, we have a regression, um but we can't do regressions without uh without a standard first, so, um although I'd say super high dude like a hundred percent, let's do regression testing and let's make sure that it's part of the plan and if it isn't part of the plan, because we don't have time, we should communicate that if we don't make regression testing part of the plan, we will have regressions and we will spend time like infinitely battling regressions afterwards.

F

Nine comment: piggybacks off that um yeah there's like 12 mr shipping at least a week, and when they're all touching global components, extensively like I'll spot check some pages from each content type. We have like over 60 pages. I can't check all of them if most of them look good cool, we're moving fast.

F

There are going to be regressions, but we have a great team. We have the entire company they'll, let us know- and sometimes it's a really quick fix, like those two that john patched up this morning, super small real, real quick. So it's not. I don't think it's like the death to our team. If we we have a couple regressions because we're moving so fast, and maybe we have like a thorough weekly regression like the end of a sprint or the start of a sprint to make sure we're catching stuff.

F

But as our site grows, it's gonna get harder because it's gonna get over a couple hundred pages, really quick.

I

I just wanted to call out a point that I thought was really useful that I had seen with netlify the product itself, where it'll, when you're like generating like uh you're building out a static site generator it'll tell you like what, like a number of pages, that have changed. So it's like if you're changing something like card.view it'll. Tell it'll tell you like: hey, like you, know, company and solutions, and all of these child pages changed like we don't know where it's changed, but something in here changed.

I

uh So I don't know if that would be helpful for us without, I feel like we're still like in you know that kind of very early land where that stuff might not be as beneficial but something we could certainly look into as we're starting to get more stuff rolled out, um and I just wanted to call that out, because that's something that I always thought was super cool.

C

Yeah we get, I mean, that's the those are the regret like we can do the same thing I just like. I don't think we should until it's like, because if you, if we set it up right now, everything will change every time. You do a thing like it'll be noise that we'll ignore every single time. Like that's, that's good like if we do regret visual regression testing too early. It's just going to get so noisy that we'll never pay attention to it.

C

If we never do it, then we'll never have it so like we absolutely like it needs to be part of the plan, but, like I just I fear, setting up regression tests that everyone learns to ignore because they're like every time. I make an mr. The entire website changes because, like we're still in such an early phase that like that, is an expected behavior right.

D

um Has been considered to have an staging environment uh with all of uh iteration uh changes, all the all the mrs deployed and uh make the regression on that the staging staging environment before merge to production, I mean it will be a bigger task, bigger for make a regression for everything, and we will need uh someone to to do that anyway, but we we will uh avoid to have that kind of issues in production. I mean it's just an idea. I don't know um I I use one to share that idea.

E

I think we can do that with the review apps can't we.

D

Yeah I mean I mean it's it's easier to make a regression for juanimar to do instead of doing regression for everything.

F

We're already going to start a branch for our whole branding refresh and do like a big reveal branch which will kind of be our staging. That is going to be a change for our team already. I would hate to have another one on top of it,.

C

I think it's a good I like started like, I feel like I'm uh repeating myself too much, and I like I, don't I don't want it to be dismissive. It's like yes, that is absolutely what we should do just like not now like.

C

I like, I don't think we're ready for it, because, like it's the same fundamental problem as like, we should do the regression tests against an environment that looks like production and like we can have things that run on a cadence of like we can have like daily regression tests where we don't even need to run, because the regression test can be expensive.

C

We don't need to run it on every mr, but we can, you know, have a daily check, an hourly check, every six hours check but like to reiterate one more time like I don't like everything's changing we're about to rebrand.

C

We should not spend the time putting that together when we're about to when we're about, to cause regressions on every single visual element of the site right like because it's all gonna change with the new brand. So, like we'll just fail the regression test every single day, and that will be an expected behavior and I don't think we'll be adding value like until until we get to a stable point where we say like the work is basically done.

C

It should not regress from this point, but I would expect visual regressions every single day from now until the end of the quarter and like, I think we just have to move forward with them right, but like again like that is exactly the right idea, like 100 staging environment run the regression test on them. Let's do it. I just think like now is not the time to do it.

A

uh Do we want to move on I'm already kind of eight minutes over? So I don't keep everybody here, uh but just did you want to go over that last point.

B

Yeah so, while y'all were talking about number one of the, how are we going to deal with the mr issue issue? um I found this link to an issue that already exists, and there are a couple before that. There's one that's like four years old, one, that's five years old, all asking for the same request of.

B

Can we add, mrs to issue boards um and tyler actually had commented on this one in particular like a year ago and becky was on board, but I don't think she's here anymore, um but I was just curious like can we push forward to get this feature into gitlab so that we don't have to keep using workarounds um tyler? You have to comment there. You wanna go talk.

C

Yeah, I don't know you know, I mean we gotta swim upstream against whatever process like you know, the business has to decide that they want to do it right, um but I think, like the thing that, like I commented on this, because I was hoping that by commenting on it, it would like be another like tick mark in the should we do it or not. So I think you know anyone on this call or watching this video who, like wants this thing, there's a link in our agenda to the specific uh feature request.

C

I think just go and just like type a comment and, like I think, there's like six six reactions on mine. I think it's more powerful to like type three sentences and be like I want this too, because xyz like I like, I pull, I like linked it to our communications handbook and I was like in the handbook we say we're. Mr first, but like mrs, are not like the easiest thing to work with to track work, so um I think go write three sentences on it and see what I like.

C

Who knows, if that'll be what it is or maybe someone's working on it right like or getting ready to work on it? Who knows not me.

A

Well, well, I think that's everything for this retro, thanks for watching and we'll see you next week in our sprint planning our iteration plan.