Dashboard performance

mentioned in issue gitlab-foss#24669 (closed)

@yorickpeterse I've left this and the linked issues without milestones, as I figure https://gitlab.com/gitlab-org/gitlab-ce/issues/25503 is probably the more important of them. Please correct any errors here or in those descriptions.

changed milestone to %8.17 in gitlab-foss

mentioned in issue gitlab-foss#27496 (moved)

@smcgivern @DouweM Can we have somebody work on these dashboard issues, if this isn't already the case? It's starting to get really annoying. For example, loading my current MR dashboard (showing a whopping 4 MRs) can easily take 30 seconds or more.

@yorickpeterse I think @jarka has started on gitlab-foss#25503 (closed)!

changed milestone to %9.0 in gitlab-foss

changed milestone to %9.1 in gitlab-foss

https://gitlab.com/gitlab-org/gitlab-ce/snippets/1654799 is the SQL generated when I do IssuesFinder.new(User.find_by_username('smcgivern'), label_name: 'bug').execute.to_sql. That's insane.

mentioned in issue gitlab-foss#29359 (moved)

@smcgivern : Are you aware of the use cases of these?

Do you know if there's a good reason to see issues from multiple projects together in one list?

The dashboard in general seems to be a global view into the entire GitLab instance, of which the view is limited to what you have permissions to look at. Can we start reducing that global view to use cases that people actually need. It doesn't seem like a person needs all these global views at all. I could be wrong. Let me know.

The default view when you navigate to issues and merge requests now filters on yourself as an assignee. That seems like one very good and valid use case. See everything I need to work on. Other use cases in GitLab should mostly be team-driven (group views) or work-driven (project views).

So Option 2 fits very well with that scenario of viewing what I have to work on. So I think it makes sense (again, with my limited understanding of the use cases), and the UX to make this happen would serve that use case. (So "tricky UX" not really a con at all.)

Another alternative that takes even more functionality away from this page is that the search gives you dynamic issue search links to projects. I.e. when you use the dropdowns to search for issues, it gives you a list of project links. A link appears as a result only if there is at least one issue in that project that matches the filter/search. When you click on a link, it navigates you to that issues page of that project, with the associated pre-filters applied. Not sure if this design would actually help performance though.

@victorwu:

Do you know if there's a good reason to see issues from multiple projects together in one list?

Yes, plenty. There are groups, but it's also been requested to allow filtering by multiple projects within a group, or multiple groups within the dashboard.

Bear in mind that I am assuming - perhaps wrongly - that a global search across all projects is more useful for people on much smaller instances than GitLab.com. Maybe they don't use it much at all either.

So Option 2 fits very well with that scenario of viewing what I have to work on. So I think it makes sense (again, with my limited understanding of the use cases), and the UX to make this happen would serve that use case. (So "tricky UX" not really a con at all.)

Based on the above, we could say that we only allow it when filtering by author, assignee, or group(s)? I can see a case for using the dashboard to look at issues for gitlab-com and gitlab-org on GitLab.com itself, for instance.

A link appears as a result only if there is at least one issue in that project that matches the filter/search. When you click on a link, it navigates you to that issues page of that project, with the associated pre-filters applied. Not sure if this design would actually help performance though.

Yeah, I think the sheer amount of projects you can see is a problem here Checking all of those for issues won't be much faster than just showing the issues in general.

@smcgivern : Thanks for more context. So looks like Option 2 is the smallest iterative step we can take? Given the horrible performance, I think we can just shoot for Option 2, and call it a day for this first iteration. Get feedback and iterate.

For Option 2, perhaps just some simple FE wizardary would work to maintain those requirements right? So truly our first iteration is just a small tweak on the FE, and we should get some huge gains in performance. And we will hear soon if there are any major complaints. What do you think about that plan?

@victorwu maybe, yes. I'd like some more input here, though. We might also need some user research, maybe?

@jarka @adamniedzielski what do you think of my proposal for the dashboard?

I agree that we need some user research here. GitLab.com is different than smaller instances. Also, no matter what we decide we will break somebody's workflow.

From my own perspective:

I think that we can define dashboard as: show issues / merge request that are either authored by me or assigned to me. So it's like option 2., but I would remove "Author" dropdown and remove "Assignee" dropdown and by default display the union of "authored by me" and "assigned to me". The remaining two filters would be "Milestone" and "Labels". This simplifies the user experience. Please note that I'm not aware how difficult it is to display the union of these two scopes (and keep pagination working and so on).

I understand that it's quite a radical proposal, though.

@adamniedzielski that's too radical for me! We can break other people's workflows, but not mine I use this to find issues other people have authored or assigned all the time.

added ~902455 label

@tauriedavis @sarahod : We need some help understanding how people are using dashboards. In summary, the driving reason is that that set of screens is extremely non-performant. So we are proposing we reduce functionality. It doesn't seem like it is feasible at least in the short to medium term to maintain all that functionality and still improve performance. So we need some pointers on which direction to take. We are considering limiting those searches/filters to be only allowed to be used when you have selected an author/assignee. Could you help us out? The comment thread above should explain everything. Ping me if something doesn't make sense. Thanks!

@smcgivern : From feedback here, the issues and merge requests dashboard seems to be a common use case for people. https://gitlab.com/gitlab-org/gitlab-ce/issues/29835

A number of comments regarding the previous sidebar accessing issues and merge requests with one click. https://news.ycombinator.com/item?id=13931969

@victorwu yep, they are, and those are filtered by assignee. (The links aren't shown if you're logged out.)

changed milestone to %Backlog in gitlab-foss

@sarahod @tauriedavis : We're throwing this into the gitlab-foss~~2024187 bucket for now. Probably you have plenty to do already. So not high priority compared to all the navigation things going on. Development will just focus on other gitlab-foss~~2731248 issues in the meantime. There's no shortage of them. Let us know if when you're able to chat about this.

Thanks @victorwu, like you mentioned I'm not sure we will get to this for a bit.

What if we do the following in the meantime:

Default view is set to issues assigned to me
Reseting filters shows this default view
If a user tries to change every filter to Any then we throw an error saying at least one filter option must be selected

This means you can never navigate to the list when no filters are selected and so the list would never be giant but you would still be able to filter by any author, assignee, etc., in every project.

I think this is virtually option 2.