Out of the box starter charts for Insights with additional options to configure via yaml file
Problem to solve
We built a highly configurable charting system which can help provide insights on open issues, merge requests, and more. Unfortunately, the current implementation requires users to add a .insight.yml
to the repo, before any charts are displayed. This is not a good first experience for new users.
We should strive to have a convention over configuration approach, where the first click on Insights loads a great default dashboard.
Intended users
Further details
Proposal
From https://gitlab.com/gitlab-org/gitlab-ee/issues/9486#note_153651617
We need to show a dashboard when a user clicks on Insights
for the very first time, without an .insights.yml
file in their repo.
To accomplish this, we can:
- Add an instance level template for
.insights.yml
, which includes our default dashboard. - When a user clicks on
Insights
, and there is no.insights.yml
in their repo, we will automatically use the instance template instead. This is essentially the same design pattern we have with Auto DevOps.
This way a user can easily modify the default dashboard by adding a .insights.yml
file to their repo based on the template, and then editing as desired.
Default starter charts
- Total MRs per month & per week.
- By default show all MRs for that project or group (inclusive) depending on the user's permissions
- List of projects to exclude can be overridden by yml configuration
- Bugs created by priority
- Display ~bug created per month by priority. Default to
bug
label - Define a default label set that will be use for priority levels. If labels are present display the issues with this label.
- Display ~bug created per month by priority. Default to
- Bug created by severity
- Display ~bug created per month by priority. Default to
bug
label - Define a default label set that will be use for severity levels. If labels are present display the issues with this label.
- Display ~bug created per month by priority. Default to
- Priority, Severity and Bug labels can be overridden by yml configuration
From @rymai:
we'd still need a way to configure the labels used to filter / group the data (e.g. we use ~P1, ~P2 etc. but another organization could use
priority:1
,priority:2
etc.). I agree this could be done later via UX
We can define a set of default labels that can get picked up. This would lower the bar in configuration. But then the existence of the yml file would override this. E.g.
-
insights:P1
orPriority 1
orP1
-
insights:P2
orPriority 2
orP2
-
insights:S1
orPriority 3
orP3
-
insights:S2
orPriority 4
orP4