Design exploration for instance and group level cycle analytics
Description
Cycle analytics is a feature with a lot of potential. Currently, this cool feature is only available at the project level and is a bit challenging to find - it's the 3rd option available on a mouseover of "Project" in the sidebar.
Making cycle analytics only available on a project-by-project basis makes it very hard to use. Organizations with many projects can't use this information: it's too granular, hard to click into every project to view, and makes "not enough data" issues more likely.
Problems
- How can we make Cycle Analytics useful for organizations with many projects?
- How can we increase the visibility of Cycle Analytics, so that more people are aware of this feature?
- How do we connect instance-level, group-level, and project-level Cycle Analytics together?
- Where do we present Cycle Analytics in the UI?
Solution
Bring Cycle Analytics to the global level by adding it to the Instance Statistics Dashboard where ConvDev Index and Cohorts currently live. Project and group-level scoping would be achieved based on the filtering functionality that would be introduced with #3759 (closed).
Without any filters, this view will show Cycle Analytics for the whole instance. If the user selects a group or project as a filter, the analytics will change to reflect statistics only from that context.
When the user clicks on the filtering bar, a menu with the following options appears:
project:path-to-project
group:path-to-group
label:~label
After the user selects one of the filter types, a list of appropriate suggestions appears:
Project | Group |
---|---|
Some of these filters will be exclusive, so their behavior is detailed in the table below:
The existing project-level Cycle Analytics
We will retain the existing project-level Cycle Analytics in addition to the new global dashboard. This will prevent current users will from feeling it has disappeared without warning and feeling lost. This way, we can also introduce existing users to the new functionality.
We will integrate the project-filtering token UI at the project level, but we will not let the user change the scope. Instead, when they click on the token, we will show a popover with the following text:
Explore Cycle Analytics at the project, group or global level by visiting the Statistics Dashboard.
In the popover, there will be a link to take the user to the global-level dashboard.
Project level | Popover |
---|---|
Visibility of the Instance Statistics Dashboard
Administrators have the ability to hide the Insntance Statistics Dashboard for regular users. This is achieved through a on/off switch that toggles the visibility for the whole dashboard. We will introduce more granular controls so administrators can hide the following elements individually:
- ConvDev Index
- Cohorts
- Global Cycle Analytics
Even if administrators disable all three, users will still be able to access the Dashboard to make use of group-level and project-level Cycle Analytics.
Even if they disabled all three, the icon would still show up in the top bar to allow users to view group and project-level Cycle Analytics. Do you think that makes sense.
A note on icons
The icons used in this proposal are pending review:
- The
users
icon that we use for Groups is also being used in the Instance Statistics left sidebar for the Cohorts feature. - We currently do not have an icon for Cycle Analytics, so one will need to be created for the left sidebar.
Original
We should consider a new design for Cycle Analytics that covers a group and for an instance:
-
A user should be able to interact with a unified Cycle Analytics page. I should be able to specify the scope of what I'm looking at, and narrow the information presented from instance > group > project.
-
Relocate Cycle Analytics to a more prominent location in the UI: the analytics icon in the navbar here in https://gitlab.com/gitlab-org/gitlab-ce/issues/41416. Make instance-level cycle analytics the default page.
Future exploration
- Show past performance. Are we getting faster/slower relative to the past?
- Which events/issues/MRs are driving the change in velocity?
- Show performance relative to other projects/groups.
- Introduce other metrics (e.g. size of commit/MR)
- Suggestions/recommendations.