 So, one thing I want to talk about is the product categories page. So if you click on the first link there, that is a page that we've been using for a long time now at GitLab, and in the beginning it was a way to tell folks, especially within GitLab, what each product area is working on. And so, for example, we always tell people who are triaging issues and so forth, like, you know, assign this team label, blow it all up. So this page has grown in usage. And one of the uses is that there's this thing called categories as well as stages as well as features. So there's a hierarchy. So if you click on the other thing there, which is a link there, there's department stages, categories and features. So departments are dev versus ops and then stages, which are the seven stages, or I guess there's nine now if you count everything. There's categories and then there's features. And then at one point there was capabilities. And I don't know why we, I think folks in product marketing and working with CID said that they didn't want to have that level of complexity. So basically, there's these four right now. And so if you were paying attention in Slack about like half a year ago, you saw like, I think it was Mark Fletcher was working with CID to get everything into something called features YAML. So that's also related there. So if you click on features YAML, it's a really messy list right now at the moment of a lot of features and part of this taxonomy and then so we're slowly cleaning it up. And so there is a bunch of uses for this, for these four categories and in particular features YAML. So if you click on features YAML, you'll see things like, if you just search like, say for example, issue board or something, there's a bunch of like attributes and they're all really interesting. And so for some attributes, we'll say like some really obvious things like, is it which tier it is in? So that's pretty obvious why that's useful. And then there's things like, who are the competitors? There's even like an attribute for like ROI and stuff like that. And the reason why there's all those attributes is that this source of truth, features.yaml is driving a lot of different pages on our website. A lot of the product marketing facing pages. So for example, it's driving that product categories page, maybe not obvious. Well, it actually wasn't before, but now it is so that that's good. And then it's driving things like the, when you go to about.glab.com, there's things like it explains the product and there's like a pricing page, a product page and then it pulls in all these things. So it's driving a lot of those things and then there's product comparisons with other competitors and so on and so forth. So that's why you'll see comparisons as well. Like you'll see like GitHub and like another like Jira and stuff like that. So if you search for issue boards, there's one entry there and then it'll say like GitHub is partially, Bitbucket is false, Asana is false, Jira is true, CA Adrocentra is true, Zebia Labs is true. So all that is driving all this other things. So it's a bit crazy right now. I don't know the future of it if we're going to keep using features YAML, but it's I think it's one improvement because I think we have a categories YAML. I believe so. I'm pretty sure we do. So that's already improvement from just having features YAML. We have a categories YAML and what else was I'm going to say, so this was brought up because Sean pinged me on letter B on a recent plan categories change that John Jeremiah. So if you look at the product categories page, it shows you like all the stable counterparts in all the other departments, right? And so product marketing for plan, actually for the entire dev stage is John Jeremiah, if you notice that. And so I've been working closely with him to clean up the categories. And so you'll see things, for example, like we have our categories are the big one are project management, the big ones are project management and agile portfolio management. And we have other things like Kanban boards, which is sort of weird. Like why is why is that feature called out as its own category? And that's just to really differentiate it and say it's a category and not a feature, even though it's sort of not really true. But we want to be able to do like comparisons and communicate with the industry that this is a thing for us. So some of these are driven by multiple needs and that's one of them. Another one is like service test, for example, and that's sort of weird for a category again. So we might roll that into a different category in the future. And then we have things like a value stream management, requirements management and quality management. So that is also illustrative of the purpose of these categories in that we actually might not have any features in these categories. So for example, value stream management, we know what we want to do, but we don't have actually a lot of features there at all right now. And even less so for say requirements management and quality management, we don't even know what's really our vision and that's something on my homework list to do and I've been working on the past couple of weeks. But those areas are, we just are not competing there. But the fact that we're already putting it in to our product categories serves multiple purposes, one of them is communicating to the industry. We recognize these things. We care about these things if you want to contribute or you want to send us an email about it and ask us about it, of which customers do. Then it's there and so that's serving one purpose and it's also a signal. For example, right here it says on the product categories page it says value stream management, requirements management and quality management are planned 2019. So it's telling the market that these are things that we're interested in next year. So that's why it's serving all of these purposes. So that's all that to say that won't impact day to day your work. We're still building features and it won't even impact, as I know right now, the documentation. So you can think of where would it even impact? Even documentation, I don't think there's a clear plan yet, especially from a documentation team, on how we should align categories. I think it would be nice, but there's just so much debt to clean up from just categories perspective and then the product marketing side. And then we hired a new CMO recently. So I expect there's a lot of change there that is going to impact the website and maybe impact some of these categories and so on and so forth. So that's why it will probably be a while before it will really impact this team here. But it's just good to know how we're communicating with the wider community. And so the one thing I can see perhaps it would matter would be when we're naming things, right, when we chose the word epics and it took a long time. And then the next thing we're going to start naming is are we going to call them subepics and I think we don't want to do that. And when we do requirements management, for example, are we going to call them requirements? Are we just going to call them issues? Because we're unlikely to invent a new thing, a new object, to satisfy the requirements management piece, right? And so that would be relevant here. So I wanted to just highlight that. If no questions, Sean, you're up. Yep, just a couple of things. The first one is that we renamed functional group updates to group conversation since the last one we did, but we also made what I think is a very good change, which is that they apply to the whole stage group. So the front and the back end, the UX product management quality people working on plan rather than just a team, which is like the plan back-end team. And so this is our first one. Since that happened, the way I've been doing it historically is using GitLab pages and this JavaScript library that lets you write your slides and mark down. I'm hoping to change in that, but it looks like we're doing that again this time. Pedro is volunteered to help out with the conversation so that even the presentation part is more conversational and it's not just one person going through the slides. If anybody else would like to help out there, please post on the merger quest. Otherwise, feel free to post stuff. I'll be working on this throughout the rest of this week. So if there's anything you think we should include that's notable that we've done in the last eight weeks or that we're going to do in, well, I guess the next eight weeks, but maybe that's a bit too far out in some cases, then let's mention that. And yeah, Victor, I think you said you were away for that conversation. Is that right? That's correct. Yeah. Okay. So yeah, Pedro and Annabelle, I see as well, which kind of makes sense because it's two days before Thanksgiving. So I'm assuming it'll be quite a quiet one anyway. But yeah, I'll see if other people are interested in participating too. I'll be up for that, Sean, by the way. Okay, excellent. In conversation, I'll be updating the content. I already got the things. I just haven't gotten to it. So I'll be updating a couple of highlights and then I'll be up for participating in the conversation. I wanted to ask, what did you feel about yesterday's Create, the format of having the conversation jump across three people? Was it good or? I haven't actually watched it yet. I missed it. You mentioned something on the Create. I think you will watch the slides then. That's fine. Yeah, I read the slides, but I haven't watched it yet. So yeah. We just split it up into three stages and we each took sections. So how did it feel as you were part of it? It felt natural. I think we were expecting more questions at the end. But that also means that we covered a lot of ground. I don't know. Cool. But it was smooth and we covered pretty much each part very well. So I think it went well. More than three people might get a little bit more hectic. So I guess we have the three of them. Yep, sounds good. The other one is just a really minor item. So throughput labels are a thing. Throughput labels is probably the wrong term. We're tracking throughput as an engineering team. What that means is that we're just literally counting the number of merge requests by team in different categories. There are some questions about how those categories work. So for instance, we don't currently have one for documentation, but we probably should have a separate one as opposed to putting it in backstage or feature or undefined because it's really its own specific thing. But those feed into those charts, which I've linked to, I personally am not going to be using the charts for much initially. I think the idea is to just start tracking it and getting the data and then go from there. But if you create a merge request, just try and make sure you include the plan label, first of all, because I'm not leaving going to see it if it doesn't have the plan label, probably. And one of those throughput labels, if it applies, if you include more than one, that's fine. There's a priority ordering. So community contribution is also a feature. We'll count as a community contribution, for instance. But yeah, there's not really much to say on that right now. I just wanted to, Pedro's asked if it's a small change as a feature proposal. So feature proposal means any positive, I know that's not the right word. Yeah, feature proposal also covers enhancements, I guess, is the best way I would say that. So we're actually considering renaming the label to just feature because feature proposal doesn't really make sense for a merge request as much as an issue. But yeah, we sort of discussed whether we wanted to track that separately from an enhancement. I think we decided we didn't care right now. So what's backstage? Is that like tech debt or? Yeah, backstage is tech debt, but also stuff like, gosh, what's a good example? So I've been using it for things like, say, Yaka makes a change for ethics in E. And she needs to make an equivalent change in C. You could say that's tech debt, but it's not tech debt because we haven't actually accrued any debt yet because we're doing it straight away. But it is a backstage change in the sense that no user will ever notice this change. This is like just work that we have to do that is. So I would have thought that would be another feature proposal or one because the first one was here. I mean, I don't know. So if the e-emerge request is a feature proposal in this case, but Yaka needs to refactor some common code in CE as well, the separate CE merge request. The CE merge request itself isn't really a feature because CE doesn't change behavior. It just changes like its internal structure. That's what we mean by that. Tech debt definitely fits in backstage as well. Just to be clear, the backstage is like a super set of tech debt for things that aren't. So it's very code specific, which I think is the point of this exercise. Yeah, I think essentially it means if the merge request wouldn't have a change log entry, then it's probably backstage. That's a good way to think about it. Because our danger bot. Andrei has asked about multiple team labels on MRs. Yeah, there's a question here in the issue. I've already commented there. Yeah, I wanted to hear more of your thoughts, Sean. I mean, especially because we discussed there, but is there anything else that you want to add? Because I definitely want to have both of us in sync. Yeah, basically what I'm trying to express in that issue is that I don't think we need to care that much. Yeah, if some overlap, it's not going to be that many overlap. Just double turn, it's fine. Yeah, it's probably fine. There are some legitimate cases where things might overlap, and I think that's OK. Maybe if we ever implement label sets where you can only have one of a particular label, maybe if we change these to custom fields, for instance, the team, then that will be an issue. Yeah, this won't be solved until the tool forces it to be. Right, exactly. I don't think we should be wasting spending too much time on the tooling around that that is in the lab, because I think it's kind of an edge case. So yeah, that's all I had. Kushal, over to you. Yeah, so I just wanted to discuss around the design proposals that we have in mind for scrolling the timeline of whole Matthew. I believe it is already under discussion like what approach we want to go through with. But since it is scheduled for 11.6, no matter which approach we go with, like having a button to scroll the timeline or having a scroll bar, it would require back end effort for the both type of design that we approach with. Like it would need to hit API no matter whether we scroll or whether we click on the button. I think that if we go with the button approach where we would click on next or previous just to shift the timeline by the duration that we already have to step ahead or a step behind. In that case, there might not be any back end work needed because the API already has support for query columns for start and finish dates for the epics. But if we do go with the scrolling part, then it will require some effort both from the front end and back end because we would want to assess how much user is scrolling and how much we want to show. Instead of just user basically scrolls a bit and then entire timeline shifts one step back or one step ahead. Just basically wanted to start conversation regarding the UX of how we want to approach this. I think we're leaning away from the infinity scrolling because it's just gonna be really janky when things pop in. On that note though, I am still drowning in discussion regressions. So I haven't had a chance to look at this and I'm out next week for like 10 days. So this wasn't marked as a deliverable. So I wasn't really high on my priority list, but wait, is it? No, okay, thank God. Yeah, label is missing for deliverables, but milestone is set to 11.6, so yeah. Right, I think it's going to be a button, but I don't see the UX being finalized in time for this release. Okay, let's look at, I'll share my screen, why don't we use this time to manage the portfolio management stuff? So... Yeah, we still have a lot of time, so. So this is a great feature. It just goes to this board, if you noticed. So we're doing this, we're going through this, which is great. So I think Kushal is still working, so we're sort of cheating for Kushal and I guess Felipe maybe, where you folks are still focused on portfolio management. So that's the case, for portfolio management, it would be, this one would be highest priority and then going down here. So if we don't get to this one, I think that's fine. And, because we do still have, for example, the promote one, I guess that's only back, I'm remaining right, and I'm just looking at. So Kushal, do we need to rearrange anything or are you gonna run out of things to do, which I never wanted to tell anybody that. So in case we are unable to do this scroll timeline thing for roadmap, what we can do is that either we already have something that needs to be prioritized and find that one, or I can include one of the items from our epic refactor and include in this release because out of the items that I'm covering for 11.6, this one appeared to be the major one earlier today. And you just wanted to have a good handle on the UX because it's a major one, right? That's totally makes sense. So why don't we do this, Kushal? Let's talk about this one in a second and I'll put in our agenda and have that be like the big deliverable even though we want it to be small, like the big one that is crucial. And then this one, the UX is pretty much done, right? It's just copying the UX from the other things and then this UX is done as well. So I wanna leave this here because it's in the list and then when you get to it, let's insert the tech that things, not tech that, yeah, the refactoring thing that you wanted to do. So let's not move this. And then so for Edible, that's the same message for you, right? So this would be the highest priority for UX design. And then I think we talked as they were, you're working on subepics anyway. So don't worry about like getting this ready if you don't get to it. Does that work for you, Edible, as well? So you said that you're away next week, so we're gonna have to make sure. Yeah, that works. Okay. Who's the UX attacking the attached an Epic to an Epic? I didn't see anyone assigned though. That should be Edible. So do you want me to assign to you, Edible? Yeah, sure. Okay. Yeah, and so yeah, let's talk about that right now. So this one is, what did I, oh yeah, promote issue. Okay, so yeah, let's talk about that afterward then. So this one is, the reason I created this one is because we really want to be able to, we already have this, so this is not new. So maybe I should add this to the Epic as well. We've already been talking about of Epics Forever and Edible's been doing a really good job of doing the design and thinking about all the edge cases. So it's ongoing work. The reason why I created this separate issue is we really want to be able to ship something really, the smallest thing as soon as possible so that we can demo it for an analyst and get on a report very soon. So that's why, and these reports are once a year, right? So if we're able to demonstrate, we have functionality essentially for, where this would be falling is if you go back to here, like product categories. And if you look at, if you look at this, which is Agile Portfolio Management, and I don't know where this goes to, okay, this goes to a product page. Okay, so there's a lot of words with no links, right? But then Agile Portfolio Management are supposed to be doing these things. But what really matters at the end of the day is there's like a couple of key features in portfolio management that analysts and customers will mark highly on. And one of them is having multiple layers of things, right? We're calling them Epic, so customers will call them like, or different tools will call them like Epic's features, issues, stories, tasks and stuff like that. But at the end of the day, just having the ability to have multiple levels is what's crucial to us scoring high on this report. And so we want to help the analysts check that checkbox. And so we can't really do that right now. We have Epic's and then issues, so that's maybe like a one layer and then we have tasks under issues, which is like half a layer if you think about it. So it's not really convincing. And so in talking to private marketing and sales, we're saying that or private marketing, John especially asked me like, can we ship something in time for a demo so that we can score high? And so my thought is that we're so close in terms of a design, and we don't need to be able to do the whole thing with the roadmap view, the visualization. Can we just be able to ship the minimal functionality? And even though it's not gonna be really awesome out of the gate and it wasn't gonna be anyways, but the fact that we can have multiple levels, then that would enable those folks to check the checkbox and enable us to demo it. So when we say multiple levels, it's just like an Epic can either be a parent or child, fine. So you can just have two levels of Epic's basically, like this is a parent Epic and it has these children, or this is a child Epic and it has this parent. Would that be fine or am I a bit confused about how many levels we have and how many extra levels we need to get basically? I think the working sort of number I'm using is like five levels because it should be at least one level. Then that's like four. Right. And then the reason I'm coming up with five is pretty arbitrary because three seems reasonable and you wanna have more than three, right? And then like four is an even number and five just like looks like a new one. Like that's what I mean by arbitrary. And I mean five's prime, so it's a better building block. Prime number and it also, if you look back to one of animals earlier designs, again, it's going back to strategic initiative and then feature and then or maybe Epic, right? So strategic initiative is like the CEO thing, right? And then the executive thing and then breaks down into like maybe three, four or four Epics and then those are like departments and then each department might have multiple product managers or project managers and then they build down. So maybe like five. I'm just thinking of like an org chart almost. And so that's where I'm getting five from. And then for this issue specifically, we don't actually need to show those five layers all on one page. We just need to demonstrate that it can be five. So that's why in my proposal here, I'm saying can we just have like the ability to add here? So pretend this is an Epic right in my screenshot here and just to add something. And it's not an issue, you just add an Epic. So you can add an Epic, you click on the Epic, you can also add another Epic. And so when we're demoing it, we're just showing that, oh, look, you can add like five Epics and that's enough. But we don't actually have to show all five, you know, like literally on the same page, it will be nice, but then that's not what's crucial. What's crucial is that we have functionality that you can have five levels. Where are we limiting? Just to be clear around the limiting. So if they are just related, it's fine to do whatever because there's no related, just means related, right? For groups, we limited at 20 nested groups, I think. And I would be reluctant to go above that without testing it because the way we calculate the hierarchy is reasonably efficient, right? But we don't wanna push our luck, essentially. But 20 should be like, I mean, maybe I'm gonna sound like Bill Gates or whatever here, but 20 levels of Epic should be enough for anybody, right? Like. So that's another reason why I'm using just the number five is also to illustrate, because I know there's been on-court conversation about we have to constrain it, we can't be totally crazy. And I don't, I think we should leave it unconstrained from a user perspective. And then Pedro probably disagree with me, that's fine. But then there's all these technical reasons why we shouldn't. So it makes a lot of sense. I told Admiral yesterday or the day before that I think it makes sense because we probably wanna constrain it anyways. So let's, if we're gonna build this here, then we probably need to constrain it because if we don't constrain it and then somebody adds like a hundred and then we take that away from them, then that will be terrible. So we can't do it. So my point being is that this, let's build something that's the smallest thing that is possible. And I think the smallest thing that's possible is just literally just attaching an Epic to an Epic and then having a parent pointer. Maybe you don't even need the parent pointer because in the demo, we're just going one direction. And then, but the unfortunate thing is we probably do need to build in the constraint somehow just to protect ourselves. And that's not for the purpose of the demo or the MDC, but it's the purpose for not giving the people ability to have a hundred levels of Epic. Well, what's the main issue with the 100 levels or more? Well, there's the technical constraint is I think that's the obvious one. Yeah, we don't know how that will perform. We don't know that it will be a disaster, but it seems like risky to assume that it will work fine when we know we had performance issues with subgroups initially. So from a technical perspective, like Victor said, we'd rather not impose that constraint on someone after the fact, but there it is. And even if it's a fairly arbitrary constraint, like if people are hovering for like more than 20 or whatever, or more than five or whatever. It's much easier for us to test that once we've got ourselves in that situation in the first place. But it does mean that like Victor said, we're doing work that we may not need to do, but that's fine because we're iterating. So like- Yeah, that was my point. Okay. And for UI, for UI is also very much more manageable as a first iteration. Right. Well, if we were ever going to show these in like a tree view, you're gonna have to- Yeah, the UI part, that's the part that Victor was hinting at that I have a bit of a strong opinion. Yeah, and so, I mean, like we can argue that's a different thing. Yeah, exactly. So I think the ability, like if you tell me, like Sean, oh, it's fine if they create infinite epics inside of epics, I'm fine with that. Technically, as you said, it might not be the best thing and for numerous reasons, but then the interaction in seeing all of those epics together and encouraging people to have that kind of structure, I think that's the experience problem. Right. And so there's two, at least two points here. So there's two discussion. One discussion is we just have to do a good job of designing this and for, like, I mean, visual design, technical design and like just product design in general. So that is ongoing discussion and, you know, Annabel is leading that from a, you know, UX design perspective. And then we should all support her in, you know, what that is along the way. So that's quote, unquote, one stream of work that's ongoing and that should be high priority because, you know, that's strategic. And then so I see this particular issue as a sub stream of that main stream of work that we need to do as soon as possible. And so that's why I purposely created a separate issue for it. So to highlight that fact and then put on the mouse on 11.6. So the demo is gonna be January 18th, I believe. And so what I've been telling people is that if we do this in 11.6, obviously it will be available on gilab.com and that's great. If we don't have it ready for 11.6 and we do it for 11.7, it will still be available likely if we meet the freeze on time and everything, right? So that's why I put it as high priority 11.6 by one that's informed the team that there is a buffer there but we want to do this as soon as possible. And it's also the reason why, if you look at this, it's sort of inserted in some other things that we said we would want to finish. So that's where we're at. I have a question regarding the epic. Can an epic be, can an epic have two variants? Ha, that's a great question. I just pinged Annabelle and Pedro last night. I have not checked my notifications. Right now the answer is no, currently. Well, no, no, no, no, no, right now the answer is there's no design for it yet. So, but my assumption up to last night was that, was the answer was it shouldn't have more than one parent. I want to challenge my own thinking but I'll let Annabelle and Pedro answer that right now. Oh, I didn't get that. Is it on Slack or was it an issue? I put that in an issue somewhere last night, so. Okay, I'm thinking no, but I need to read the issue. It should only have one parent and multiple children, only one parent. Right, right, like a tree. Exactly like a tree. Yeah. Is there any use case that you were thinking, Andre, that it might be helpful to have multiple parents? No, I was just thinking about in terms of UI whether we'd have one parent or multiple. That was my question. Okay. Thanks. Yeah, so I'm thinking whether I should start branching off to a new topic. Probably not. So I'm on the crazy reason why I think, oh, why can't it have multiple parents? Let me, yeah, let me just go for it because it's like, okay, let's at least figure out, make sure that everybody's comfortable with this because this is important. Like, I mean delivering this. So, like, is everybody comfortable with this from a design and like implementation perspective? Is it reasonable that we can ship something in 1.6 at latest, 11.7? Does that make sense? Yeah, if we're just doing this basic kind of copying of the issues, I could look into something else, but right now that seems reasonable. And like you were talking about a pointer to the parent issue, that's not necessary, but we could just add it in the sidebar like we have that milestone thing and the issue we could add something to the epic. Yeah, like the design-wise, I think it's, we can just reuse that, so that should be obvious, but my thinking was that you could, we can literally recreate this whole box and call them epics and put them right underneath, right? I was thinking either that or just literally do this and you can paste in epic as well, but then we have to like change these words and these counts, which might be messy. So that's my first UX pass at it, so. But yep, that's it. So if that's fine for everybody, I really wanna talk about multiple parents, but I'm gonna control myself and maybe- Oh wait, sorry, just one more thing. Now might not be the time to talk about it, but I think it would be great if we could finalize the UX this release so it could be developed sooner. I mean, I know we have not buffer, but I don't really like to push our luck with that. Yeah, yeah, yeah. So- No, no, of course, yeah, so. I have a few more days once I finish all the regressions and then I'm out for like 10 days and then I come back. Pedro, is there anything specific that you, any opinions you have on this right now or do you wanna think about it? I'm sure you have a lot to- No, I only have one. It's not showing more than one level. That's the only thing. Other than that, you can do whatever you want. We're just doing one level deep at a time, I think. That's the bare minimum MVP show direct child and that's it. Oh, I didn't see that written there. Well, I mean, that's a suggestion at least to keep it as simple as possible. Okay, yeah, yeah. No, if that's what you're thinking, I agree, yeah. I think it needs to just show one because if we start thinking again about like showing the whole tree, then that gets into the broader- The design and discussion. I don't wanna make something and then change it. Yeah, right, right, right, right. Other than that, I don't know. I don't have a strong opinion of above or below. I mean, if we have a box as Victor was suggesting, like maybe have a box of epics below the issues, it might be slightly easier to miss if you already have something like this and you might miss that feature. The same could be said- Put it above. Yeah, or put it above. The same could be said if you turn this box into epics and issues that could also be easy to miss. I don't know, but I don't have a really strong opinion. Is there like budgets? What do you think will the issues, the epic will have more issues or epics? Because if it's less epics than issues, I'll put the epics first, because then it's less of a jump of issues. And the other point I wanted to make in terms of UX is I'm totally fine with one level. I completely agree. From our perspective to implement, I think we just need some guidance on how to show limitation once you're five levels deep or n levels deep. How are we gonna show the user that and add any more there? That's just sort of- Just don't show it. I mean, that'll be a terrible experience. Yeah, just put the limitation 20 levels deep and don't show anything. I never get there. So we can do the box, but then they'll be asking, where's my box? Yeah, I think that's a good- For some groups we just know, right? Right. For starters, that'd be fine. Yeah, I mean, if it's literally just an MVC, and our level of shame is really low or high or whatever direction it's supposed to be, then I think it's fine. Even just sticking a box above or below, I think it's fine because for my purse, to me, that it'll come up with something amazing anyways, and so we're gonna come back and reinvent it anyway. So I don't see it as a huge waste of time or anything like that, the fact that we put that in. Of course, we're gonna have to refactor it later on, but to me, that's not a bad thing because our goal is to show this off to an analyst and have us be on a report. So there's a lot of value in that. That's something new for GitLab, right? But I think there's a lot of value in that. All right, I'll take that. I like your idea of putting the parent epic in the sidebar because that mimics what people could be expecting in terms of the structure. It's unfortunate that it's separate from the child, from the children, but we'll fix it later. That's how I see it. Like, I think. And I see in the future growing that to the depth. So you'll be able to see not just the parent, but you'll be able to see like the five levels up later, like way later. I think I saw that in a mock-up that Annabel showed earlier. So I thought that was really very useful and simple, which is nice. One cool thing that it'll be nice to have if people reach the limit of five, 10, or 20 epics is to send something in the usage ping or something to us. So we know, okay, there was this one instance that reached 20 epics or these 20 instances or 100 instances and so many people are reaching the limit. That could be helpful. For us to understand that maybe 20 is too few epics. We're doing five though, right? We're five, yeah. You keep saying 20 and you're freaking me out. Yeah, I was saying 20 just because, yeah. Let's, it can be five, I don't care. Are we saying five now, as the limit? I think technically it could be more, right? Sean can comment, but I think UX-wise it might be wise to have five because maybe you don't want more than five, like you don't want like 10, right? Because there was also the UX concern about not letting users go crazy, right? So I'm fine if you wanna just set it at five or three, like, no, if you say three, I'll argue with you. But like five, I would not argue. I think that we can, we should let users do what they want, if technically feasible, but the experience should encourage a certain behavior. So like if we designed the experience to encourage having just one or two levels deep, and it's like we're on purpose making it not that easy to have a 100 level deep tree, I think that's already enough. But if users want to go through the trouble of creating 100 epics deep, unless again, I think it's just technical. Okay, yeah, well, I don't wanna drag this too long. So I'll let Annabelle and Pedro fight that out because I was getting from Annabelle before that she wanted, Annabelle, I'll just let you answer. Did you want to like hard not let customers do users more than five, or do you wanna do what Pedro was saying, like encourage not more than five? I think I originally did want to put a limit on it, but that's when I was thinking in terms of sort of stripped agile pyramid style. But I don't think we need to, I'm leaning towards, you know, let them do what they want. But for this, this tiny portion of the whole epic, I think limiting it to five, I quite like that idea because then if we do expand it, then it'll be a good thing. And like you said, if we go down, it would be a catastrophe, I don't know what people would do. Okay, so let's just, let me just update the issue right now. And one more question. Andre said, would you expect an epic to have more epics or issues? I think issues, but was there an answer to that? Would you know, Victor? I would say I agree with Andre. Well, there's no answer. I don't think there's a clear answer because we don't know how people are using this yet. But as a project manager, would you think it would be more issues? Yes. Well, unless it's the, it's the inner nodes of the, if it's the lowest epic, like the leaf epic, then we have a bunch of issues. But if it's the first one, you can have a lot of epics inside and no issues. Right, right. But in that case, that's fine because you should always have epics first, in that case. Right, because that will always work out because if you have a lot of epics, then you'll have like no issues. That you could probably do some interesting statistics. Like if you have a high number of child epics, then the probability of having a high number of issues is low. If I'm just thinking about the tree, literally I'm just thinking about the tree. I think it's a safe bet. So just epics first, right? Okay, I'm just gonna write that in the issues. Or just randomize it every time you refresh the page. I like that. I'm just kidding. Flip a coin. I agree with Andrei, epics first. I'm just not sure and I'll let you Annabel figure out what's the best interaction design if it's to have merged lists, two separate lists, like epics above and issues below. I bet there's some things to explore there. Okay, so I don't know if I have to job in nine minutes and I'm frantically trying to slack somebody. But anyways, I'll move on to the last topic, which is a promo issue to Epic Quick Action. So I just wanted to ask where we're at on status on that issue, because I thought we were actually gonna merge it for 11.5. And so I just wanted to know that if it was blocked or something like that. Yeah, so Yarka and I worked on that one. The front end and back end were done, like the basic functionality of the feature was working, but Yarka figured out like the back end changes that requires an entire promo action to go through were quite complicated and it required some basic largest changes basically, which is why it got set from the release. But again, Yarka would know better what was the blocker which pushed it out of the release. Thanks. And so I'm just- As far as I'm aware, it needed a bunch of changes. Just the exit. The type of thing I was talking about earlier where I need to refactor stuff in the scene. So Yarka is, well, it looks like it was last pushed to like pretty recently, so she's still working on that. Yeah, but I'm clicking through the environment to see she's put something in 24 minutes ago. So that's great, as long as it's not, it's ongoing work. So that- Yeah, it's not stalled. Let's not block by anything, it's just needed more work. That is great. I mean, if you look at our kickoff talk, that was only one that missed the only direction issue that did not get merged. So I think people like Sid and Yoke and Mark care about that. So that's great for the planning that we were able to do every one except one. So I think we had like five or six direction issues. So it's really awesome that we got everyone but one merge. All right, and so I'm gonna go ahead. Yeah, just asking one question. From the previous milestone, we added the possibility to filter by none and any, which one is the new option? Is it the none? They're not new, they're just renamed. It was just like no label before and now it's just NO and E. And then actually there were some cases where I think it was missing. And so there was just some gaps in various places inside Gillab, like search bars and like issue boards and stuff like that. And then a couple of community contributors. I think one of them is a, two of them are core team members, I think. Jacobo and George. Yeah, so I basically reviewed a few of those community contributions. So we introduced any option to milestones. So earlier it wasn't possible to look at the issues which have at least any milestone assigned. So right now, up until then, what you could do is that you could select milestone filter and then select none. And it would show you the list of all the issues which do not have any milestone. But what if you want to look at the list which has milestone assigned, no matter which milestone. So that's where any comes into the picture. So that was the new feature that I did. Cool. Thanks for your show, that makes sense. All right, so anything else we should talk about? I'm gonna stop myself from talking about multiple parents. That's it. All right, I will put this up on YouTube. All right, thank you everybody, bye now. Okay, except wrong.