This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Instead of colors, could we elevate an existing label to be the "main" label of an epic? That way we get the color for free. But that also seems messy.
Thought about this as well, and elevating the “main” label color. The problem is knowing which is the “main” label
I like @JobV's simple proposal. In a future iteration, we could allow defining a default epic color per group, so you don't have to always change the color.
Question: how would we use this feature internally? To differentiate stages? Would Plan and Create have a different color? How would you define this? We should at least think about our own use case before committing to this.
@pedroms: If we had additional colors, it would open up the ability to do things like sorting and ordering. So say within the Plan roadmap you want to see all the board-related epics toward the top and the issue-related epics toward the bottom. Thanks for bringing this up. This leads me to think we should do the label approach. Let me explain further. (And I’ll let @JobV defend his concept further.)
Instead of right click and select color. Right click and select label. Then the epic bar inherits that color automatically.
And then in the filter bar / drop down area, there would be additional options to order epics in the roadmap by label.
So for example, suppose you have these epics shown in the roadmap with these labels:
Epic 1: Create, Code Review (Orange)
Epic 2: Create, Merge Requests (Red)
Epic 3: Create, Merge Requests (Red), Approvals
And so you would set epic 1 to inherit Orange by selecting the Code Review label. You would set epics 2 and 3 to inherit Red selecting the Merge Request label.
And so in the filter/dropdown UI, you would somehow indicate you want to group by Code Review and Merge Requests.
And the visual effect is that the colors would look clean and grouped on the roadmap view.
The benefit with this approach is that you can still use labels to do most of the implementation. And for the UI to select grouping, you don’t have to introduce colors, which could get messy quick.
@JobV : The red flag for me with colors, is that you require a new additional field per epic. That's not terrible in itself. But the moment you need to interact with colors in sorting/grouping, I worry.
@jeremy_ : I think @JobV mentioned that you would be interested in this. (Correct me if I'm wrong.) Wanted to get your take on how you would use this in terms of sorting and grouping.
My understanding is that you would essentially be able to combine the two roadmaps (as you see in the screenshot below). So basically imagine that in the below view, but each section has different colors, and they can independently be sorted. Is that how you would use it?
And so in the filter/dropdown UI, you would somehow indicate you want to group by Code Review and Merge Requests.
And the visual effect is that the colors would look clean and grouped on the roadmap view.
@victorwu sorry but I still don't understand the underlying motivation for grouping them. I do want to understand that so I can help us the best I can. What information are you looking to extract from looking at “grouped epics” (essentially epics that share something in common)? For example, looking at the image you shared in your previous comment, what's the story behind this?
This is a great visualization and people can sort by dates.
But with this visualization, I can only see all areas mashed together. If I want to drill down on ~"code review" , I have to filter further. If I want to drill down on ~"web ide" I have to filter further again. But if I want to see these two areas stacked on top of each other at the same time (is that screenshot) I currently have no way to do that.
And the reason I want to stack them like that is that I can at a glance see the ~"code review" chunk versus the ~"web ide" chunk. And see their relative times.
So that’s why I was suggesting that colors inherit the label colors.
@pedroms: Above is at least how I imagine why I would use colors. @jeremy_ and @jramsay might have other ideas.
But suppose I continue to be James. Let me propose an alternative that doesn’t require setting colors manually.
There’s two “levels” of label filtering in the filter bar. (I have no idea how the interaction design would work. But please bare with me.)
So in the first level of the filter I say ~Create. That will return only the ~Create epics.
Now in the second level, I choose labels ~"web ide" , merge requests and ~"code review". So GitLab takes the result set from the first level and then sorts them into three sets based on this second level. And then these three sets of epics are stacked on top of each other in the view. GitLab automatically picks three unique colors for me to represent the three sets. (It would be smart and not just choose blue for all three.) If an epic belongs to more than one set, it would just appear in more than one set in the view.
Essentially I’m proposing a complicated boolean operation. I think this would be extremely compelling if we nailed the design and use cases. But it’s super risky if any of those fail. Please poke holes in my ideas.
I really like the concept of going beyond colors and allowing me to define a label for this higher-level split. We do this for labels (color + text). Couple of uses come to mind:
Epic of epics. I don't necessarily need a full epic-of-epics with labels, description, etc. But man, it'd be nice to be able to roadmap all my billing epics under a "billing" header with a unique color.
Organize epics by outcome or initiative. I've seen this at other companies, where an epic has additional fields like "outcome" (increase revenue, increase user retention, reduce operational cost, whatever) that you can sort by to give a quick answer to "how are we going to improve revenue?". Same thing for really long, complex initiatives that span multiple epics.
We’ve been using them to denote both Product work and Engineering development, and would be great to be able to assign different colors according to the type of work being done
There’s two “levels” of label filtering in the filter bar.
@victorwu after your first comment, this is exactly what came to my mind Maybe a “Group by labels” control where you select labels? We're already considering a “group by milestones” control inside epics, so it could be similar. (And then, if labels have the same color, instead of showing completely different colors, we can just vary the brightness of the colors.)
@jeremy_ good point about “outcomes”, “initiatives”, and “themes”. I think Atlassian's article on epics describes that pretty well:
Article quote
A product roadmap is a plan of action for how a product or solution will evolve over time.
A theme is an organization goal that drive the creation of epics and initiatives.
The product roadmap is expressed and visualized as a set of initiatives plotted along a timeline.
Breaking initiatives into epics helps keep the team’s daily work — expressed in smaller stories — connected to overall business goals.
A set of completed epics drives a specific initiative, which keeps the overall product developing and evolving with market and customer demands on top of organizational themes.
From our example above, a theme would be increasing space shuttle launches, the roadmap would track towards increasing launches from 3 per quarter to 4, the initiatives would be to drive down costs and increase ticket sales, and each epic would roll up into the initiatives.
Instead of creating an entirely new object inside GitLab, I think we can have the same functionality using epics relationships and labels.
I think you can get away using a single object with relationships to model T > I > E, as they mostly differ in granularity of conversation and timescale. The only thing that comes to mind where you may differentiate along the tier is when financials come to play. ie. investment, estimated cost, actual cost (Roll up), cost of delay, etc. May not exist at the epic but certainly above that. That said, it's a whole other area that may not be up for consideration (yet). Epics + hierarchy + labels sounds like a fantastic way to start! :)
Thanks @pedroms for the idea. Yes, I am thinking about "group by". It's similar to the concept of "group by" when you write a SQL query, and you are collapsing records together based on a certain field.
@victorwu so is it fair to say that this issue is not about “epic colors” but more about visually grouping epics that share specific labels? Feel free to schedule it so we can dedicate more time to this.
I like the idea of the epic inheriting label colors, but I'm still not sure exactly how it would work. Consider this view:
If we were to color-code each epic bar by label color, the first question would be, which label should it use? Here are all the labels for one of those epics:
It would make more sense if your filter options got more specific. Say you wanted to search for ~Plan and ~"portfolio management" orGitLab Ultimate . If you were to do that, you would see the two badge colors in the filter bar, and the epics would have the correct corresponding colors. You'd know exactly what the color means because it's right there in the filter bar. A few of the problems with this is that:
You can't choose and/or in the filter bar
If two labels have the same color (like boards and ~"portfolio management"), you're not going to get any benefit here
@victorwu would it be possible to color code epics bar on roadmap based on their completion status? I mean Based on current date (red line) are the epics:
In progress
Late
Not yet started (upcoming)
Really like a RAG status on it. I hope this makes sense.
Not at all. We just aren't currently able to move it forward in the current release as we are focusing on 2 major improvements to the roadmap via #5164 (closed) and #7077 (closed).
As we increase functionality of the roadmap, this item is still important and planned to be validated and worked through. It is part of a larger epic (&2003 (closed)) which is required for us to reach a Viable state of Maturity for Roadmaps.
When we are able to dig into this further would you be willing to provide feedback and thoughts as we validate a design?
Phew! Absolutely @kokeefe , you can surely count on me on what I can help. Plus, thank you heaps for the prompt response (again). I do appreciate you and the team are very busy bees. :)
One of my customers would like us to consider implementing this. "being able to right click an epic in the roadmap view and choose a color (basic) or choose a color/label (complex) both would serve our initial ask."
We would also really like to be able to choose a colour for each epic. Ideally we just want to pick a colour for the epic rather than having it select a colour from one of the labels.
@SteveTerhar@espadav8 In our desired use case, colors would correspond to common points of significance in an app's lifecycle. Consider: awaiting approval, first release, initial user feedback, and scaling. Each of those is rightfully an epic, not an issue: you can have many issues to get you to your first release, many issues to build in feedback collection, and multiple issues in scaling (marketing to get new users, going to a higher paid plan for the backend to handle the volume, need for new search filters due to volume, etc.).
This is especially significant where there's bottlenecks. As a hypothetical example, suppose 5 apps -- the red apps -- need an action from one of very few people while another 6 apps -- the blue apps -- need an action from one of a different set of very few people. It could be that the red apps all have the same stakeholders and need approval. It could be that all the blue apps need better advertising, but your company has few people working in the marketing department. So color corresponds to a waiting queue. Or at least a "zone of slowness" if things are being juggled.
So there's a refinement here: instead of "awaiting approval" being one color, there'd be multiple colors, one for each stakeholder, leading to bottleneck-centered coloring.
That's a fantastic MVC, ma'am! As for the edge to place the color on, I think it should be determined by the handedness of the language: left for English, right for Hebrew (not top or bottom).
Advantages of that choice:
Reserves the horizontal dimension for separators (like a dummy epic named ------------ Dec 17th ------------), potentially handy on an epic board.
Easier for my eyes/brain (or so I believe): scanning down, the colored lines are all aligned. I'm not jumping over as much.
I was going to work some more on my MR tonight, but I am also conscious that Work Items are coming "soon" and that might make some or all of the changes moot.
I'm keen to think of the MVPs and cut back some more of them MR where it makes sense. Having colours in even for a few months could be helpful.
I'm also interested to know if Work Items plan on supporting colours too, other than the colour and icon they get from their type. If they don't have the ability to choose a distinct colour, how much of the code that I have could be reused by Work Items.
@espadav8 I agree it could be useful, even for the short-term. Is there a concern that the new design is too much for an MVC? Is there a way you think we could break it to be smaller?
The MVC is only slightly more work than what I currently have in the MR. I need to work out how to do the colour drop down and add it into the sidebar though. Currently I just have a free text field you can type the hex colour into.
I'm off for the next 4 days after today though, so it'll be delayed for a bit
As Product Owner, I was hoping I could color code the Epics in Roadmap so that the developer aspects stood out from the rest of the organization's milestones on the Roadmap.