Skip to content

[VSA] General VSA Feedback From Gabe

Overview

This issue description explains multiple feedback items. The details are below, but here is a checklist summarizing the items and showing whether they have been addressed.

Creating A Custom Stage

Extra padding on this field

Screen_Shot_2020-09-15_at_3.37.04_PM

Cancel is disabled...why?

I can't leave the edit screen without clicking on another stage...I would think clicking "cancel" would close the edit view.

Screen_Shot_2020-09-15_at_3.37.54_PM

Data Integrity

Confusing and questionable data

the Validation Backlog stage is configured to Start = workflowvalidation backlog applied and Stop = workflowvalidation backlog removed.

Screen_Shot_2020-09-15_at_3.38.37_PM

  • "How can we help users find..." shows it has been in Stage for ~1 minute, but the issue (#249244 (closed)) shows the label was applied ~25 hours ago.
  • https://gitlab.com/gitlab-org/gitlab/-/issues/242009 shows it is "workflow::validation backlog" but it does not show up in Design ("workflow::design") even though that label has been on this particular issue for ~4 days.
  • #246795 (closed) is currently in Planning Breakdown but shows up in Validation Backlog. In all the situations where an Issue has passed through a particular stage and onto the next, I would expect it to show up in both places with some sort of visual indicator telling me the issue is currently active in this stage vs. already passed through this stage. Right now, we don't show the active stage an issue is in and this feels not right.
  • basically applies to every stage and makes it horribly confusing for me to actually see what stage an issue is currently in.

Broken Metrics

Confusing Reports

Days to completion

I don't really understand how this is being calculated or what it is telling me. I would also expect it to change based on the filters I've applied (label = groupproject management)

Flawed Assumptions?

Issues and merge requests are grouped together in pairs, such that for each <issue, merge request> pair, the merge request has the issue closing pattern for the corresponding issue. All other issues and merge requests are not considered. (from the docs - https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html)

How is the stage time determined when 1 issue has 5 merge requests?

What if none of those merge requests use the Issue Closing Pattern because it is a configurable setting that many teams opt out of? (https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#disabling-automatic-issue-closing)

I would expect cycle time start to = Timestamp of 1st commit/MR that mentions an issue - Timestamp Issue closed

Type of Work is not super useful for providing actionable insights

I work in a cross-functional group within our larger GitLab value stream. I cannot see type of work for my team only because we only show single labels...not groupproject management and ~bug.

Edited by Libor Vanc