GitLab Create Code Review Group, 14 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: GitLab 14.2 Kickoff - Create:Code Review

Description

14.2 Kickoff for the Create:Code Review Group

Planning Issue: https://gitlab.com/gitlab-org/create-stage/-/issues/12871
Release Board: https://gitlab.com/groups/gitlab-org/-/boards/2159734?scope=all&utf8=%E2%9C%93&label_name%5B%5D=group%3A%3Acode%20review&milestone_title=14.2

- Sorting of MRs by merged and Closed: https://gitlab.com/gitlab-org/gitlab/-/issues/18458
- Retain location in Changes/Overview Tab: https://gitlab.com/gitlab-org/gitlab/-/issues/297440

Better defined mergeability: https://gitlab.com/groups/gitlab-org/-/epics/5598
Restructure MR Widget: https://gitlab.com/groups/gitlab-org/-/epics/5589

A

Hi, my name is kai armstrong and I'm the senior product manager for the create code review group here at gitlab today, I'm here to talk about the upcoming 14.2 release and what the code review group will be working on. So let me go ahead and share my screen and we'll get started.

A

In 14.2 uh you're, looking at the release board right now, you can see a lot of the issues here, I'll link down to this below the video, but there's a lot going on, and so I want to touch on a few things that are pretty important here. The first is a couple features that we're going to be working on, and so one of these is going to be.

A

Allow sorting, mrs by merged and closed dates, and so we have lists of merge, requests on the merge request, dashboards and project pages and other things, and you can filter and sort those by a variety of ways.

A

But you can't sort those by merge date or close date, and those two are really important options that help you understand when code was actually added to your code base and can help in diagnosing issues that you find that have been deployed to production, you're trying to isolate, merge requests to a certain time period or they can just help. You understand the order of things that are getting into the code base and when that's happening, and so we'll be adding both of these options to the list.

A

It's a really minor addition, but it's something that should really improve the workflow when you're. Looking at these merge, request, lists and trying to understand, what's happened and when that has happened.

A

Another small but impactful change that we're going to make is retaining your location and the overview and changes tab of a merge request. And so, if you're familiar with the merge request page when you're looking at a merch request, there's a changes, tab and there's also an overview tab and those you might bounce back and forth between both of those tabs.

A

And sometimes your position can get lost as you change tabs, and so you switch back and forth and you're not in the same place. You were, and you have to sort of reset your context and so we're going to be tracking your positions through those. So that way, when you go back and forth, you should stay in the same spot on each of those tabs to make that context. Switch a little less dramatic.

A

The next thing I want to talk about is sort of the two big things that we're focusing on not only in 14 2, but throughout sort of the next quarter of work that we're looking at in the code review in the merge request area and so the first one of these is better to find mergiability, and so we're going to be working on all of the logic and the backend and front-end changes that are required to make our merge button work inside of gitlab, and so the merge button in gitlab is pretty complicated as it stands today.

A

There's lots of back end logic and front-end logic. Some of those contain various amounts of business logic.

A

They also include all of the checks and other things for pipelines and security scans and other events that are happening inside the merge request, and so we're going to be taking a sort of ground-up approach to building a new way to deal with mergibility and merge requests, and so we're starting that in 14-2.

A

We expect that to run probably three- maybe more milestones to do that, um so that we can come out of this with a simpler to develop against and easier to understand and diagnose, um mergeability sort of area, and the key benefits to that is you'll, see, there's a lot of issues linked in here that are bugs and other things that are they're very hard to diagnose and understand, and they require certain conditions, and that's just because the logic of this is very difficult.

A

So we'll get some usability improvements and making that process a lot stream more streamlined and we won't be waiting on checks from the back end and check from the front end and various other places to happen. And so you should see some improvements into the reliability of the merge button, but also this will help us close out new, bugs or other bugs that might be introduced or interesting.

A

Behavior that's introduced later because we'll have a simple way to sort of go through these and how all of these should be processed so we'll be starting on this in 14.2 expect it to be a common theme and look for improvements in the merge button there as we're doing that work in the back end. We're also going to be working in the front end to sort of um refresh and redesign some of the merge button area.

A

What we call the merge widget inside of the merge request page, and so, if you take a look here, this is sort of what the the merge um button can look like now with some various pieces.

A

This is what we want it to look like um in the future and there's a figma file here that I'll I'll go ahead and we can look at just one of the base states here.

A

This is what we want. The new structure of the merge request button to look like, and so we want alerts sort of attached at the top, a title, some actions and then merge options and then non-actionable text and then a merge button. um The merge button today can sort of say a lot of different things. That's inconsistent in how it does that, and so we want to. We want to build some more consistency into that and you can go through the sigma files linked in the epic I'll link it down below.

A

You can sort of look at all the various pieces that are, you know how it looks today and then how this will look in the future. So if you notice in this one we're looking at um threads and so when there's unresolved threads, you have to resolve those before you can merge and there's a lot of information in here. We're going to simplify that and say look the merge is blocked. All your threads must be resolved. Do this and then here's your other actions and other information down below that'll help.

A

You understand what's going to happen when you get to that point, where you can merge and so we'll be working on this effort, also starting in 14 2 it'll.

A

Take you know two to three milestones again for this work, but we're doing this in conjunction with the other work that I talked about for mergiability in the back end, and so we think both of those improvements together they'll really be valuable in improving the merge experience and what you're interacting with when you're trying to get that merge, and we know that's the most important part of when you you finish that code review.

A

You need to get that code merging into the code base, and so we want to make that process more reliable and make it easier to get to that that state. So I'm really excited about both of those changes and the progress we're making there in terms of the usability and reliability we'll provide there I'll put links to all of this down below. If you have any questions, feel free to comment in those epics comment. There tag me in issues and I'm happy to take a look thanks.