Ensure we (GitLab) use all our features.
Definition of the "do we use it?": someone on the team clicks on the link at least once and month to gain some new information.
Interviewed different people and collected their feedback into a google doc.
https://docs.google.com/document/d/1n0WaJKfenTzewXUm5H59azorI3TIdhdHlBnwleNElBM/edit?usp=sharing
Feature name | Do we use it? | Can we use it? | Must Improve/Issue | Action Items |
---|---|---|---|---|
Across All Products | Macro UX Patterns | Not scheduled | ||
Contribution analytics | No | No | Graphs are unreadble | Scheduled for 11.0 |
Burndown charts | Yes(GCP migration) | Yes and No | Burndown charts don't exist at the group level | Scheduled for 10.8 |
Service Desk | Yes
|
Yes |
|
In a good enough state right now. Product should review if private comments are a possibility |
Container Registry | yes |
|
Schedule a PR for docker that will fix this outstanding bug | |
Issues board | Yes | Yes |
|
Full Subgroup support by 11.0. Speak with UX to make paradigms more clear. |
Approvals | Yes | Yes |
|
Talk to UX and Product about implementing missing features. |
Epics and roadmaps | Yes | Yes |
|
|
Deploy Boards | No | No | No. We don't have any apps to deploy yet. | Find applications of ours that will fit into the paradigms of deploy boards and use them. |
Auto DevOps | Yes (Cloud Native charts) | Yes and no | See https://gitlab.com/charts/gitlab/blob/master/.gitlab-ci.yml | Enable it for our internal apps. https://gitlab.com/gitlab-com/version-gitlab-com/issues/111 and https://gitlab.com/gitlab-com/license-gitlab-com/issues/79. |
Application performance monitoring | Yes (Cloud Native charts) | Yes | We deploy GitLab and have monitoring enabled, see https://gitlab.com/charts/gitlab/environments/190276/metrics | Find more applications of ours that will fit into the paradigms of application performance monitoring and use them. |
Cycle analytics | No | No | No one uses it. The data is not that interesting. A lot of the data is empty for CE and EE. We have so much activity and we just have no data. We think the concept is interesting but it's not useful, interesting. It would be really interesting to know within GitLab, how long did it take for someone to respond to a MR. See where things are slowing down in the pipeline. | Overlaps with: https://gitlab.com/gitlab-org/ux-research/issues/24 & https://gitlab.com/gitlab-org/gitlab-ce/issues/37195. Users aren’t currently utilising Cycle Analytics as it’s too restrictive - it doesn’t support their workflow or report the data they need. First and foremost, users want a way to track and report on existing project progress (via dashboards) as opposed to retrospectively looking at project progress (via Cycle Analytics). Internally, it's a similar situation: &135 (closed) (Team dashboard) |
Cohorts | No | No | No one uses it because it just isn't useful. | Do UX Research to figure out how to make the data more interesting. |
Review Apps | Yes | Barely |
Pain to get working. Lot's of custom configurations just to get it working. Hard to get it working at all.
|
Enable it for more projects |
Dependency Scanning | Not yet (added in %10.7) | Yes (added in %10.7) | Standard job config, languages support, report content | None |
Container Scanning | ? | Yes (with whitelisting) | Standard job config, whitelisting, report content | None |
DAST | Yes and No | Yes | Standard job config, languages support, report content | None |
Code Quality | Yes and No | Yes | Standard job config | None |
Blocking manual actions | No | Yes and No | Using blocking manual actions with GitLab QA | Do UX Research to figure out how to make the data more interesting. |