GitLab Digital Experience, 25 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Digital Experience Iteration Retro 2021/03/25

Description

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

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

Inbound Marketing handbook page: https://about.gitlab.com/handbook/marketing/inbound-marketing/

A

Hello, everyone and welcome to the digital experience uh sprint retrospective for this release cycle um march, and it is the 25th today um so uh we'll start off. uh Are we starting off with things that went well, I guess I said that so that's what we're doing um uh so, yeah, I'm not sure who wrote this first item, but if you did, please speak up.

B

That was me. um I forgot to put my name um things that went well for me. um Was intern online cross-team collaboration with the events templates. um I felt that people responded quickly with quick decisions and proactive problem. Solving. uh There was very little need to manage expectations.

B

Everyone's really really onboarded to the iterative approach which I appreciate next is laura.

C

And yeah uh we have ongoing conversations about our grid uh system. A happy accident where uh we discovered tailwind kind of does.

D

C

We needed to do out of box, um so that's great uh and I'm glad that, like javi and anyone else, who's involved in great discussions was able to kind of uh align with me on that, uh and I think sung me here up next.

D

Okay, thank you so this week uh one of the things that went super well for me is my first template and templating experience on ruby and thanks to tyler he's the one that has been hoping that this will come to person yeah. I think it's coming I on personal projects. I still don't think I'm gonna be using ruby, but now I think I'm feeling comfortable working my way around and doing what I'm doing so that actually went well and thanks to everyone that has been working on that stack for a very long time.

D

There was good documentation and I already see our files correlate with each other jelly brandon lauren thanks a lot. That's awesome! Yep and.

E

I avi it's me. Oh.

D

E

Other jay uh yeah I just want to shout out um lauren for leading our latest get 101 class. It was awesome, love your enthusiasm always and uh ever so slowly, beginning to understand gitlab.

E

um I think now it's hobby.

F

Just realized just her initials are like one letter away from basically.

E

F

Okay, um I just wanted to shout out that our code reviews have gone a lot better, like I think the quality of our the feedback that we give each other has gone way up, at least like since we started here. So I would encourage us to continue like that trend because, like I think like when I first came, I like didn't know what to look for, and I think like, as we've gotten like a groove and more comfortable with each other. It's like easier for me to say like this is good.

F

This is bad like we should change this like. This is a suggestion. That's not blocking. This could help. This could not help yeah up next is lauren parker yeah.

G

The um blog post template deployment went well and um the slack announcement helped by giving places, people can add direct feedback that needs to happen right away and for future iterations and everyone hopped in and it.

G

A

Cool, um so I guess, uh unless uh laura wants to vocalize that little note below, um we can go on to the uh things to improve on for uh next uh sprint cycle, and it looks like.

F

uh Javi's up first yeah. um This is kind of a little bit related to like this bigger point that I think some of you all have put in the in the things to improve on like in your own sections, but like I think I see this issue like more so like when I'm actually trying to publish npm where it's like, if we're on version, 0.7.4 and two people are working on things concurrently like who gets to get like the 0.5 bump and sometimes like.

F

If let's say this is something that happened where it's like, and this is like totally like. There's no way to know like like tyler was working on something because he was like trying to leave before friday and like I was also working on something on friday and like. I think we started using like the alpha tags like differently, so we both had like different alpha versions of like the same thing, um and so then, when we went to the full version, it was just like oh shoot.

F

So then what I had to do like um after he was gone, like was essentially like, say like all right. Like I'm version this like this is zero 7.6, for instance, and he alright and then tyler's version are 0.7, and then I have to make like a 0.7.8 that has both of our changes um and so like stuff like that was just annoying.

F

The rebase was like crazy because it's like you have to find like in what order do you want like the things to be like brought in, and so that was a pain in the butt. We should find a better way to deal with that. um Another thing that I have on my next point right here. I actually have three points: wow.

F

Okay, um point number two is just like: how do we go about backlogging stuff, I think like saw me in the beginning of the sprint, was like I'm not really sure what to work on, and I feel like it makes sense to like.

F

I don't know like improve that process like a little more um and I don't know what that would look like, and I don't know what suggestions people have for that, but just like in my head, it's like.

F

We have requests that people give us and then like for it to reach the backlog like a backlog like we have to go through and like make sure that the request is like a reasonable request, something that we can reasonably deliver in two weeks period. Time like it's like been like refined.

F

um So that's like what I have, and I see people writing comments. If people want to jump.

G

In I put everything in the inbound marketing backlog, milestone which is giant and unmanageable, but that's where they live right now,.

A

Yeah, so I think in terms of how to how to prioritize the work um part of that is during the sprint planning like we know that, there's stuff coming in, we know that there's stuff we want to do, and we can all you know talk about uh what projects we propose that we work on that sprint. Obviously that doesn't help the things that are in the backlog. So it's it's kind of going to be a discovery process of how we can do that uh moving forward, but there's always going to be too much to do.

A

That's just the nature of you know having the workforce that we do at a company as large as we do, and you know, there's there's always more projects that everyone wants to do but uh yeah. How do we prioritize that good question, um but it's important to focus on the okrs.

G

I am have a couple epics that I've uh was talking michael with, and that happened this one.

G

What do you guys think about adding these epics or issues to our sprint doc um so that we all know that they're there and then we can choose issues from them um like every before every sprint. Like oh, hey, everyone, we should probably be looking at these things, yeah you don't have to, but just okay yeah. I think.

C

Yeah, I think I'm always like combing through my past history and like links and whatever trying to find which okr tickets and stuff yeah having a single source of truth would be awesome. And then, if we want to do work that fits within one of those, we can create issues within those epics and they're easy to find. Yes, love.

A

Sounds good I've been keeping a personal bookmarking list of the things I should be working on, which I just realized does not help everyone else. So, yes, having those in the planning doc would absolutely help us. I think.

F

Sweet and then very quick, last point um like in my head- I I don't know I was thinking about this earlier today um is like people are gonna like stumble onto slippers and like be like. What's this like what is all this code stuff like? What does this mean to me like? I feel like that. We should have like an entry point. That's not so like so tied to understanding how code works. So it's like people can like just like consume.

F

It understand the concept and like if they don't necessarily care how it works like they don't have to know um we we we can have. I know there's like a lot of different ways to go about it, but that's just something that I wanted to bring up. um If anyone has like points on that, um I.

G

Thought that was storybook like the website.

F

It has a lot of like code stuff in it. If that makes sense like you, you open it, and it's just like, like yeah there's like a lot of there's yeah, and I saw someone put a point so if you want to talk about it, whoever did that.

D

Abby, are you looking forward to develop a cartoon animation explaining sleepers, like oh, just leave hers I'm just kidding.

F

I mean I wouldn't be opposed but, like I think, there's a better solution.

H

I don't know, I think, go ahead.

F

This is all you, I think. I know what you're gonna say.

H

Well, I was gonna, say well, you may or may not know and like we did a little run-through of figma last week and then we have storybook and then we have tailwind like they're in and of the same thing. So I think it would probably be a good idea to align on a video to just to get people to understand like it's, not just like michael kind of pointed it out.

H

If we just did a video on figma, it would make it look like that's all we're producing, which is just a couple of graphics and figma, which is not really just not really the case at all. So it'd be a great idea, I think, to align- and we don't have to do at this point. But whenever they say like this is all in the one thing, but it's just three different torch points and how this team outputs productivity, and so I'm not just showing them in isolation. So we talk about storybook and isolation.

H

Then we talk about tailwind and isolation when, in actual fact they all connect. So it might be an idea to do some sort of educational video on that to sort of take the weight off. So people know that everything is reflected in each other in a way.

F

Just to finish up this point really quickly, I think there's no way to completely like at some point, like people just have to like read some things to understand what it is. I don't know, but anyway, that's like the last that I had um laura you're up next.

C

uh Yeah um kind of related to your um versioning problems, uh it's just specifically uh in slippers. If I have one or two mrs open and then something gets merged in my other. Anything that I have open has merge conflicts and it's just that compiled css and the compile javascript or like yeah. If you've added a new package, then your package json is going to be um a conflict which is fine. It's just a matter of like you know, checking out each branch, rebasing or running a yarn build or whatever like getting it.

C

You know into a state where it's all up to date, it's just a pain to do that. We don't really need to be committing those compiled files because they get rebuilt on merge and on release kind of thing. So maybe if we add them to a git ignore or whatever you know like some sort of way to just like nope, we don't commit these like thousand line gobbledygook files that can't even be viewed in gitlab. You know in the interface.

C

So um if, if that's an improvement, we're all kind of aligned on it might be worth doing.

D

Yeah, I think the git you know will be very, very important. I think lauren. I think you spotted that on my present made request about some uh css files, that is in the disk folder which shouldn't be compiling over and over again. So I think we should improve on that area because I sense the same problem happening to me too.

C

Yeah, sweet um and one other thing I wanted to just go back when uh javi was talking about the npm version in conflicts, um brandon and tommy. You made some good points about maybe doing uh like an actual release cycle like having a day that we release or something and just we merge everything into master and then do like a release at some point when we call all kind of a line on it, but or or at least some sort of communication around who's releasing what version that might be helpful.

C

If we can figure out a way to do that, but yeah cool uh lauren you're up next.

G

um I'm just piggyback on your your comment on 8b um there's always going to be conflicts and dub dub dub. um So um I made a quick video this morning because there were other conflicts that hanif was encountering um and this isn't really documented in a great form for anyone using dub, dub dub. So let's make that better for everyone, I'm I'm I'm pretty spicy in my video, so I should um yeah make like a doc, um okay, nine. um What is the requirement to announce an mrs complete and ready for deployment?

G

I put um what I do, but I'd like to hear from from y'all what that is.

G

A

I mean I, I kind of go along with what uh lauren outlined and then also there's the mr checklist, that's mentioned in certain temp blitz. I think, and we have a handbook page on it. So I might add that item to her um list of things, but that's that tends to be more of a this- is a larger thing. uh There's two, I think I made two template versions of that where one is like a shorter list and one's a longer list, but it also it's not just the code right.

A

It also covers things like uh is this content inclusive and you know other other things that speak to company values. So it's it's always good to remember to go over that checklist as you're making those merge requests.

D

The last thing that I always do is just to check with the dri of anything that's working with that. Okay, are you sure we should go live with this page and if they say yeah we're fine, we can go live then. That is when I see it as okay.

C

One of the pieces of functionality that I've seen in the gitlab ui that I haven't used is um yeah. If you have merge requests that you've opened and you kind of go back and forth and you make changes and people are commenting and everything is um changing. And then you hit a point where you think it's good, but maybe everyone else that was commenting and reviewing has kind of forgotten about it or they don't know that you're ready.

C

There is like a little request: re-review like a little arrow beside their name as a reviewer or whatever. So like. I don't know what that does. I assume it like pings the person like emails them and says like please look again or whatever. So I don't know if we utilize that I haven't, I haven't had huge big pieces yet.

G

For the blog post, um I had to use that at least once um probably should have done it more because that there's like 15 updates so and I want someone to actually check it after I've done all those updates before I launch it, because I almost deployed it and updated the entire release blog, which would have been super bad and like that was like final seconds like. Oh, no, don't do that um yeah, it's nice to get eyes on it!.

F

I had like a a quick question that just like escaped me: I'm, like it's gonna, bother me now but like uh we'll, keep going I'll, let you know if the question comes back.

F

I remembered I remembered I remembered okay, so I know you all were gonna talk. Someone was gonna, talk, okay, wait! So notifications like how do you all have your notifications set up within like the gitlab interface, because, like I think right now, I have like all emails turned off and I have like this weird.

F

I have weird situations where it's like, sometimes I'll get tagged and I won't get notified and like if I'm digging through the issue like if I like, look for the issue myself I'll see my name tag like mentioned like three days ago, and it's just like. Why did this not like tell me so I have.

G

Yeah there's inconsistencies, um I have all the emails sent and then I have a folder in my gmail that funnels all the notifications and I look through it every morning, every lunch every evening and it's like 100 200, sometimes and then I have to select them all, delete it and it's just like a quick visual way to like search through everything, not great. But it's helped me because I don't get that to do pain every time either.

F

Yeah, I would rather have blown up emails than to like miss something, in my opinion,.

G

If you don't, you.

F

G

Get a thousand and then that's really bad.

A

And you can always create email filters too, in gmail, like uh basically you know say if it's app mentions me then put it in this folder or if it's uh you know from so, and so put it in this folder and mark it as read or you know, whatever you want to do, there's there's ways to filter in gmail, uh which is nice to have that extra layer of notification.

A

um Kind of you know sorting.

A

Cool any other thoughts on that item should we move on. We can always async on that later too. um So I think I'm up next um and kind of similar to uh what javi and jess were noticing about initials. Earlier I've worked with lauren for like two years now, and I guess I just never saw our initials next to each other, so like lb and bl, like you, know, kind of like one typo away from missing the person's name, but anyway um fun little thing I just noticed so yeah.

A

I just wanted to remind us, because this happened to me this sprint- that uh seemingly small tasks can snowball out of control into larger ones. So uh just a reminder for us all to add buffer time to our projects. um We don't actually know how long things are to take so yeah. That's uh always good to know, and I think tina's up next.

B

Next then, it's it's pretty much the same um as what brandon just said. I didn't account for time spent on tasks that weren't actually related to my boards or my issues or my epics, um so supporting the blog, for example. So it's a good reminder to under commit so that you have capacity to help the the rest of your team and to support your team on other things.

B

E

uh So I'm just continuing the conversation from the end of our ui to code meeting about how we want to hand off design to development in terms of an mr or an issue and who's in charge of creating that uh in the everyone was there, so I don't think laura or sami. Was there um maybe others, but uh the consensus at the time was like mr was preferred, but then there was like an issue that showing up on the board. So I wasn't sure if that was gonna, be like a blocker for us.

E

If we still needed an issue just for tracking purposes um and how far in advance you guys would like notice if at all or just like it's done, do it.

G

I will offer my opinion. um We need to have the engineering issues, so we can attach the mr to it, so it shows up on our engineers boards. I don't like that, but I don't see any way to get the mrs actually on our boards at this time.

B

And I think also um having conversations about changes in the amr is the preference for engineers and then using the issue to be like this is done, reviewed closed or having less conversations in the issues. More conversations, yeah like the.

G

Engineering issue: it's just a shell issue. We don't don't need to spend a lot of time on drafting that, except for issue the the labels milestone. All that stuff.

B

And that doesn't mean that our design issues need to work like that. We need to have conversations in our design issues, so let's keep doing what we're doing with our design issues so that we can house the conversations there and link to those threads in the engineering. Mr, when needed.

C

I also like the idea of um having an issue for like just have the source of the the figma files and stuff that's yeah, assigned to an engineer opening an mr. um It means, if I'm understanding this correctly. The mr would be um like open the entire time that the end work was also happening, and I don't know now, there's like an mr that's open. That is the design and then an mr that the engineer has created, or it's all one mr kind of thing there's no mmr for design, there's only one.

C

Well, that's what I thought we were asking about was like creating mrs for the design handoff.

H

No, we only ever get issues if there's any design.

E

Confusion around um when we hand it off. Are you guys going to be just doing an mr or you.

D

E

Issue attached and like how much notice do you want that, like the design work is going to be ending soon or like? Do you want to know at the beginning of the project that we're working on that's now in like two three weeks or maybe a month from now, you might have this on your plate or you're, just cool with being like okay, we finished this thing yesterday. Now it's yours do what you will like that's the kind of stuff I'm looking for.

H

Is there a risk? Is there a risk in that, though, with like a hard hand off, which is something that I think we should definitely try and avoid, like that's always caused issues in my experience in the past, where it's all of a sudden ta-da, here's something that you work on.

B

Well, that's why we have conversations with engineers and our design issues before it turns into an engineering issues, so I think um yeah.

D

I think, from my perspective, I would prefer just an mr for uh for engineers, because I've seen that my conversations have been splitted all around scattered all around. I have some conversation on the mri.

D

I have some conversation on the issue for engineer and I have another conversation on the issue for design, so I'm reading through three different threads, but I can eliminate the three just to just uh just two one single, mr for engineering, where I can have all my discussion related to that and if I still need to know anything about the design part, I can go back into that issue and look through so instead of creating another extra issue for me, so I can handle every discussion for engineering just in the mr.

D

So at the time when the design is ready, we can just anybody, can open an mr and assign it to anybody. So I think that can be a very small standing over from design to engineering so for uh based on what jesse is saying that? Okay, what if the mr is not something we should work on right now, yeah then it can still be there for, like. Maybe a couple of weeks before we start work on that right thing, I don't think uh engineering issue is necessary. I think it's causing more confusion.

B

But engineering.

D

B

Mrs don't show up on boards, so it's really hard for management. Yeah.

D

I'm trying to.

F

So I know, becky was looking into other features that we can use in git lab issue templates that we ended up not using for, um like the whole inbound marketing, I'm interested to see if we would be interested in use like looking into some of those ourselves to see, if, like maybe there's ways for us to like be creative about like instead of having like the idea of like we have an engineering issue and then a design issue.

F

It's like just an issue that we can figure out how to like how the project management can still happen, but have one issue um I'm. I think that there could be some creative ways if we're like willing to go through that exploration process, but I'm not sure if any of you have in the past.

G

That sounds like, I think, great idea to open an issue for and us all to discover and work on.

A

So I I will add uh kind of my experience on that is. As an engineer, I want one final document starting point. I don't want to have to sort through all of the prior conversations so like if we have one artifact it's great to have that one artifact be the single source of truth, but then, when I have to read through all of that to get to what I need and so part of the things that have happened in the past is like. Okay, that makes sense.

A

We could solve that by putting the final bit of information that the engineer needs in the issue description. Well, then, someone comes along and doesn't know that. That's where the final information needs to be and they're having more conversation and then goals, change and shift and the updated description never happens. And so then you don't know right, and so personally I like to have.

A

This is where the engineering is starting and all private prior discussions can continue to be ongoing. But like this is this is the non-shifting deliverable that I have and then I can review later. So so that's how it kind of ended up where it is in my head, but that's not to say we have to continue that way. It's just something to be aware of, as we have these conversations moving forward.

G

I'd like to piggyback on that specifically for the events, commit template um one or maybe a couple issues for tina that if that is going to turn into an epic for engineering with 20 30, separate engineering issues, so that won't be a one-to-one use case.

F

Yeah, I think that makes sense. I guess like in my head, there's like not like a one at least I record I've seen there's like a size fits all, but I think it's just more so like communicating like what do we do in that case, for instance, and like how does our team, um especially when issues are flowing within us, I think sometimes we may run into issues when we start communicating with outside parties, but I think just like for us to have like an alignment, I think would make us a lot more efficient.

F

So uh that's good. That could be an action item.

F

A

Good, um so I think.

C

A

C

Did we land on uh we're gonna be doing issues? I don't know if or did we land on we're gonna keep talking.

E

It sounds to me like the mr is going to be for where all the conversation happens and the issue is just a shell to track things, and maybe even in the issue, we literally just say. Please do everything in the mr and just like: leave it really blank, so people are forced to go over there. Cool.

A

That would be my suggestion.

C

Yeah so design does all the design work has their own design issue and then design creates an engineering issue, links the design and then engineers make an mr that's that closes that issue. Okay, you can.

G

Do that and engineers should create their engineering issues, because there might be many for one design. Okay,.

C

So, as soon as the design is ready.

E

C

Gets kind of tagged.

E

Hey this is coming up. You might want to make an issue or an mr or whatever.

F

Yes and there's the caveat that we will explore other things that might make this process better for us, because it's a pain in the butt. I think we all agree that.

C

That's terrible.

A

Sounds like we, we got to um a point where we we know what to do for that now uh moving forward and we can continue to discussion uh and iteration uh after that, so um yeah. I think um that out covers our our retro. Today um we have a few action items here that we have already discussed, but if we want to just kind of recap them really quick, um so it looks like we should file an issue for merge, conflicts and slippers.

A

You know and uh investigating what we want to do with that and add a list of epics and issues to our sprint planning dock, which is a good idea. We all kind of very enthusiastic thumbs up on that, and you know to do to look into project management for issues, and you know how we want to do that, uh how we can iterate on that uh to improve things moving forward and looks like jess is uh yeah and and kind of the conclusion of what we just talked about as well with design handoffs.

A

So that's it for this week. Everyone. Thank you very much and we'll see you later.

D

Right. Thank you.