This issue is for feedback on the new merge request homepage. Details about this new feature can be found in the documentation.
How to give feedback
Check existing feedback & known issues: Before submitting, check to see if your feedback is already captured in the known issues section or reported by someone else in this issue. If so, comment on the existing thread or leave an emoji reaction to show support.
Start a new thread: If your feedback is not listed, start a new thread with a descriptive title. Include relevant details, screenshots, and steps to reproduce the issue in expandable sections.
Be Specific: Provide as much detail as possible, including device/browser information, steps to reproduce, and expected vs. actual outcomes.
What you can expect from us
We will read all of your feedback.
We may not respond to all feedback directly.
We will create issues for repeatable bugs and assign a priority based on severity.
Known issues, feature gaps and changes in behavior
As we work towards maturing Duo Code Review for a wider release we'll track gaps and changes based on the feedback we receive as part of this internal test.
@spencer.landis Can you share more on why you think it's a downgrade? What value were you getting from knowing all of the items you were involved in, even if you didn't need to explicitly work on those?
Just a quick reference of how much open work there is. Even if one I'm assigned hasn't received feedback yet, it is helpful to know I need to bump a message about it to the rest of the team.
@phikai Yes. Not just "my own work", but in general I would not assume that the person reviewing has the same responsibility as the person integrating. Reviewing involves code/logic of an implementation/change (i.e.: developer). Integrating typically involves CI/CD pipeline executions and sometimes that may require further consideration to decide how or when to merge it exactly, or in which order if there are multiple approved MRs pending integration (i.e.: product owner).
@phikai Many times they are the same person, but not always. And MRs can have their assignee changed. The assignee is the one responsible for handling the MR and should be considered active for them until it is either merged or closed. A MR can be considered inactive for everyone if there is no assignee (i.e.: a MR, independently of whether it is ready to merge and/or approved, could have their assignee unassigned if for now it is not considered a priority anymore).
A better solution will be to let the user select what to add to the counter.
I also miss seeing at a glance how many open MR's I have and how many I need to review.
I am used to starting the morning by clicking on the counter and seeing if the number has changed. This way, I know I have a new review waiting for me.
This new layout is terrible. I just want to see all the review requests that I am the assignee on and now it is split up!
Also, the section Waiting for assignee literally isn't that. It is merge request that I have commented on that have not had a response to every comment.
Also, if you collapse sections and then refresh it doesn't save the state of what was collapsed. So you still have to open/close sections that may/may not be relevant to you.
And "Assigned to you" are requests that don't have reviewers for some reason. Sometimes I have review request with no reviewers because I want to kick off CI, they aren't requests that I want front and center, certainly not before requests that I have assigned reviewers that don't fall under the active count.
The one thing I did realize is that you effectively can get the old view back by using Search and searching for MR's that you are either the reviewer or assignee on. There just isn't a button for exactly that anymore.
Personally I really like this =)
There are work/improvements still to be done, but this is a very good start I think =)
It is also nice that only have to click once to see all MRs in one view instead of twice to either get to those Im assigned to myself, or the ones Im reviewing, that was very annoying
I agree with Matt! I don't understand the splits and this makes it harder for me to find the PR:s that I am looking for. I don't need all the extra information attached and don't understand what half of it means.
I think the main issue for me is that I want to be able to find the PR:s by name. And the name is a lot less prominent in the new design. The most prominent now is the "PR status" which is pretty useless for finding a specific PR. Id much rather have a basic list like it used to be and then have the status listed right next to it. The changes make no sense to me.
I don't need all the extra information attached and don't understand what half of it means.
@simon147 Did you look at the documentation for the new homepage? Did that help you understand more about the information on the page? Are there aspects that still aren't clear?
I think the main issue for me is that I want to be able to find the PR:s by name. And the name is a lot less prominent in the new design. The most prominent now is the "PR status" which is pretty useless for finding a specific PR.
What are you looking for when looking for a merge request by name? Is there something about the name that would tell you to take an action or are you just looking for specific ones because you know some other way that you need to take an action?
Rather than selecting to view where I am assignee, I now have to scroll down quite a ways to find my MRs past a bunch of MRs that I am marked as a reviewer or collapse the section, though this collapse doesn't persist adding extra steps every time. The ability to search or filter results is also gone with the removal of the search bar. This change offers no benefits and several obstacles to my workflow.
The ability to search or filter results is also gone with the removal of the search bar.
@AndrewBranoff The previous implementation with a fully featured filtered search is still available on the Search tab. Also, if you follow an old bookmark, there are redirects in place to take you there. Thanks for the feedback.
The usual goal of software improvements is to lower the number of clicks and steps needed to make use of it, adding an extra step, clicking to the search tab, makes it more difficult to use.
@AndrewBranoff Can you say more about why you're looking for MRs where you're the Assignee if they're not surfaced in the top sections where you'd need to take an action? Is there some other signal you're getting that tells you to take an action on those?
@phikai Much like Miguel in Spencer's comment thread, in my organization (or at least in my team at my organization, others may operate differently), the assignee and author of an MR are usually the same person, and that assignee is responsible for the MR through the rest of the process, including the rebase and final merge. This new format pushes down MRs that are ready for that next step in the process of merging in, and does so in an odd way, since I see MRs listed in the section titled "Waiting for approvals" that have all required approvals for merge hidden in with those that still need approval. (Practice here is that everyone on the team will be assigned as reviewers, but only two are needed to approve before a merge, meaning most MRs have 3 reviewers assigned that never see the MR above the 2 that do on the 6 dev team)
I don't like the new layout at all. I like the old split between Assigned and Review Requested very useful and better than the new one to organise my work.
Where are the filters for quick search of past merge requests ?
Was super useful to have it at the top of the page, instead of an other tab.
Also, I'm an assignee for one merge request I created (yes this is how we use it here) and it doesn't show up in the "Assigned to you" section. Why ?
I'm an assignee for one merge request I created (yes this is how we use it here) and it doesn't show up in the "Assigned to you" section. Why ?
@bthery_altair Does this merge request have any reviewers assigned to it? If you are an assignee and it has no reviewers it will show up in the Assigned to you, if it has a reviewer assigned then it'll be in another list depending on the review state.
The old pages showed labels put onto MRs, which was really helpful to know which MRs are high priority potentially, or anything else. They were a good way to get additional information beyond the approved/not-approved detail at a glance.
Could labels be displayed on the new page with each MR entry?
@Matthew.Rupchan In some of our design iterations and tests we did have toggles that allowed label configuration. We ultimately went away from that, but I've opened #517583 so we can continue to explore that.
Why would you do that? You claim in the new merge request popup "Know at a glance what merge requests need your attention first", yet you provide less information?, now i have to go to the search tab to actually see the useful information. Who thought that would be a good idea? Why break something that worked ok?
@phikai I cant answer for Michelle, but we use it to label different mr for different groups, and also prioritization and similar info. It helps a lot making quick decisions on which MR to look at now, and which are ok to wait a bit with. For example
Another thing I noticed now is that we have automatic systems (dependabot) that creates lots of MRs with newer versions that we need to start to use. But sometimes we cannot do it directly and add "on_hold" labels, or other "grouping labels". But when dependabot creates more MRs and it is 20+ MRs in the list, we really want to see which we have marked before so we do not have to go into each MR all the time.
At least you've done your research before making such changes to understand user's values and you know that simple > bloated. Oh wait.
Looks like another change in a series of changes completely separated from reality (to be honest, there were no usefull changes in Gitlab's UI for quite some time already).
If I'm assigned to a merge request and it's not either merged or closed, I want that MR to count as active, as it usually means that it still requires my attention in some way and I need to keep tabs on it.
On the other hand, I like that merge requests that I am reviewer in and have already approved are now no longer included in the active count. (I assume that if new changes are pushed and my approval is reset, that merge request will again revert to counting as active?)
as it usually means that it still requires my attention in some way and I need to keep tabs on it.
@pekka.korhonen Can you elaborate on what kinds of things would require your attention on those MRs? If they're awaiting a review, for example, when the review is finished it will return to you and then be part of your active count since it's ready for you to take action.
@phikai Reviewers might leave comments, questions and/or suggestions before adding their approval. Also, even when there has been no action at all from the reviewers, I will sometimes need to remind them to take a moment for code review - they might simply be busy with other tasks and forget otherwise.
Until now it has been convenient to go through the list of MRs assigned to me every once in a while to address any discussions and code changes, but also if there has been no action from the reviewers to remind them that I want to move this feature along and they need to take a look at it before I am able to merge it.
Can you elaborate on what kinds of things would require your attention on those MRs?
An example is "go chase the reviewers to actually review it". I'm not sure it would be an acceptable answer when asked why my feature still isn't merged a month later to be "well, gitlab didn't say I had any actions to make on it so I kind of forgot about it"
I'm not against this change, not that much, but I think this was tailored a bit too much for how the GitLab's team uses MRs and didn't really think about how others are using them (understandable since the initial test was internal and it's only now available for public, self-hosted aside).
For example, in our company, we don't have many engineers and some projects only have one engineer (or two) working on it. So, we often use MRs to "logically separate/separate the context of" the changes to keep track of what was done more easily instead of doing review rounds and such.
With this new MRs dashboard, it's harder for me to have a quick look at the MRs that I am assigned to and the ones I have to review because they're usually hidden in places that I don't really expect them to be, because we didn't use the "GitLab's intended way" of using MRs, e.g.:
Open the MR
Assign a reviewer
Wait for the review
Remember to use Start review instead of leaving comments
Remember not to remove yourself as the reviewer once the review is done
Iterate
This enforcing of the "GitLab's intended" way of using MRs is taking away the flexibility we used to have.
What this boils down to, is that I can see the usefulness of this new dashboard, for big teams like GitLab can definitely be seen as an improvement, but for other teams this is more of a step back.
My suggestion would be (100% up to you to decide @phikai, just my idea of how I would approach this):
Keep this as a default for a bit more time to gather more feedback from other teams/users
Disable or default to the "old" page while working on improving the new dashboard (if feasible)
Reiterate
Once ready, keep both "systems" (the old dashboard and the new one) but let each user decide which one they want to default to
I know it might be seen as a "code-duplication"/"two systems to maintain", but the simplicity and flexibility of the old system has its value so I would definitely not decide to use one or the other. Instead, keep them both because they are both useful in their own way, just change the default page shown on the MR dashboard (and the behavior of the MR button on the sidebar)
@zillemarco The "old system" is effectively still there with the search tab. It's one of the reasons we left it in place and we don't currently have any plans to eliminate it from that location.
In the old system I could get to the MRs that were assigned to me much faster: a single page load after selecting "Assigned to me" from the lef-nav button.
In the new system I have to go to the MR dashboard, wait for the page to load and finish repositioning things, and then select "Search" which is a harder target to hit (Fitt's law, plus being in a somewhat unpredictable location) and then wait for a second page load.
If assignee has the meaning that you seems to be shared here (assignee: (noun) the person/entity responsible for corrections to the MR and/or ultimately merging, but not necessarily the creator) GitLab NEEDS auto-population of this field (which I'm guessing you agree with based on your comment here). Until that is implemented or you start showing stuff you've authored, this feature is entirely useless to me. (I've actually found it's wasted my time since I end up unconsciously opening the tab when I really wanted the information from my bookmark. I had forgotten it existed until the UI decided to draw my attention back to it.)
And, even if someone uses the assignees field, why is the assumption here that they don't care about the reviews that you've authored? Are people predominantly just mic dropping reviews all over the place at other organizations?
The default MR search has a search filter for author.
@jmholl Would it be fair to say the old pages that referenced assigned MRs also weren't valuable to you? As in you weren't using the old default pages either?
And, even if someone uses the assignees field, why is the assumption here that they don't care about the reviews that you've authored? Are people predominantly just mic dropping reviews all over the place at other organizations?
Can you say more about this? I'm not sure I understand this statement don't care about the reviews that you've authored.
@jmholl Would it be fair to say the old pages that referenced assigned MRs also weren't valuable to you? As in you weren't using the old default pages either?
Correct.
But this is still a big deal to me because there is nowhere on the platform I can see merge requests I've authored and merge requests I need to review as the MR search does not allow for OR constructs.
To workaround this limitation, I have two separate ways to track these two MR related pieces of information, I have a bookmark for the MRs I've authored and an email filter to discover I've been made a reviewer. You might ask, why are they two separate styles? Well, my MRs are something I am aware of and so I want to interact with them on primarily a pull basis, but other people making me a reviewer I am not aware of and prefer the push style of email. BUT, if every time I pulled by looking at my MRs I also implicitly push my review MRs to me AND I get to see regular changes to the MRs I review, which I don't with emails. And that would be much better since GitLab emails are not fun to manage.
Sharing here, I'm hoping GitLab is interested in perhaps broadening the scope on this to actually achieve an improved merge request homepage for more of the platform. I'd hate to see it evolve into a piece of the platform I still can't use but want to.
Can you say more about this? I'm not sure I understand this statement don't care about the reviews that you've authored.
The title of the menu entry is Merge Requests. The merge requests I've authored don't show up there. This seems to be desired behavior by GitLab implying there are a bunch of people who don't care about Merge Requests they've authored and as soon as someone else is assigned (or removed (which could be in error!)), they'll never look at it again (maybe an email will catch the parenthetical error if the user is paying attention to that stream).
So, effectively, the author of a merge request is really just an internal piece of information to GitLab; no high-level functionality keys off of it. And so, if that's going to be the case, the things it does key off of NEED to be auto-populated (preferably in a configurable fashion since I feel like this push-back in this conversation means there are organizations that don't find this desirable).
To leverage the Assignees field and this page, nearly every MR I open through the web interface I would have to manually add myself as an Assignee using the MR interface. While it is one click, but we're talking more that 99% of the time this is the behavior I want. I'd also like to point out, that that button (which is actually a link even though it does button things) is drowned out by the surrounding UI elements.
And this style of change ownership has been the case at every company I've worked at, for every person and every team I've worked on and with at them. Not owning the reviews you've authored extremely against the norm.
I'd be very interested on statistics on this because GitLab's behavior has (as you might have guessed) baffled me forever. Across your customers, what percentage of them that use the assignee field regularly, more often than not don't have that match the author? Are most of them using push options to auto-assign their assignees (maybe with wrappers or git hooks)?
The title of the menu entry is Merge Requests. The merge requests I've authored don't show up there. This seems to be desired behavior by GitLab implying there are a bunch of people who don't care about Merge Requests they've authored and as soon as someone else is assigned (or removed (which could be in error!)), they'll never look at it again (maybe an email will catch the parenthetical error if the user is paying attention to that stream).
@jmholl That's an interesting hypothesis, but I'm wouldn't say that reflects the reality. What we (GitLab the company) and most organizations do is use the Assignee field. Generally, that matches the author of a particular merge request, but not always.
So, effectively, the author of a merge request is really just an internal piece of information to GitLab; no high-level functionality keys off of it. And so, if that's going to be the case, the things it does key off of NEED to be auto-populated (preferably in a configurable fashion since I feel like this push-back in this conversation means there are organizations that don't find this desirable).
I'd say yes and no, there's some value in these being different - perhaps multiple people are actually working on a change or a teammate leaves and someone else picks up the work. There are valid reasons for these to end up different which is why it's not a default behavior. Although it is something we've considered and continue to evaluate.
To leverage the Assignees field and this page, nearly every MR I open through the web interface I would have to manually add myself as an Assignee using the MR interface.
I know many organizations automate this with /assign me in the bottom of the merge request template so this makes it functionally automatic for all merge requests.
Not owning the reviews you've authored extremely against the norm.
When you say reviews here, I think you're referring to changes or merge requests. As compared with when you review a merge request, my understanding of your workflow, is that you are setting yourself as a reviewer.
@jmholl That's an interesting hypothesis, but I'm wouldn't say that reflects the reality. What we (GitLab the company) and most organizations do is use the Assignee field. Generally, that matches the author of a particular merge request, but not always.
Yea, I'd love to use it, too, but it's onerous, which is a large part of the point I was making.
I'd say yes and no, there's some value in these being different - perhaps multiple people are actually working on a change or a teammate leaves and someone else picks up the work. There are valid reasons for these to end up different which is why it's not a default behavior. Although it is something we've considered and continue to evaluate.
That was not my point. My point was that the happy path, the well trod path, has the author be the owner. I didn't say this feature doesn't have use. In fact, I indicated that I have needed similar functionality in the past (e.g., "While it is one click, but we're talking more that [than] 99% of the time this is the behavior I want.", "Not owning the reviews you've authored [is] extremely against the norm." (corrections (my grammar was terrible) and emphasis are added now and not from the original)).
My point is this should be a default if GitLab is not going to leverage my authorship status. Especially, if this is the most traveled bath by far as I have hypothesized based off of my prior experience.
I know many organizations automate this with /assign me in the bottom of the merge request template so this makes it functionally automatic for all merge requests.
That flow there is definitely helpful, but sadly that also means I lose the default MR template and GitLab's custom template do not expose functionality to duplicate it and I don't want to replace manually assigning myself to merge requests to having to manually removing the duplicated merge request title in my descriptions (i.e., %{first_multiline_commit}).
And this further gets back to my previous question of what is the cross-section of organizations using this and automating this? Does it turn out implementing some automation on your own (to be verbose, the merge template fits into this category) is largely necessary for this feature to be useful? It'd be nice to hear that GitLab has done this analysis and that my hypothesis is wrong instead of dealing in further hypotheticals and anecdotes.
When you say reviews here, I think you're referring to changes or merge requests.
Correct. I was referring to reviews as "code reviews" or in GitLab's parlance, merge requests. Sorry for the confusion. Since I was talking about my use of other platforms in addition to GitLab I wanted to use a more generic term because other platforms don't call them merge requests.
As compared with when you review a merge request, my understanding of your workflow, is that you are setting yourself as a reviewer.
Oh, one more thing. I would honestly remove the top/outer Merged tab and keep only Active and Search.
The merged tab is not that useful, and we have the (almost) same view inside of the Search tab so it feels like a duplicate.
Also, with the idea of keeping both systems and removing the outer Merged tab, I would probably rename Active to Dashboard and keep Search as is. Dashboard feels more like what that tab actually is, a "tailored" experience, while Search gives you the freedom to do what you want.
Bonus point: having only two tabs the user setting would be something simple like this:
I already miss the "Closed" tab for merge requests.
How can I now find that one specific thing that I remember was merged 6 months ago? Should I move away from GitLab and simply check my git log, seems like an odd solution right?
@andlrc@tomas.backman Are you often looking for closed merge requests? Can you share any details about what you're looking for in those and what's important about them?
Not very often but from time to time yes. Both for the reasons Richard mentioned. But also sometimes when finding an older change in a local repo, and I wonder if we finished it, then it is nice to browse in the Merged list as well.
@MaksFedorko The merged tab gives you the last two weeks of merged work that you were either the Assignee or Reviewer of. It's not meant to be a comprehensive listing of all merged work, but more of "recently" merged.
This can be an issue. Multiple times over the past year someone has been faced with a problem that was already solved, and the best way I find to guide them is to show them the solution by giving them the MR I know I did say a month ago. While I understand the old functionality is still there under the search button, adding effort and clicks to get what used to be convenient is an issue.
It's not meant to be a comprehensive listing of all merged work, but more of "recently" merged.
It was like that before and it was convenient. Now you have to keep a mental note of when the MR was merged and either look here or search and filter MRs yourself
I have MRs that are done using a script, so they are done one after another, I now need to extra click to go to Search where the old view is, otherwise I have to scroll up and down trying to find them.
@tomasz.wesolowski What do you mean you need to scroll up and down to find them? When you create the MRs via a script are they also being assigned for review and so they're waiting for others? Any additional details you can share about this workflow?
I miss having the instant split of my MRs and MRs for me to review on the button in the top left, but I could definitely make use of this page (and would probably grow to prefer it) if it saved which sections I keep collapsed/expanded
@jake.featherstone What would your expectations be if a section was collapsed by you, and then when you visited the page again it was still collapsed but the contents of the list had changed?
Personally, I'm not that interested in the requests that aren't included in the active count.
The fact that you're not including them in the count indicates that they're of lesser importance. These are the ones that I'm currently collapsing to prevent the page from becoming a bit overwhelming, and I'm not too bothered if the contents of those lists changes.
I do think it it could just be a case of needing to get used to where each section is, what it contains and when it'd be helpful to check it
I think the new MR overview has potential, but I would like to keep review and assigned MR's separated like before. This could be done by simply splitting the overview in two.
Previously we have used draft a lot, and it would be nice to have filters in the different sections to focus on MRs with specific statuses.
Create MR, assign to first reviewer, reviewer approves but does not assign 2nd reviewer. The MR is no longer visible in the default view and unless I remember that I had such an mr, it stays in the limbo.
Desired behaviour - once the assigned reviewers have approved the MR, the MR should show in an actionable MRs list.
FYI @mle@iamphill - there's some other similar feedback about authors who also merge their own work, so maybe we could consider all those cases as part of returned to you?
The Waiting for approvals section has merge requests in there that have all required approvals to merge, but has two reviewers of which one has given the mentioned approval.
I expect the merge request to appear in Approved by others if it has all required approvals.
Another thing is that we usually just write "threads/comments" instead of full reviews on MRs. It is more flexible and still stops MRs from being merged until comments are adressed which is the important point.
But these do not show up under: Returned to you headline. Which 'i think they should. (I assume now there are only those with "proper reviews" that go there)
This view feel very good to have (I have been missing similar!)
But without adding "just comments" there it is not nearly as useful as I would like.
I just opened my MR page and was pleasantly surprised! I will need to get used to by using it for longer than 5 minutes, but here are some initial thoughts.
I usually go to shift r to see if I have reviews left to do; And then I go to shift m to see my MRs and if I need to do something. So having them in one view is really nice to see. The order though, I get that reviewing has a little more priority, That's also why I open my review MRs first. but in a view like this, it feels odd. I think having the reverse:
Assigned to you
Review requested
Returned to you
would feel more natural to me. So perhaps it would be nice to be able to reorder these sections to your liking.
Another thing I immediately thought of was this view on project or group level. We currently try to filter the list based on draft status, assignees, reviewers. but every day, it's the same question "what are the filters?". I know history searches and bookmarks exist, but no one seems to want to use them. So having these predefined sections would be a nice thing to have to get that immediate overview to get updated and divide MRs to review.
I've been using it for more than 5 minutes now . Still happy with this dashboard. In fact, instead of going to my MR list every time, I just keep this tab open because I find it so useful.
Here is some feedback:
Unfortunately, I couldn't use the Returned to you section, because no one that reviewed my MRs used the review functionality. So having "normal" threads count towards this too, would be great. I read there is an issue about it already somewhere.
Every morning, we divide all the MRs that are ready to be reviewed. Then seeing them in Review requested is a nice section to have this sort of todo list.
The Assigned to you section is nice. However, in my flow, when I remove the draft status, I'm done with it and it's off my plate. I've seen some people refer to that first three sections as "work to do" or things that need my attention. So when the status is Reviewers needed, it's not really for me anymore and can be placed in the lower "idle" section. Maybe a new section Waiting for reviewer or something.
I haven't found a use for Waiting for assignee personally. We always assign someone. My eyes are drawn to the open sections, so it doesn't really bother me to have this "useless" section. It's probably useful for others. Apart from the reorder in my original feedback, maybe a section toggle? To show/hide them.
The info does say "Your assigned merge requests that are waiting for approvals, and reviews you have requested changes for.". Does this mean, I'm a reviewer and I requested changes? If so, that description is pretty confusing to me. And the section would be more like "Waiting for feedback to be resolved". I'm curious what this section is supposed to do. EDIT: I read the docs, and it's when you are in a review or when you requested changes. I think the section title could reflect this better.
Waiting for approvals is a nice section in case a review takes long and you can bump people so they don't forget. Something I did find a bit odd is the next scenario that happened:
My MR had two reviewers. Our rule is that one approval is enough for the merge. My MR was approved by one person.. (These are from one row). You can also see the approve Icon is a little hidden behind the second person. but no big deal. I see it and on hover it rises to the top. Anyway, I had the required approvals, so I kinda expected this row to appear in the Approved by others. But it wasn't. I guess that section is really "Approved by all others/reviewers" (Same row). (also, I kinda expected the approvals to say 2/1 since I have two of the one required approvals. I guess I also have one of the one requested approvals. This is more a side note haha.
I also didn't find a use for Approved by you. Simply because we only need one reviewer and I immediately merge after approving. But that will probably change soon. So then this section might become more useful.
Same for Approved by others, they also usually immediately merge. So, nothing really gets in this section.
This table view is nice, but to fit the labels, you could also consider using the rows we are used to in the normal MR & issue lists. Title and labels on the left. Assignees, reviewers, extra info on the right.
TL;DR
This new layout is just overly bloated and confusing.
On top left Merge Request count I have 2. I think (I actually don't know so unintuitive is this layout) this is because the Review requested count is 2 as well. However, these are actually Draft, so I don't care. Under waiting for assignee I have my 1 MR which is not draft, thats the actual only one I'm interested.
My own MR is not under Assigned to you but under Approved by others ?? This does not make any sense ... If this section is just a subset of my MRs (with no reviewers yet) then don't give it a name that let one assume a list of all their MRs.
Edit: I found the grey on grey text Items below are excluded from the active count so at least this makes sense now
If you really want to keep that layout pls just add a button to switch to the old layout
@phikai potentially to discuss it or to have it at least on the agenda that something requires a review soon. Sometimes people do like a pre-review (if its a MR with higher uncertainty - e.g. research related).
... how do you know when it's ready to be reviewed?
This is meant to be controlled through merge_request_dashboard. We have not enabled it.
Gitlab states it'll be Enabled by default from version 17.9. We're not there, and it's already force enabled. This sucks and doesn't conform to the docs and release notes :(
This is an administrative feature flag. There is no possibility for users to choose what they want to view.
Preferences are personal, and force-enabling it globally before the official version release is kind of a shit action.
Now, all users are stuck with the new interface on a deal-with-it basis. This is an example of poor UX. :(
33 dislikes, 4 likes. Could you please understand that the feature is disliked by 90% of your customers and disable it? Or at least, not force enable it globally?
I really would like to have the ability to quickly see all Merge Requests created by me that are currently open.
Right now its scattered around, somehow some of my MRs are considered excluded from the active count despite me actively working and committing on them yesterday, they are ranked lower in the list than some old draft: I commented on in 2023 that was not closed by its assignee.
In general I like the idea of a task-oriented personal dashboard like this.
Like many others, I do need labels, and yes I am following #517583.
It would be nice to be able to sort these sections. By that I mean that if I were to want "Review requested" and "Returned to you" swapped vertically, I should be able to do so.
The verbiage of "Items below are excluded from the active count" needs work. There must be a way to indicate visually which items are "counted" without needing that grey box in my way.
Why are MRs that I am the author of now so hard to find?
On our team we don't use the arrow thing next to "Reviewer". Instead we set the reviewer to whoever will review the MR, and then we assign it to them when it is time for them to look. They assign it back once they have comments.
We've been ping-ponging the assignee since before the Reviewer field even existed. It worked really well until this recent update:
Author = the person who made the change
Reviewer = the people who will review the change
Assignee = the people who currently need to do something with the change (eg: review or respond to comments)
We even have a Slack automation that relies on this workflow, and DMs you notifications whenever an MR gets assigned to you.
This new UI doesn't work with that workflow. When I assign an MR to the reviewer, it completely disappears from my view. I don't want that. I want to be able to easily check on MRs I wrote. ie: "Author = me"
Adding to this: if I assign my MR to someone else and set the reviewer, it does not appear in the "review requested" section for me. It just completely disappears.
@xenomachina Generally speaking, the way GitLab's merge request review flow works best is that typically the Author is the Assignee and the Reviewer is anyone who will review the work. You can just set those people initially and never need to change them for the lifecycle of the merge request.
When you do this, the first time you set someone as a reviewer (request a review ) they get a To-Do and email notification that tells them they've been asked to review.
You can also re-request a review from that user if you've made changes to a merge request and need them to take a look again.
Taking a look at the homepage overview and some of our review feature docs may help streamline your workflow around these features.
Thanks @phikai. The diagram on the homepage overview page fits the model we're using, but we'd been using the assignee to send it back and forth instead of using "changes requested" and "request re-review".
We would like to switch to the documented way of doing things, but from some testing it looks like there is a bug in the way parts of this flow are implemented that would make this a significant downgrade for our team.
Normally, every merge request change causes a "Merge Request Hook" webhook event to be fired. For example, when setting the "Assignee" or "Reviewer" fields, or if the MR is approved, there is an event. However no merge request event is fired when "changes are requested" or "request re-review" is clicked.
We have an automation set up that will notify us via Slack DMs when an MR's assignee changes. This works great when ping-ponging the assignee, as the reviewer/author immediately get notified when there's something that needs their attention.
Unfortunately, given that "Merge Request Hook" events are not fired by "changes are requested" or "request re-review" being clicked, we can't set up notifications for them.
I don't think our team can switch to the "request re-review" flow until the bugs with missing merge request hook events are resolved. To do so would be a significant downgrade to the process our team has been using for several years.
Given the fact that it seems very unlikely that they will be resolved any time soon (the bug about no events for re-request review is already almost 1.5 years old, with no milestone set), can you please at least include all merge requests that the user is the author of on their merge requests dashboard? Then we only have to get used to an unfamiliar UI, rather than one that's actively excluding information we need.
I also agree with the sentiment I've seen from other comments, that the way it currently determines what is "active" does not seem accurate. Any merge request (that is not merged or closed) is "active" for me if it is assigned to me — regardless of who the reviewer or author is, and regardless of whether it is approved or not. "Assigned to me" == "active for me".
@xenomachina No plans to introduce author around this currently. It's something we've considered (in a way) around combining what author and assignee means as part of #365969, but haven't proceeded with at this time.
@phikai That issue seems to be talking about changing the data model of merge requests themselves, which is much more complicated than what I'm suggesting.
I'm talking about something much simpler: when the merge requests dashboard selects which MRs to display, it looks like it currently selects only those MRs that have the user as one of the assignees. Instead, it should also select MRs that have the user as the author.
For users that use this process, there won't be any change in behavior, as they already have the author in the assignee list anyway.
For users that don't assume author=assignee, the new UI will become usable, as it will stop filtering out merge requests we care about.
@xenomachina For your use case where you're placing people in the Assignee field, wouldn't this create more MRs in all these categories since the queries would be where author OR assignee? That feels a bit like a net-negative, but curious to keep exploring.
I've opened #520163, to loosely frame that out and asked (internally) to pull some data.
UI is unintuitive and overwhelming. The MR's respective labels are missing. It feels like a "Advanced Merge Request Page" that no one really wanted. I think a redesign is needed but this version is not the one that delivers. Requires some re-thinking for sure.
The text above should be like a sub-header imo. As I said before, its overwhelming and unintuitive. People may miss it and not understand what's going on.
Fantastic UI I love being able to see both things I'm a reviewer and an assignee on from the same screen. But I would like it to be a bit more obvious which requests I'm assigned to. Potentially instead of laying out all the screens vertically, it could have a horizontal/tab/some other separation of "I'm reviewing" and "I'm writing the code"?
Also, now that I figured out the top things are "you need to do something", I like it more, but it could be more obvious. I also requested changes of a colleague today and it's in "waiting for assignee" which is wrong, it has an assignee and two reviewers, it just needs updated.
Can we bring back the view in "Your Merge requests"?
My team's workflow involves reviewing MRs after they have been merged. The new UI makes it very difficult to track which ones have been reviewed at the moment. We cannot see the approval status or the emoji as we could before.
I generally like the new design, but shouldn't the "Reviewed by Others" subsection go back to the top of the page as it's something for me to action (ie proceed with the merge)?
I can see some use to breaking things up. But, all I really want to see, at the top of the page, is a list of merge requests I'm reviewing and a list of the merge requests I'm authoring.
This view is so strongly coupled to the gitlab model of MR statuses, that I don't see myself using it any time soon. Our MR flow is different, so we use labels to indicate MR status. The "requested changes" setting + clearing doesn't work for us.
FWIW, because I see you ask for this feedback frequently, here's what we use:
"NEEDS REVIEW" --> Says to the reviewer "I've actioned or replied to all your comments. Please take another look"
An MR can be both DRAFT and NEEDS REVIEW if there are some parts that the assignee wants reviewed but hasn't finished everything
"NEEDS CHANGES" --> Says to the assignee that there are open points to address
"NEEDS QA"
"DISCUSSION" --> Unclear if this will even move forward. Hold off on detailed review for now
All of these MRs are/should be DRAFT, but not all DRAFT MRs are "DISCUSSION"
Because of this difference in workflow, gitlab's assumptions about which MRs are active/inactive don't match what I think of as active/inactive, and the various boxes are pure noise.
I think about MRs that I need to review and MRs that I am assigned as very distinct categories, with very different actions, information needs, etc. E.g., for MRs I'm assigned to, if it takes a few days to turn changes it's usually ok. Whereas for MRs I'm reviewing, I really want to give feedback quickly so I can unblock the assignee. I liked the previous UX because that reviewer/assignee distinction was top-level, unlike this UX that requires viewing each entry specifically to determine my role.
For me, there are two points of UX degradation:
The "MRs I'm reviewing" search requires manually typing out the filter and is quite a pain to set up. It would be awesome to add a button to open this with one click, like the way "MRs I'm assigned to" is now
The number badge on the top right is now completely meaningless. Not sure what the fix is
Sorry, I do not have time to read through all of the feedback, however, I also dislike this new view. The biggest thing for me is I now have no idea who is asking for the review. The old view has the title for the Merge request and directly below it there is text that says who the requestor is. Now all that is there is user's icon. I do not want to memorize icons, I just want to be able to quickly read who posted the MR.
For me theres two main improvements that can be done.
There should be a clear section near the top for only MR's that are approved and can be merged when your the assignee.
The approved status on the left should be green, not grey like all the others. It makes it hard to see ready MRs. Could be resolved by having its own section.
@diney1@rtingle For the looking at pipelines usecase - are those MRs often assigned to reviewers while you're waiting to see if pipelines are passing?
For comments, those would come back to you as Returned to you after the other folks complete their review. You shouldn't need to look for those until they've been returned.
For merging approved MRs - I've opened #518710 to potentially introduce some way to signify ready to merge items.
It depends. Initially I'd have my MRs in draft with no reviewers. I might do this way before I want to merge to get easy access to pipelines to deploy to developer environments etc. Later I'll have reviewers of course.
I think all of this feels a bit excessive, I'll probably have at most 3 MRs assigned to me at any one time and I just want to see them. Status symbols on the MRs would probably be better than totally separate lists.
MRs I'm reviewing might be more numerous and there separate lists makes more sense
@phikaimy own would be merge requests I created. For example when someone commented but did not click Request changes, or when everything is fine but you didn't use auto-merge. I can't seem to find these MRs in the new UI.
Page jumps about during load (due to sections async loading in).
My main use of the old MRs page was to find my MRs. Now if I go to the new page I scroll to that section, then something else (that I don't care about) loads above it requiring me to rescroll to the new location where my MRs are listed (or some of them, it seems to split up my MRs into different sections).
I like the page, it's clear and is a Todo-style dashboard for me.
For some projects, we do not use the Assignee features, because it's always the Author of the Merge Request. So an option to also have "Your merge requests", based on Author instead of Assignee, would be nice.
Or is there some feature to always set the Assignee by default to the author of the MR?
@phikai I use quick actions to assign reviewers/approve/submit reviews. I'm pretty sure I changed reviewers (to myself), unassigned another reviewer, approved and assigned a maintainer in the same comment
@terrichu AFAIK, quick actions are executed in the order they're in the comment. So if you did...
/approve/reassign_reviewers @terrichu
Then you wouldn't have been a reviewer when you approved and you would have then effectively requested a review from yourself.
I know we've done some work to save state if you remove and add yourself, but in this case it looks like we executed the state in the order we were given things... @iamphill thoughts?
I like that once I have approved an MR it is removed from my list. This is an improvement over the old behaviour (where it just hung around in my list till someone merged it)
I think, a "Ready to merge" category at the top is really needed, but I see that this already planned (#518710), good!
Alternative approach
I'd like to suggest an alternative idea for the page: A kanban-board of all merge requests the user is part of.
graph LR; WIP["Draft / WIP<br/><sub>Work in progress (not ready for review)</sub>"] --> Open["Open<br/><sub>Waiting for assignee(s)</sub>"]; Open --> Editing["Editing<br/><sub>Assigned</sub>"]; Editing --> Review["Review<br/><sub>Waiting for all approvals</sub>"]; Review -->|Changes requested| Editing; Review --> Ready["Ready to merge<br/><sub>All approvals given & pipelines successful</sub>"];
On that board, add an option to filter out MRs where it’s not the users turn to act (and make that the default). That way, you can track all work where you are involved but you can also focus on MRs that require your action.
Just a simplified idea, but I wanted to share my thought process on how I see most MR workflows and why the new MR homepage might miss the mark.
It would be nice if there was an Authored by you section, personally I don't really find it useful assign things to myself as it feels like the same thing, so would be nice if I could swap that section out or at least have authored as well as assigned.
Currently the only way to see those is to go into the search and manually find them which is a bit of a pain so I have to have save a bookmark with the search query.
We use the reviewer, and then re-request reviews when comments have been address.
I think that some people on my team put themselves as the assignee but I don't as that always used to make them count in the number of Merge Requests in the sidebar, and I just wanted that to reflect the number of MRs that I had to look as as opposed to every MR that I'm involved with. As such the assigned and author fields essentially equate to the same thing for me, so I ignored the former.
@phikai 100% and then if my authored MRs could be included in the new MR homepage I would be a happy bunny.
The only thing about that I'm not sure about is this:
Authors should be automatically populated by users who author or commit changes to the merge request.
For example if I make a suggestion on an MR and then accepts it that would then mean that I'm now an author on it and so that would get included in my MR list which would be a little confusing and muddy the waters a little as I would still want to be just be considered a reviewer.
The new MR view is causing me trouble. Before I was able to get to my list of assigned MRs quickly. Now I get this larger list and the assigned section is empty. Also, the branch information is missing, so I can't tell at a glance what branch the MR belongs too.
If I go to the "Merge Requests" -> Open and then filter on ones assigned to me. I can get an assigned list with has the branch info, but it's more work.
New MR view doesn't show the labels of MR. Also, there's no search/filter options. I would like to filter MRs which are in draft and see only active ones.
@nagendra6 Can you say more about what before verification means? Are you also saying that a merge request isn't initially draft, but is then put into a draft state after the work is done?
If it is a work in progress MR, then starts with draft and once complete, we remove draft and send it to review.
If it is a completed work, but blocked due to release or other reasons, then it goes back to draft, and will remain in that state until further update.
If it is for other purposes (POC etc), then it will be in draft indefinitely until we don't need it and close the branch.
@iamphill Can you open an issue to see if we can further improve the performance of these queries? Maybe we can loop in someone from the database team to help out?
Please just admit you goofed by releasing this universally, clearly without getting enough feedback ahead of time, and give us our beloved layout back! There was close to zero mental effort involved in understanding at a glance how many MRs I was assigned and/or marked as a reviewer on, which category they fell into, and their age. It was intuitive. Now I need to click, scroll, expand, collapse, and think about what's going on on the page. It's frustrating and clearly a large portion of your users vehemently hate it. Do the right thing and revert. I really don't enjoy being so harsh, especially online, and I am grateful to your product team for their best intentions, but this truly sucks.
If you want to offer this new page as opt-in so you can make it just as intuitive in parallel, go for it, but you're as of now a long ways away.
I mostly agree with this. Maybe the old one except once you approve an MR it gets taken out of your list of MRs with you as a reviewer. That is the only bit I like in the new UI
Even that I find questionable. On my team at least, it's useful information to see that an MR you approved hasn't yet been merged. Maybe a checkbox on the page or a profile setting could control this though. I see your point that for some, once you approve, having it off your actionable page is valuable.
Is there any way to just switch this back? Even with as few as 2 open merge requests, it is incredibly painful to find the right one. I want to see the titles of the merge requests. Grouping by "status" makes no sense to me.
This new UI for the MR homepage has been messed up. I'm no longer seeing tags assigned to the PR since we usually use MR tags to define what type/status of MR like: Pending/Blocked/In progress/Passed. Please bring us back the old school UI.
Please make sure that assigned merge requests are shown in the assigned view and not skipped over if I am a reviewer as well. For (complicated) reasons I am on a reviewer on lots of PRs, but when I am interested I assign myself so that I have a much smaller set of reviews to do.
This used to work fine with the separate views, so this is a regression.
I had an MR fall through the cracks for me and therefore missed the milestone. It's approved, but apparently the pipeline failed. But it appears in the "Approved by others" section way at the bottom.
Problem is that it is completely out of my view normally. I had assumed it had merged, so I wasn't looking for it. Everything else I'm involved in is listed at the top.
I think at the very least it should have been listed in the "Assigned to you" section. Definitely should be "above the fold".
And because it hasn't been merged, I consider it "as active" and part of my work, and should be counted in the active count. It ain't done and off my plate until it's merged.