GitLab Create Code Review Group, 13 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2021-04-13 Create:Code Review UX Sync

Description

Weekly UX Sync for the Create:Code Review group.

A

A

And I guess you've got the first one up.

B

um Yep, um I think we have only this agenda, I'm also sure pepper will join or not, but I can also just talk about it and petrol if he joins later, he can add more colors here. So I was planning for the solution- validation, very quick one for this concept, waiting for and as petro ping. Some of you already. We found some gaps in this concept while we are translating into this concept into the high fidelity prototype, and these are the questions that we had and we discussed in our 101 with petro.

B

So we don't have very straight answer for all of this question yet, but I think it would be worthwhile if we revisited those questions first and then. If we have some answers, then I think we can move on to the actual solution- validation, including high fidelity, mock-up, so hi peppero, so he just joined. I think he can add more comments after all, so the possible next step would be. I would start mapping the possible any possible use cases for the scenario, including any edge cases and then okay.

B

This is the possible user flow at the moment, and this is the proposed user flow if you're introducing this waiting for concept and if we are adding more details in the design, including the lo-fi, mock-up and and then we are ready to conducting the solution, validation and, in this step three before that, of course, I'd love to get more feedback on catherine's, because the planning is really rough like we include some of the very short usability studies there.

B

So I love to get some more feedback and then, according so corresponding to the feedback that we have in the actual solution, validation. I think I will need to revise this design a little bit and then ship it to the engineering team and the rough estimation for this timeline would be around a month, including everything.

B

But I think this is good timing to revisit this concept and fill this gap and then make sure we are going to the right direction before we shift this feature.

B

Do you have any other questions or petrol, please feel free to add more. I just explained.

B

A

I get I I mean, I think my biggest question is like it sounds like the pieces that there are gaps on are interactions.

A

A

But that doesn't feel like it means that we shouldn't necessarily do work on this front, and- and you know, we have a capacity discussion to like get through and figure out what we have capacity for for performance stuff. But what I would actually expect is that, like.

A

um Like in 1311 originally or 13 10, what are we in 11.? We were going to do the filter part of waiting um that doesn't feel like we still shouldn't or couldn't do I guess, um and then even some of the other pieces feel like maybe they're not unchanged. There might just be enhancements to the interactions, and so I guess I wonder if like should we stop work because it's likely 1312, we have some capacity, 13 well 14 and 14 1.

A

We maybe don't given like how long it'll take to get through investigations for performance work and where that is and so um yeah I don't know. I guess I just want to get a sense of of how we feel about stopping work or not stopping work here.

B

um I I can hear what you're saying, but I think it's still important as the solution validation also validates some of the interaction here. So my initial concern was like. If this interaction is not well defined, then our outcome from that research might be not correct. So I think it's better to just step back just just one step back and then and then rework, but I don't think, as you mentioned like it would be like crazy, radical change.

B

It would be just additional stuff included in the details, but I I'm still not so sure so when the port and my initial exploration is ready, I I'll make sure to share with you and pedro and katherine so that we know what where we are heading to so I'll. Try to speed up on that.

C

Yeah, okay, um yeah. My my understanding is that the.

C

Those parts that I mentioned, where we need some way for people to find the merge requests where their attention has been requested or that someone is waiting for them.

C

I think that's, that's part of it and we will always need to to solve it and which, in turn means that we need to save that indication and attach that indication for the user and save it in the database and say pedro. This, mr, is waiting for you like. We need to save that somewhere and we would need to filter, merge requests based on that.

C

I don't think that's changed so that issue that you were mentioning um the filter waiting for filter on merge, request list page. um I think that's that's the issue right. I don't know if that's only backhand or front-end.

C

um It's both, but I think uh I think that's still needed, and I don't believe that anything about that will I mean I don't think that the the core concept behind that will change. Maybe the filter name could change. Maybe the uh the the the labels in in the navigation drop down could change, but I think what sanjiong was trying to say is that we're mostly trying to explore is how what what does the user do to get um merge requests on other people's lists?

C

Is there any automatic behavior? How does that automatic behavior work and how does the interaction work, not only in the user interface but also in the back end like what is the logic that we need to accommodate to put merge requests on that list?

C

um I think that's what we're still exploring did I let me know sandring if I said: okay.

C

So I don't know if yeah go ahead.

A

I was just gonna say I think that makes sense. I think.

A

If there's a possibility that the language changes right, we don't call it waiting for anymore. It may actually make sense to not do any of the code because we'll probably like end up naming a database table waiting for or something crazy, and then we'll always have this like um complicated code in the back end. So maybe it's fine to punt down the road for now.

C

Yeah, for example, one of the things and something you can add more color to this. But to me like one of the things that sanjiang shared with me, is that she was showing this uh like the current design to one of our product designers and they one of the feedback that they gave was. Why do the buttons like to to call uh like to wait for a signee or to re-request review? They look the same. They have the same icon, but they have a different label.

C

One of them says wait for assignee and the other re-request review, um and- and it's interesting because for the wait for assignee, it's linked to the waiting for concept, but the re-request review is there's a gap. There I mean it's, you can infer the association, but it's not as clear as uh wait for assignee.

C

So do we need to change the labels of those buttons so that they are the same like, for example, I don't know request their attention or I don't know something else that can encapsulate and have the same, consistent thing and maybe as you're right it. It could affect how the filter is labeled, and we would then need to change how the database set up um sanjong.

C

Do you want to expand more on that.

B

Yeah and and kai, thank you for bringing that, because I never thought about database naming, and I think that should affect, of course for sure and as pedro mentioned like I, I really got interesting feedback around like those. Why are we using same icons for a different action and I think how it looks like on the current design in the design proposal, maybe as a first time user.

B

They are confused because so they can actually re-request review for the reviewers, which is related to the review status and also we can also make an action button just beside the assignee which will occur waiting for assignee. So I think we're kind of mixing this review status and also waiting for waiting for assignee status.

B

I think it's kind of like mixed in concept to the first time user, so I think it's worse to revisit, maybe just changing the icon and as pedro mentioned, I think we need to relabel- or I'm not so sure, I'm just thinking out loud, but I think it's worse to double check those hypothesis first and then move on to the actual solution, just just to be safe.

A

Okay, I think that's fine.

A

It makes sense to me.

B

B

Thank you. That was my agenda.

A

C

A

C

Yeah I was, I was just quickly quickly going to ask how much capacity can we expect to be allocated to performance.

A

I don't know um like every day or every month around this time, planning has snuck up again um only we're predictable and on the same schedule. um I don't know.

A

I think I've asked the problem we have right now is that we don't we don't know what we're gonna go do yet, if that makes sense like one of the things that we're still waiting on is defining uh we've got to like get our test large, mr, and so I imagine much of what we'll be spending 13 12 and why you know I've got a little hesitation, but I I think all the reasoning is sound is we may not be pulling a ton of 1312 capacity to go a dress performance because we might still be trying to like build the test environment and do investigations, and I don't know that you know whatever eight engineers are gonna do investigations um there might be like two or three, which leaves like this other work.

A

The flip to that is that we've got because we lost 1311. Essentially, we've got all of the 13 11 work that we were going to do that moved backwards into 1312, there's some bugs and some other things that we're gonna, that we were planning on addressing that we didn't get to because of database work.

A

So we may be able to fill that. I imagine we'll fill that capacity back up anyways. So I don't know I I don't think we'll allocate a ton in 1312. I would expect us to allocate much more in 14., um just given that, hopefully we'll have like a a plan and some concrete things that we're gonna go do right. Now we don't have any concrete things. We've got a lot of a lot of stones to still turn over, but but we don't know which ones are the good ones yet.

C

Yeah, that's that's! um That's good enough for me, um yeah anything. I mean I'm still trying to understand what what I can do to help, but I think at this point my understanding is that it sits in in the engineering courts and in the quality team to come up with whatever it is. We need to come up. um Do you think, there's something that's from the ux side that we could help.

A

um I don't know yet, and I will say that, because I've sort of been sitting watching um waiting on like that, 95th 99th percentile data to come back to sort of get a sense of where we think what a large mr looks like and then I think, as a group, we just need to make some decisions about the things that we won't have in there, which I know you suggested like file, size and types of files like binaries and and others, and that we without going you know back into italy.

A

I don't think we can get any of that, and so we'll sort of just know that there was like this. Many lines changed and this many commits, and that might be all we know.

C

Yeah, that's fine right, yeah.

A

Yeah, we'll need to make some judgment calls, I think about.

A

What what makes sense- and I think that'll take all of us to sort of like agree that we think this is a reasonable but large, mr and then have that um and then trickle that backwards to quality in other people. I think one of you know one of the concerns that we've all I think long had with the quality test is that they they there's one that has like 30 000 commits and one that has you know like 10 000 files, but like those are different things and like not really representative and like we wanna.

A

I think what I would like is for us to to set like we believe this is reasonable and also like, if you tell us that you've got something that's outside of this, we're not gonna like. We just need to sort of be able to make it clear, at least for the time being, that we're not addressing sort of things outside of that, um and so I don't yeah. So that's a long one to say saying. No, I don't think there's anything that we need for ux right now.

A

We need that that first set of data to come back from either the data team and nick or just nick, depending on who gets the access faster and then and then start building out from there.

C

Cool yeah makes sense.

C

Yeah one other thing that I wanted to to ask is.

C

How what do you feel? How do you feel about the.

C

The different process now that we're experimenting with creating shared key results within the code review group instead of having.

C

That top-down approach to setting okrs and.

C

Yeah, I think, let me rephrase, I think my question is how how how good or bad do you think the this okr that we're setting as a core review group and also the other, um the other okr for from the ux department. That's uh like generated a lot of discussion in slack.

C

Do you think that is helping you more as a pm, or do you think that's just creating more frustration and confusion about what I, how how do I do my work as a product manager.

A

A

I, like our group, coming together and picking the things that we thought were important and that we thought we could drive an impact on, and I thought that thread. If you look at the issue that we had and you look at um all of the collaboration in there and how things got bounced around like.

A

I think that is exactly the intent of what that process was supposed to do, and I think we did a good job and then we also got to a point that we needed to get to, and I will say we sort of got to a point we needed to get to you know without.

A

Other outside influences, although towards the end, all we sort of got was outside influences and- and I think that's probably where my frustration in the process is- is we set an okr and then because, because it's sort of then um became a focus area across the company that top-down thing started to happen and they sort of conflicted with ours in a way that was like.

A

um You know, ux talks about merge, request performance and they talk about usability things which is logical and makes sense um right, like as you go up the ux chain. I would expect that, like the nuance of like usability and performance gets a little lost because it is, it is nuanced, and so, like you started, seeing like sus issues or not suss, but like async critique issues and all these things that are sort of like yeah, we're not disputing that. Those are good things to do.

A

But we're disputing that like we as a group have a finite amount of like capacity, and we have to pick one thing, and this is the thing that we're gonna pick um products all the same thing like it happened on the product side. They started doing it.

A

I have not seen anything from like engineering, but I'm sure there was like that and we've, and so we've had to like go and sort of re-fight all of those fights and and get to a point where we're like. No, this is the one we're doing.

A

This is how we have defined it, and this is all our group is committing to I'll, say the ux one was particularly confusing because there was like three things in there that all sounded like they were code review, and I think anyone outside the group could not have read that and thought anything different.

A

And yet you know we we sort of knew that those were going to be handled by other people and that some were not engineering efforts but like that, wasn't explicitly clear, and so then those got brought up in like the same sort of performance.

A

Conversations about mrs, and so um I don't know I I wished I'd love to know how other groups dealt with their like shared stuff, and if you know, if you did your shared okr's and it didn't become like the ceo's okr like you probably were fine and like it wasn't a thing and it didn't cascade down, but when, when it became the ceo's okay, everyone sort of was like.

A

Oh we've got to do something to show said that we're like dealing with it versus saying, like oh code review, is like got it. Here's the one like we're, just gonna use that and like we're all in, like all the other functional groups being like we're. Okay with that as the one, and I think that didn't happen yet, but this is the first iteration of this sort of process. So maybe it gets better.

C

Cool yeah, I I was just concerned that it was um yeah. Just I mean in a way you validated what I was, what I'm going to say, but it confused things a little bit for everyone and for you.

C

Yeah, I just I just want to make sure that um we're not making your work even harder than what it is um by trying to help. You know, because.

B

I mean that's, I.

C

Mean we we're assuming positive intent from from everyone, but you're right. It's just a confluence of so many things at the same time, and so many people trying to focus on the same thing that it leads to confusion and duplicate work and having to fight again for certain things that were already settled.

A

Yeah, I will say I don't. I don't think my work was harder by anything. This group did. I think my work was marginally more stressful for a period of days, because it was trying to realign everyone, um and I felt like at a low level the people who are involved and have to do the work. Our group, we knew what was going on.

A

It was just then like translating that back up, because there were multiple conversations happening across every single department, with an inconsistent group of people from all the groups, and um I think we were slow to recognize that, like I was having to have that conversation, and michelle was having to have that conversation, and you were having that conversation with michelle like as a group and like are with marcel, like you, everyone was sort of slow to be like oh yeah, I'm having to tell my boss and they're having to tell their boss and they're having to tell their boss, and then we were sort of like wait a minute.

A

We just need one talking point and one link and everybody just say the same thing. You know we just um and then we I think that helped too, when we were sort of like no. This is the one, and now we you know michelle did a great job, creating the epic and we've got like the epic. That's like this is the one everyone go here.

A

You ask. Anyone like you know. The default answer out of our group just needs to be go. Look here, that'll have the latest information and we shouldn't try and like have anything. That's not that um and I think that'll help help that process too and we've gotten there and it just.

A

I think this was a learning experience for all of us, uh particularly for product who has never been involved in okr planning outs like below a vp level.

C

Yeah I'll add the link to that.

C

Epic, in the agenda, cool.

C

um Yeah, that's.

B

C

I wanted to know um yeah, that's that's all I had and I'm glad that we're focusing a lot on this and um yeah. It's interesting, because I was talking with marcel earlier today and that our group doesn't focus a lot on monthly, active users um compared to other groups, and I mean.

B

C

So many things to do, but we could focus a little bit on adoption and we're not focusing on adoption, and I think that's fine, but it's interesting how other other product managers are.

C

Yeah would like to focus even more on on on mao and with these okrs and just performance and usability, and all of that it seems like the way we're usually.

C

Measuring product managers is through the monthly active users, and these okrs are not aligned with that. Somehow so it's it's interesting.

A

Yes, now's an interesting metric for sure yeah. I don't know if it's the best, but it's interesting.

A

um I've got to jump. It was good to see everyone. I will see some of you tomorrow um short week this week, friends and family days friday in case you had forgotten and hadn't put it in, but uh yeah get ready for 13 12., bye. Everyone bye, bye, everyone, bye-bye.