Tasks by type chart is current based on quantity of issues/MRs but it's also useful to have this visualisation as a percentage to understand how time is being allocated.
JTBD
As Engineering Managers I need to balance type of work (features, maintenance, bugs) so I my team can have a healthy prioritization method and to response quickly for changing needs.
As PM I want to have monthly MR type reviews with the engineering managers so I can improve how I prioritize feature.
Haim Snirchanged title from [VSA] Tasks by type chart - switch between percentage & quantity of tasks to [VSA] Tasks by type chart - add percentage pie chart
changed title from [VSA] Tasks by type chart - switch between percentage & quantity of tasks to [VSA] Tasks by type chart - add percentage pie chart
Haim Snirchanged the descriptionCompare with previous version
changed the description
Haim Snirchanged title from [VSA] Tasks by type chart - add percentage pie chart to [VSA] Tasks by type chart - add percentage pie chart and historical trend chart
changed title from [VSA] Tasks by type chart - add percentage pie chart to [VSA] Tasks by type chart - add percentage pie chart and historical trend chart
Haim Snirchanged the descriptionCompare with previous version
@justinfarris Yesterday's discussion about the updated prioritization process, came at the perfect time for groupoptimize - we were looking for such feedback to validate the usability improvements for the Tasks by type chart.
Per what I learn from the direction page and slides - I updated the visualization enhancements, and we'd like to hear what you think about this, and if you think we can plan for a Dogfooding POC.
FWIW it looks like we currently don't have any type of pie chart in gitlab-ui, so there would be some additional work to either wrap around the echarts pie chart to use it in Vue JS, or implement in gitlab-ui first.
I updated my suggested solution to include the option for a new Tab for the historical trend chart and pie chart. "% Work Distribution" might be a good name. Once we have more progress with the design, we should get TW feedback on this.
@hsnir1 I plan to look at this in this milestone — thanks for getting ahead of it.
I plan to explore this in more detail, but 2. and 3. would not be possible in the way you describe. Labels are user generated, and type:: labels are (afaik) only used internally at GitLab. The solution will need to work for all users, not just those at GitLab.
The original proposal suggested that the behaviour for these and the accompanying tasks by type chart should
Use the filters
If no filters use the top 10 labels
I will explore this and other solutions in this milestone
I plan to explore this in more detail, but 2. and 3. would not be possible in the way you describe. Labels are user generated, and type:: labels are (afaik) only used internally at GitLab. The solution will need to work for all users, not just those at GitLab.
This was my thoughts as well, I think the only option is #1 (inherit from the VSA filter labels)
No, I haven't heard of any other groups needing/requesting a pie chart. From what I've read, the general rule is that pie charts should be avoided, where at all possible, as there is often a better way to communicate the data, visually (a quick google turned up this article, and this one).
@danmh - are you still thinking you need a pie chart? Or, have you found another solution?
It seems the preferred solution is to use the following type of visualisation.
I don't know if this is the preferred solution btw, or just the one we have currently. I think it works pretty well but, I don't think this is actually a chart in GitLab UI I guess I'm saying: if something like that works in your use case, then it's a pattern you could consider following. But, if it doesn't work and you have an idea for something that could work better, I think there is space to define a new path here, too
I have spent some time exploring ideas of if and how this could work. Warning: long comment ahead. I've broken it down into sections to try and make it easier to read. Please feel free to skip sections you aren't interested in.
tl;dr I don't think it is possible to use this page for cross functional dashboard reviews because of GitLab's use of labels and its implementation of filters. The solution requires filters to be applied using the 'or' operator — show me issues with the label ~"type::bug" or ~"type::feature" or ~"type::maintenance". The filters only allow the 'and' operator — show me issues with the label ~"type::bug" and ~"type::feature" and ~"type::maintenance" — which would always show 0 results. This might be a great candidate for Insights. That said, there might still be user value in the initial solution. If there is we could build it for them anyway.
Lets have a look in more detail...
Pie charts
Initial solution
The problem with filtering
A different solution
Next steps
Pie charts
Pie charts were removed a few years ago. With the UX recommendation that we avoid using them. Pie charts are one of the hardest types of charts for us to parse, we're least good at judging volume for a variety of reasons (source). They were removed from insights in this MR Resolve "Convert Insights to ECharts" (!24661 - merged). There are more details in this discussion #196184 (closed)#13006 (closed)
It seems the preferred solution is to use the following type of visualisation. I'm not sure if we have a name for them in the product, but perhaps 'stacked horizontal bar chart' works. See examples from repository languages and usage quotas:
Repository
Usage quota
Initial solution
Confident that the stacked horizontal bar chart would be a suitable alternative to pie charts in this instance I went ahead and sketched up how and where they might appear on the page.
A. Original solution from the issue description. % work items in a separate tab.
B. I assume it would be useful to compare both, so split out from tabs. Side by side arrangement like the issue description. Concerns about height matching these quite different elements. After drawing up higher fidelidy, concerns about the scales not matching the tasks by type chart which might make comparison harder (see G)
C. Full width charts. Concerns about charts needing headings for context (see H).
D. Exploring concept of these new charts being children of the tasks by type section rather than their own section.
E. Experiment with order, assuming the present is more important than the historic data.
H. Higher fidelity sketch of full width charts. Allows comparisons between task by type chart as date axis lines up. Concerns about lack of headings.
To reenforce that the filters apply, the filter bar could be sticky. This could make it easier for users to make changes while reviewing charts.
The solution is demonstrated in the following rough mocks:
I
J
I. The full page mockup, with heading sizes showing the relationship of Tasks by type as the parent category.
J. Illustrating the sticky filter bar.
However, the filter bar doesn't allow our desired behaviour to help us dogfood the cross functional prioritisation...
The problem with filtering
Labels
Internally GitLab uses labels heavily. I half remember hearing the average internal GitLab issue has ~10 labels when the average for our customers is ~2.5 .
We use labels for everything:
Identify issue type
Identify responsible team
Display the current status
Notify the right people for reviews
Group similar work together
And so much more
It is awesome! But because we've developed and rely on a pretty robust label structure, can hide some of the pain our customers may have.
Issues have no native way of identifying if they are a bug or a feature. It relies on user generated labels to be applied. And each group of people using GitLab will create their set of labels and their own way of using them.
Because of this, if we want to narrow the scope of what to display based on 'group' or 'type' in a way that works for everyone, our solution will have to allow users to select any labels.
Because we want to see all issues that have one of these labels we want filters to be applied using the 'or' operator — show me issues with the label ~"type::bug" or ~"type::feature" or ~"type::maintenance". But filters only allow the 'and' operator — show me issues with the label ~"type::bug" and ~"type::feature" and ~"type::maintenance" — which at GitLab would always show 0 results.
You can verify this by visiting Value Stream with filters and review the Total time chart. Note: task by type chart is not yet affected by filters (#258680 (closed)).
There is an active issue discussing allowing or for filters. With the oldest issue I've found about this being 6 years old. (Other closed related issues 1, 2)
It doesn't look like behaviour change needed for us to use this for the cross functional dashboard review will happen in the next few milestones.
We can't hard code some magic here to help us, as the type:: labels are GitLab created and I don't think a solution that requires users to adopt our labels and their usage is a viable solution.
So where does that leave us?
A different solution
To help us see the proportion of issues with ~type:: labels, enter our friend Insights.
Configure the Insights that matter for your projects to explore data such as triage hygiene, issues created/closed per a given period, average time for merge requests to be merged and much more.
I think this sort of charting meets the description well. But unfortunately I don't think it will work without some changes (cc: @ahegyi ).
We would need to have a chart that can show proportion rather than quantity. But selecting a narrow set of labels, a specific timeframe and showing them on a line chart is already within the existing functionality.
Because of the challenges with filters, and GitLab's reliance on labels, Insights seems, to me at least, to be a more feasible way of visualising this type of information in GitLab. And could be suitable for the cross functional dashboard reviews.
Next steps
Although extending tasks by type can't be used for our cross functional dashboard reviews, the functionality might still be useful to customers.
The original problem for this issue was:
Tasks by type chart is current based on quantity of issues/MRs but it's also useful to have this visualisation as a percentage to understand how time is being allocated.
Adding the horizontal stacked bar chart would still give users this visualisation. And showing the proportion changes over time might still be useful (we show over time in the tasks by type chart).
If we think this still meets a customer need, and needed for viable maturity, then I think we can go ahead a build proposal I.
Thanks for reading this far. Sorry if its a bit unclear, I'll try and edit for clarity tomorrow!
I don't think we should have the pie chart / horizontal stacked bar chart to show the proportion. Because labels are not exclusive they can add up to more than 100%.
I have been thinking more around the challenges caused by lables. Consider a team that completes the following two issues within a time period.
Presenting these as a proportion of 100% makes it look like only 50% of the issues were features. See the following example for the previous two issues.
I think the historical view over time still makes sense however. See a different period for a this example company. At this company they only add one 'type::' label to an issue, but issues can be frontend, backend or both frontend and backend:
This is a wonderful exploration of data visualization patterns and when it is appropriate to use a specific pattern.
@jeldergl I'm curious if you have thoughts here. Is this discussion particular helpful to inform data visualization pattern usage? Is there anything you'd like to add to this conversation?
@danmh Thanks for putting this research together! I love the sketches!
tl;dr I don't think it is possible to use this page for cross functional dashboard reviews because of GitLab's use of labels and its implementation of filters.
Following our chat, yes I agree.
I don't think we should have the pie chart / horizontal stacked bar chart to show the proportion. Because labels are not exclusive they can add up to more than 100%.
How about 100% Stacked Bar Chart? Here is an example from the Configure group:
show me issues with the label ~"type::bug" and ~"type::feature" and ~"type::maintenance" — which would always show 0 results. This might be a great candidate for Insights.
Because of the challenges with filters, and GitLab's reliance on labels, Insights seems, to me at least, to be a more feasible way of visualising this type of information in GitLab. And could be suitable for the cross functional dashboard reviews.
Yes, that makes sense, especially considering the outcome of the Insights Spike Research POC.
My only concern with insights is the Consolidation and Centralization of GitLab's analytics pages. I don't want to break the flow for the user when investigating Work Distribution as part of the VSA deep dive flow.
Thanks for this great summary of our discussions as well as your thoughts and possible paths forward @danmh.
Issues have no native way of identifying if they are a bug or a feature. It relies on user generated labels to be applied. And each group of people using GitLab will create their set of labels and their own way of using them.
The only callout i want to add is perhaps we should also collaborate with the team that is handling Work items. AFAICT work items could solve the issue we have with labels as it should help provide a more structured way to identify types of work, the most relevant epic's i've found are:
I'm not sure on the status of this work, so I might just ping a few people who may be able to provide an update as a starting point. Perhaps @mushakov@cdybenko@uhlexsis ?
The only callout i want to add is perhaps we should also collaborate with the team that is handling Work items. AFAICT work items could solve the issue we have with labels as it should help provide a more structured way to identify types of work, the most relevant epic's i've found are:
Thanks @ekigbo! I'll reach out the Foundations team to see what options are available.
Haim Snirchanged title from [VSA] Tasks by type chart - add percentage pie chart and historical trend chart to [VSA] Tasks by type chart - add "Work distribution" percentage chart and historical trend chart
changed title from [VSA] Tasks by type chart - add percentage pie chart and historical trend chart to [VSA] Tasks by type chart - add "Work distribution" percentage chart and historical trend chart
Haim Snirchanged the descriptionCompare with previous version