 So we're talking about sub-epics. So I think Annabelle you responded to at least one of their shoes I didn't look at anything for my this morning yet. So any other things you wanted to start off with before I blabber away? No, I know you talked about possibly having some designs ready and thinking about sub-epics But I don't have designs and the comment I did post was more about how we're structuring this and whether we want To do it the way that we currently haven't set up. So sure you can if you want to go ahead and talk, okay? Yeah, so I'll just motivate the problem a bit and Then and then go from there. So let me Pull up some things Right, okay, so Okay, so this is the Romap we have as opposed to in Slack yesterday Let me just a little bit smaller so maybe easier To see and so we have a we have a lot of things we want to do with portfolio management and the two big areas that in talking with customers and in In what they want Which is really interesting is sort of like it's something that I don't think we ourselves are using a lot or would use is being able to Breakdown work to to Sub sub whatever so so it's called work breakdown structure at least in some areas, right? So you're breaking down the work into a subscopes And so we have the concept of sub-epics and sub-issues and various issues that talk about those things So that that's one area of portfolio management that we could pursue And then the other area is capacity management or or pen planning with capacity and then so I'll talk about why capacity management is not here, but capacity management would be things like you know this month you have 30 points of capacity and then next month you have 35 and then you you store those numbers somewhere and then Get that becomes smart and also tells you that You should really have 40 points or something that based on how you perform in the past and so on and so forth So that's all well and good I Don't know if we would use that ourselves. I pinged a couple of folks I think Sean you said that you would at least use one feature where you put a number on the top of a milestone list board but beyond that Actually when I talked with customers They they also say they want this but they definitely want the work breakdown structure more and so that's why I I've broken that down Not I'm not intended on what sub-epics would be and then some Some I think pretty obvious follow-ups to that So so let's go into sub-epics in detail today But I wanted to mention that that larger context and then in particular Yeah, so there's several ways to break down work and so we're not really reinventing the wheel you can take Issues and have some issues and I think we would use that for at least the product issue in the front and the back end issue So that's an obvious thing that we would use but it's not clear to me how Gillab would use sub-epics. I guess Actually, I would use it myself because you know all Like these would all be under a sub-epic right right now. They're they're separate and then or sorry like these three are Talking about sub-epics so they would be under one epic. So I guess I would use them. So I take that back but Right now at least we're managing it without it and then I don't see us Well, maybe in the future we would use that. I don't know. Let me take that back But for sure I know that large organizations that have a lot of work And they want that visibility rolled up that this is where it's coming from And then so I have these three Epics that I've scoped out and have some high-level functionality to talk about those and then the these these are follow-up functionality Including this one that are pretty that are pretty straightforward like auto close epic is straightforward epic swim lanes and so on and so forth um And then one other exercise that I did That I put in the it's linked here That yobb started asking me to do so it's sort of like um, again, it's not very It's not very, you know new or anything spectacular But this concept of a flow and so if you do, you know, there's a bazillion ways to do Sort of product planning and figure out what features to build And this is one way that people like to do things which is just to Instead of creating just individual features create a flow A potential flow or you know in talking with customers and talking with users figure out how people would use your product and And and figure out a flow. So for example um When I worked in a non-remote company, I did a similar exercise and we had a brainstorming session about What do you do as a flow to get to work? Right? And so it would be radically different now right because it would be wake up rush my teeth eat breakfast Take a you know take public transport or or you know ride a bike take an uber And then maybe if i'm really good I I I would go to the gym At the I had a gym at my at my workplace And then they also had like sort of crappy free breakfast So then the breakfast would be at the workplace So then then you would just like the exercise would be about outlining that flow And then so the flow of going to work and then so once you have that flow and then you look at Which features you you have and you don't have and then you would prioritize certain features And so certain features you would have workarounds, right? So so again the example would be You know, do you really need to brush your teeth? So it depends on your standard and your and your and your hygiene standards So maybe you don't need to brush your teeth because that's okay. And so for some people that's really critical So so you would knock that out as a as a feature not to build And stuff like that. So sort of a silly example, but this flow is trying to capture this Specific scenario um, and then so What I've shown here is, you know, a product manager Creates a high-level ideas turn them into small smaller ideas Works with the various teams to scope out those ideas And then turns it into a roadmap and you execute and you track it. So We have most of that we can do most of that inside good lab But certain things we can do for example is is sub epics or If you wanted to break down High-level ideas into small chunks start scoping out work. We can't do that right now. So that's in this flow. This is a gap Estimating effort we can barely do that Viewing the plan scope and effort And so when you want to plan that type of work inside a board, which I think is is a great way to do it You can't really view it from epic level And so Pedro had this idea to do swim lanes and use epics for that So I think that's a great idea. So so this was something that yoke asked me to do just in general But what's really interesting as I was working through sub epics I had a couple of flows and eventually just became this one big flow And then so everything is more or less all these Future epics are captured in here So it's something that you can look at and ask like why don't we have that? Why don't we don't have a certain thing and so on and so forth? So again back to capacity management that is not here, right? So If you want to plan say across teams, right? So if you have A higher level of planning and you have teams that have less people or more people and you need to borrow team members Or somebody goes on vacation This flow doesn't capture it right because it is Estimate effort and plan scope and effort in milestones accounting for available capacity This is All in here and it's not like you can imagine this in this particular flow You would take this item and break it down further And then account for capacity more using the tool more specifically But it's almost like you need a spreadsheet here to do that right now And it's not accounted for so I wanted to call that out specifically What is not here another thing that's not here is like doing the actual work like that's you know that the create team is more or less involved in that so You view your plan you do your actual work and then you track the progress So doing your actual work is a flow right and so that day-to-day thing or Or even what we're responsible for like using assignee Lists on a board and seeing it day to day what people are working on that's not really here So that's something again that's absent from this flow and we would you know chat about or talk about it and separately So questions on comments on the motivation and high level things before we actually dig into At least what I think would be a good vision for sub-epics None for me Okay, so So so for sub-epics So so let me step back. So we have sub issues and sub-epics. Um, so to me there's um One one interesting issue that Um, I can bring up is is this one so So, uh You can I'll send this issue. Um In some of this discussion, I'll link it in the slack channel So here And so you folks can read it if you care but basically this issue was Mark saying like, oh, why don't we just make epics a sub type of issues, right? And so he said like if we do that then everything will be simpler It would be easier to code blah blah blah and so on and so forth So I think I even mentioned you Sean at some point you so you might have got pinged on this But you probably said like I don't need to answer Um But Did I ping you? Yeah, I did. So, um But basically that go ahead Sean Yeah, no, I was just gonna say I saw it but um, yeah, nothing. I think well You know, it's one of those things where I think It's self-evident I just I just think like, you know, I think you did a great job of responding and like I don't want to like muddy the waters Okay, sure Yep, it's not a problem. So, um This issue I really like this issue, you know, I was annoyed because it's like, oh no I have to answer one of these issues again and justify like our thinking but then I really enjoyed it because it challenged our thinking and it really solidified At least my thinking I want to share with you folks, which is um Yes, we made an epic and we didn't call it an issue a long time ago, right a year ago More than a year ago now and so Did we make a mistake and so so I argue in all these paragraphs here The only mistake that we may might have made is that we might have called an an epic and epic instead of like a group issue Right, so that's the only change that that might have been a bad choice um, but other than that what we did is we created an abstraction at the group level and then as you know, I In speaking with Sean and then I think Yarka was the first person that worked on this, right Sean Um, she said that, you know, all we had to reinvent all these sidebar things. So this benefit. I'm repeating this for benefit of available um For the at the group level because unfortunately when we created issues Or the I guess the issuable type or whatever it's called in code Only applies at the project level and it doesn't apply at the group level. So when we invented epics, we had We're still reinventing all these things at the group level so we have an abstraction at the group level and we have an abstraction at the project level and then so I strongly think that we need these two abstractions. We need these two types of scoping of work at the group level and at the project level um and so we didn't We didn't waste any time because we had to arrive at that anyways We had to do that work and now the next stage beyond that work is at the project level Should we we probably should have a concept of nested A sub grouping of or sub nesting of issues and same at the group level. So group level so again some Nesting of objects for the group level and then we're just going to call them sub epics for now. So if we if we Chose to call them group issues in the beginning We would probably that may have been come easier because then we could have said like group issues versus project issues But now we don't really have to make that difference. So the naming thing is I'm not too worried about that because we can just clearly say oh epics are a group level thing And issues are a project level thing and then that's really clear in the documentation and when we talk with users and in the product And then when we do nesting we do it at the group level and we also do at the project level and we have to connect them obviously And then if you read through this issue, there's this concept about oh, we have epics So should we also have group issues and the answer is probably Probably no because we'll just We don't have to create another object called a group issue. We'll just create an a tier of epics that is At a lower tier. So we have all epic functionality is at the ultimate tier And then if we have certain functionalities we want to bring to lower tiers in the future We'll still call it an epic, but we just won't have all the the high level functionality there So I think everything is still consistent But this is relevant to your point animal, which is How we wanted to do this type of abstraction And so when I look at this picture, which is an awesome picture by the way Oh my goodness that bugs doesn't have text. Um Yeah, did you see sorry? This is a derail. Did you see Stan's Investigation and number of things that needed to be fixed for that. I saw yeah No, but this was like two weeks ago and he was like, oh, this is fix like two libraries Get lab rails and something else. So that's why it's still not I'm not trivial Okay, okay understood. So I'm not complaining. I mean I complain a lot about a lot of things But this is one of the things I can work through Um, so another quick question. What did you use to make this animal? Does you Um, I just use sketch. I don't have Okay, so one of these days I'm gonna learn But before my previous job and and this job I was I was gonna learn sketch, but it didn't happen because it was two weeks Remind me and I'll send you the youtube videos I watched Oh, okay to Yeah, maybe one of these days I've learned it, but um, yeah, this is exactly what I have in my mind like in terms of Substructure and I think what you were saying is that For users if we present to them this side of like a theme and initiative Then it's easier for them to understand is that like I don't want to mischaracterize So why don't I let you jump in and sort of explain what you're trying to communicate here? Yeah, I was trying to wrap my head around just If we just keep on having sub epic under sub epic under sub epic we end up with This hierarchy that doesn't really mean as much as it should. It's not a pyramid anymore. It's just like a straight vertical line Um, so I was just looking at other agile things and I full disclosure I took this pretty much straight from elastian because they have just a ton of documentation um, but I know we don't want to get bogged down with terminology and force users to use this Very specific agile structure But at the same time we talked about how sub isn't a isn't really the correct word to use for sub issues and sub epics But when I see the original design where it just has, you know, your epic page and then it's got a list of epics But you're already on your epic page to me. It looks like is it related? Are they Nested I have no idea. So I think getting the terminology down is is a big part of this and I Yeah, I just I didn't I don't know the use case where you'd need to have like 10 levels of epics because I don't think they're really Ethics anymore if that's the case you basically Created this structure of your own, but yeah, I think that's a really good point because like Obviously we said sub epics isn't the word we want to use anyway, but like the word epic like Is as far as I'm aware comes from the idea of stories and we don't call our issues stories. So there's kind of a confusion there, but like, right You know these themes and initiatives I don't really belong with epics and stories like in a in a terminology sense either, right? Like there's not really a clear conceptual Yeah, yeah namings and I think I think I agree with anabelle that kind of Assuming that this is what anabelle was saying that like punting and just saying You just have like epics nested like groups doesn't really like solve that problem. Like, you know, it just Because there's already ways you can organize epics, right? Like certainly by label If nothing else So Maybe it's like I don't know I just say like, you know, there's we definitely have different Organizational things available to you and I don't know which should be sort of rigid Which should be not rigid. But I think if we have two super flexible ones, we could just use labels Right. So that was the the design I was looking at and I mean, it makes sense because it follows our other guidelines, but it didn't make sense to me looking at it I was wondering if they were related epics Right, right. So A couple of follow-up questions there. So You said it didn't make sense to have like 10 Whatever, right? So do you mean 10 levels or 10 things across or both? Across unlimited. I think every level Is just a collection of their children and you can have unlimited in every single level, right? But that's where it stops like you if you have an epic and you have a sub epic I don't know when that would ever happen Like unless you made a bunch of epics and realized that that's not the right level You actually wanted an initiative and in that case that is kind of complicated. I don't know how you would transfer that but I don't think a sub epic can really I don't think an epic can be in an epic right so Yeah, yeah, so I don't That's why I I agree with what you've drawn here. Well, I mean it's self to me This what you've drawn drawn here is a self-evident In that naming aside this what you've drawn here is self-evident in terms of The use case right so it's self-evident in that you know This make your lab the best project management tool. This could be you know, this could be an okr or you can you know it could just be like This is what the plan team or one of the things that the plan team is working on For you know q3 of law, right and then it's going to be split up into this work and so on so forth So this is work breakdown structure one-on-one. So this is self-evident and and That's it right and so to me the problem is how do we Make a tool that makes it easy for people to Break down the work and to execute it on so you have this vertical structure and then horizontally in time you have to track it So I think we all agree that this Is self-evident and this makes sense So is the concern that is it more of a naming thing? Or is it more of a constraining the structure so that people are more clear on on how to use things I think it's both. I do think naming is important, but okay Having some sort of guidelines instead of just being you know unlimited everything Right because when you go to look at your epics list or something like that it gets very complicated Do you are you looking at all your top level epics or are you looking at just all of them? And then you know depending on how many deep you go and we have this problem with subgroups is all of a sudden you You can't really show The indentation anymore because it's gotten so deep that it's off the page not that that happens a lot, but it's hard to visualize so so I totally agree with that so so that as a illustrative point is that To me it's it's quite obvious that this type of visualization is Instantly more usable than to say this, right? So one could one could argue like oh when we design this why don't we we make the design like this so to me that's That's relevant from a visual design perspective But I don't want that to Confuse our arguments saying like In terms of the the underlying structure for example So so I don't want us to say that oh like this is a bad design so therefore we shouldn't have A nesting structure. Yeah, I think that that's what I'm trying to say like This this like looks really confusing because I created it looks ugly But this looks really clean and great and so to me this is obvious and so we should have some nesting structure So I think we agree there, but then I think where we have to arrive is that okay So if we agree that this is what we want then how do we Design the feature and build it so that we have this level of thing and then so the concern here for me is Related to our discussion last week or two weeks ago with boards is that Do we start saying that now we have an issue? We have an epic we have initiative and then we have a theme right so to me the building that in the complexity of that That seems really crazy, right? So having more constructs inside gitlab that that um More abstractions that are these three things that are first class citizens seems like a law of complexity And so the way I'd like to think of it is that This everything down here or well their issues, right? They're just project level abstractions or getting back to my original discussion And then these things here are group level abstractions, right? and then So I don't have a great answer for you in that like If I were to work on that assumption, then oh, it would be natural to make epics of epics because that's what we already have And that's the iterative thing um And then that would be confusing and then um Or you can imagine a feature where you label it like shan mentioned but instead of using labels You you have some type of um, you know metadata that says like this is at level one This is at level two and or you can have or you can name that particular epic Like in addition to a title, it's like an epic type or something like that just to indicate Theme initiative and epic and then or you can use templates like I talked about with boards last time just to make drive from that This is what we're presenting to the user instead of epics of epics because what i'm hearing is that that doesn't really make sense an epic of an epic So so i'll pause there Um, oh go ahead no you go ahead Um, yeah, I was I was going to say I've actually kind of forgotten what I was going to say, uh Yeah, it doesn't make sense to have epics of epics at least to me. Um And I do see the complexity of Trying to get a user to see that this is like something that you could do without it turning into a full blown Stereotype product where I barely understood that when I had to use it at my old job um, so When you're starting with a bunch of epics like we have right now What's the next step if you realize at some point that you actually need? To group those into an initiative And then possibly group those two initiatives into a theme. How do you Go about doing that. I'm gonna pause because my baby's sleeping. Um, yeah, I kind of agree with that like, you know Fundamentally like, you know So we have issues and we have epics and we have the debate about like what's the difference between issues and epics One difference is that um, you an issue can reference other issues, but it doesn't really contain them whereas an epic explicitly contains Issues Yep But if An epic can contain another epic Can it also contain issues? Can it like, you know Can it only contain epics of a particular level like you just mentioned now victor like that's If these things don't have like concrete names, it's quite hard for me to visualize what that actually means like, um Because I think there are sort of two Two aspects of tension here. So there's the You give everything a name and you have this rigid structure and we don't want to go that far We don't want get lab to enforce your workflow, but we do want it to, you know Suggest a good workflow, right and make it easy. Yeah. Yeah, exactly Um, and then the second is sort of the Jira thing where you can customize Jira to basically do whatever you want um but then You need to have a lot of expertise in the product to understand how to do that because um, you know Things can be structured however you want Like, you know, that's the downside of it. There's the obvious um, like flip side of that from a product perspective and to me um Whatever we're calling these sub epics or parent epics or group issues or whatever we're calling them That's the fundamental problem. I see is that we if we don't have a good name for them It's quite for me personally. It's quite hard to visualize what they mean because um If they're just epics and sub epics like they're just groups and sub groups that just says to me It's an arbitrary thing that you can nest and you can like have an epic containing another epic containing these five issues and then that other The child epic contains like another five issues and another epic and like I don't really I don't really I I get like how that works technically. I just don't really understand what you'd use it for Like, you know, that might actually be easier to build than something else, but I don't I find it quite hard to understand. Um, so I really like Even if we don't actually go with this, I really like this diagram and these names just because then it gives me sort of a Concrete idea of like, okay You'd use that for this and like, you know from issues down from here We have tasks, which I don't know if we're gonna talk about today, but that's also an interesting point to me Yeah, the tasks were my idea for sub issues, which I also don't know that we get the idea. Yeah, we have we have sub we have task lists That's what I assume these were but if there were something else, oh, they weren't actually but I forgot No, I was gonna say I much prefer those like task lists to kind of a Hassle in a lot of weight like from a technical. Yeah, they're not first-class citizen at all Yeah, and I much prefer the idea that these are like these individual issues that are tasks somehow But I don't know exactly how that would work. Um, right. Yeah, that's that's kind of a derail because we sort of It's really I think it's a like it's the same. It's the same question I have the same issue in task. I feel like I understand the relationship a lot better than I do basically so right so so That that's where I'm leaning I'm so to me this What what I'm envisioning is just replacing these words initiative with epic and then this word theme with epic and I think the what you two are saying is that that already is Confusing to users. It's not as user-friendly as we want it to be. Is that a good summary? I'm sorry, which way around is the confusing way around or To me, this is obviously really clear, but I don't like this in the sense that To build initiative initiative and theme that's it takes a lot more work Um, there's a lot more things to to think about it's a more of a feature and so on and so forth Right from a product and technical perspective. I don't think we want to go away and build a completely different thing called That are like epics but behave slightly differently But use a perspective. I think it's quite useful To talk about them in this way so we can exactly have a concrete because I think The word sub epic which I know you said you don't want to use is quite unopinionated But I think this does need to be a bit more opinionated than that basically right for me personally like, you know Annabelle might have the opposite opinion where for her it's like more sensible to just have this um Epic or whatever you call it that can contain stuff and then it's up to you What it contains and how you structure those because that's more flexible to the user like, you know, this is just my my opinion so So so there's a lot there so so what what I was trying to say is that the epic I'm proposing is that these boxes are all Fundamentally the same thing, you know from a product perspective code perspective blah blah perspective So you get all the benefits of flexibility, you know, it's consistent Um, and then we have to be really smart at designing the lines So that we don't make it too complicated and also the lines are designed in such a way that It's makes it a really user-friendly experience So that even though that they're all epics in name Like they're all the same color the shade of turquoise or whatever Um, but immediately when somebody sees this they can they can picture this in their in their brain without the words initiative and theme Or they can, you know fill in the blanks automatically so that um In the sense that in the same sense that when people look at issues they might just call them stories or whatever or or You know, well, actually, no, that's a bad analogy, but but you can even call our issues now tasks, right? Yeah, exactly exactly Exactly. So the same discussion with tasks actually if we if we've called these if we have some issues in the future I would call them still issues, but you just have ui to add additional lines um, and then my contention it's the We need to have super really good design visual design functional design interaction design So that people understand the uh, the structure immediately And they can apply it to the concept of parent-child Relationships and then use it for their specific needs and so same for here parent-child And so my proposal would be that an epic can have any number of children epics and any number of children issues So in my example my generic structure, this line can also go to any number of issues um And you would have pretty much no constraints Maybe it could even go backwards, but I like I always want to Push toward less constraints and allow the user to be able to Do anything they want, but then we build guardrails or templates Maybe we introduce certain constraints Or or we put like error like not like warning messages to say like something like, you know This epic is already pointing to that epic like like or you have like this weird circular relationship and make a warning In the ui rather than to block them So so that's where i'm leaning toward. Um But anyway back back to my point So this would be like issue relationships now except these uh special epic relationships basically like right right Yeah, because we've already talked about this with issue relationships before like we added related issues And we said like in the future we have the possibility to add um You know blocking issues or parent issues or child issues as a type of relationship We haven't done that yet, but you know that was that was always like I think we talked about So your idea is to basically have the same for epic to epic Relationships and each epic can have epic relationships and issue relationships Exactly. Yeah, maybe I should have started with that and it was it was like no no I think I think the conversation actually helped me understand that so I don't know Like how do you feel about that? Yeah, I think I think that makes sense To let people do what they want to do with gate lab It's it's slightly more confusing to have issues and epics on the same level underneath an initiative And i'm still using these words because it's easy, but victor it was your idea to take our existing epic and That would now be or the initiative would be what our epic currently is Yes, so so so the example would be a customer comes to us and say We're on a tool that does blind and they give this They give this PDF to us or I want to implement this PDF and i'm picking a tool and i'm shopping on the market Can good lab do it and then we say yes it can And then we explain to them that you know the best practice within good lab Is that you would implement this box as an epic you would implement this box in the epic and epic And then you would you know create an epic within an epic and and so on and so forth So that's that's how I would This to me is like a a model a work breakdown structure model of what a team wants and then Let's give them an a solution implementation and then it would be Epics of epics and yeah, so maybe I sure as maybe like sub epics in name is confusing But I was totally thinking about relationships But by by having relationships you don't have they're all the same type of object and by default that's more I don't know if it's more confusing but To a certain degree you need You you you can't just like I can imagine a a feature where You have a template and it would be like A new initiative and then you you click that and then it would create for you One epic and it would have like five sub epics Populated and maybe some of the issues would be populated as well Like that that to me is is a way to to address Like how would people use this it's too confusing and stuff like that Yeah, sorry. I'm just trying to think of that one. So are you are you thinking that we would still have unlimited? at Epics so that's where I can be convinced otherwise and you know I would argue with you forever is sort of like emoji and then I'll let you win like 10 the comments But to me that's that's really something that I've worked with Pedro a lot on like To me and this is again, it's to me. It's totally analogous with the The voting up and down on emoji thing or the thumbs up thumbs down like What's wrong with letting somebody put like 10 epics forever like horizontally or vertically like Maybe like we don't need to like like, you know, they're not children They're they're adults and using the software and so I Pedro would be like, oh, no, that's a poor user experience. You shouldn't do that. And so I'm arguing I see the argument both ways, but I'm arguing from the fact that we should trust users to use The the product as sensibly as they would Adding additional constraints is a lot more work from a product perspective it adds more complexity And that even if we were to add constraints In certain situations, I would argue more for it wouldn't be a hard blocker But there would be some type of UI that warns you that you're you're doing it some Place in a in a way that's really crazy and it's not typical We could even say like, you know, this is not the best practice We this blog post or it might break in the future Something like that versus like a hard Like we limit you to 10 sub epics per epic something like that right, I'm not against I'm not and I also wouldn't assume that the users are going to go crazy. Um, definitely horizontally there should be unlimited because that just makes sense vertically I think that just allowing people to do that is going to be more confusing. Um, and you know, having constraints usually is a good thing For the user experience and in life really, but I'm worried that Okay, can you give an example of why that would actually be helpful like well, I think it would help you Think through a little bit before just creating a ton of issues and then ending up in this Just being bogged down by a number of The same sort of just a pile of epics and issues and then you're trying to make those relationships After the fact rather than thinking it through first and again, I'm not saying the users would do that But it'd be a lot easier to get into that state Yeah, so anabelle, I think I think I get what you're coming from when I think I get it. So Can I just use my own analogy to see if I'm just So if I go back to the issue relationships thing, so forget we have epics at all and you just say you have relationships between issues and we have this Child issue thing that I mentioned before So one thing about that was that like, you know, if we just let you add child issues There's no constraint there. You can't have something Be a child issue of two issues But it can always be a child issue of another issue and so you can easily have Cycles or you can just have like a thousand issues in the project each of which is a child issue of the one before and you have this giant chain of like Parent to child to you know to grandchild to great grandchild to whatever it's like a google google developer interview question Yeah, and that's obviously like, you know Like if you ever wanted to so like because the way related issues work is we only display them in At the moment anyway, we only display them in the immediate parent and child context that that's kind of okay And again, we don't have this feature But if we did it this this will be one way we could do it But if we ever wanted to display this in a way that showed you the overall structure We would need to introduce some constraints so that you can't create a construct to the or some some kind of Guard rails like victor mentioned earlier so that you can't just create something that's ridiculous and doesn't display properly Because if it doesn't display properly then your structure probably doesn't make sense, right? Is that Is that uh, am I understanding your concern here correctly? Yeah, yes, exactly. And again, I'm not I'm not not totally against it either. I'm just trying Without doing any actual designs yet. I'm just trying to Think it through and I couldn't easily think of a a page where I could see That kind of structure while I said you have just a vertical chain. Yeah, and I think I I don't you know, I I haven't thought this through enough to know how much weight to put on that But I definitely agree that it's concerned because if we don't have those constraints then It makes adding any visualization like this afterwards really hard Because we don't know that it will even work. We'll have to test a bunch of edge cases Um, you know, we'll probably spend a bunch more time working on those Edge cases down the line on the front end and on the UX side to like, you know, make them display in a sensible way When really we're not sure if those are things that you we want to encourage anyway um, and if those are things that really make sense from a user perspective to to to do Yeah, I think I think there's various shades of gray there that I think we can argue like As we get there individually, um, like design decision one by one like like number of verticals Like how would you address that? um, my extreme opinion Like or a extreme opinion which my may or may not subscribe to is I don't care if they put 10 and like things run off the page Then you're just using the product incorrectly. I'm not going to spend all this time to build All these features to hold your hand So that that's one extreme opinion and probably something that I would be more Uh subscribed to would be like oh after like the sixth one Or whatever like you have some warning text or maybe it like you hide the add button, right after like the seventh one And but you can still add it, but it hides it or something that Jump in there. We do actually have a constraint on subgroups at the moment. Anyway, right 20 or something. Yeah, I heard that somewhere. Yeah But but I don't even think that there's like is there any I never tried myself But is there any ux actually prevents that like Uh, I think it's a like it's at least a back end constraint like it won't let you there's like a banner message It just says error probably if you you just can't create right and like yeah That's just like a peer performance thing. I'm like, yes, then we'll just build it but To me that's That yeah, so so that Yeah, I made my point already This is a very minor technical point, but I'll just mention it now while I'm thinking about it Um, another thing is that subgroups only work on postgres. They don't work on my sequel and if we do Unaffin United's you can nest however you want. It will be the same there for the same reason But that shouldn't be a blocker because um, we are really heavily pushing people to use postgres Um for a bunch of reasons One of which is that supporting true database. This is quite hard a lot of the time Question about that actually you said um subgroups are not supported by My sequel right that would just yep and is So I have no idea how subgroups are implemented But my understanding with related issues and and similar like this would be quote-unquote related ethics Um, but there really be like parent-child relationships. Um Aren't you just storing like pointers in the database? Yeah, so actually let me let me clarify that if if you only want to know So this is like what I was talking about earlier. If you only want to know the immediate parent or child We can do it in both if you want to know the hierarchy um, we need a feature in sub postgres called uh recursive common table expressions, um, which is um Uh, I think my sequel does have something equivalent for it But not on all the versions we support. Anyway, basically it lets you write a recursive SQL query that says like, okay This is a parent of this so you can Keep going up the tree to get parents Okay, so it makes it really easy to to do though to that type of logic Well, I'm performing as well. Um, it's the other thing but so you don't have to do our logic in the app code Yeah, this is this is kind of a slight derail, but the point I was making there was like, um That that basically depends on whether we ever think Whether we ever think you will want to see the whole structure or whether you only want to see The immediate up and down for whatever part of the structure you're looking at and I think Because you know this This image that we've been looking at for like half an hour looks nice to me And I think there is definitely value in being able to see that whole structure at once that way. That's for sure Um, you know, maybe not even the whole structure But certainly a few levels down because maybe you wouldn't want to see all the tasks at this level But maybe you could zoom in or something on A particular thing to go see tasks, but I think there is definitely value in this and if we Work ourselves into a situation where we can only do the up and down immediately view you sort of lose some of that, although From the way you've described it in the issue like the sort of general high level issue where you've talked about the different steps Um, it is very much talking about one step to the next step. So maybe Maybe the idea is that sort of like, you know, I am concerned with like This level the level above the level below right The my manager is concerned with The the three levels like off-set Above that and so on like maybe maybe that does work. I don't know but these are these are just things i'm thinking They're not particularly constructive contributions. Yeah, no, no This is I think this would be next steps and I'd really rely on on our design team to To figure that out. Um, but but the at least, you know, the cursory thing that I thought about was that When you're on a given epic such as this one, you can see everything downstream if that's the right word And you can't see anything above you except the parent And then if you wanted to see things above you you have to go to that parent Um, so that's my design and I don't like that's definitely not going to be the final design There's going to be probably other ways to look at it or so equivalently if you're at this black box You can see everything So this would be an epic if you're in this Dark green box you can see everything down below But you would not be able to see another initiative than this thing or you would just see the pointer to this But you have no visibility to this. So that that's my way of designing it, um You know way that I think is sane and covers most use cases that make sense but But to me just just I think we should in at least hopefully in the next six minutes we can agree on The structure and then we can the next steps will be more about the visual design Which I think drives the functional design in this particular case So so coming back to all that so Annabelle and Sean, I think you're starting to Agree that we we want to implement this or the design will be relationships essentially And these will all both be these three will will still be of the epic of the type epic Is that is that accurate assumption? I think so. Yeah, okay Um, I'm just gonna reserve the right to change my mind. I mean, that's good Because this is being put on youtube so I'm just gonna just gonna put it there But yeah, I think Yeah, I think in general that probably I think what I'm leading to sorry go on. No, sorry our Ethics are a type of issue that aren't they or no, they're not so they're Well, I don't know what they're how they're implemented in detail, but they're just an abstraction at the group level Right, so it's an object that's scoped at the group level. So you so an epic There's no such thing as a project epic. There's only such things as group ethics And within an epic you can attach Any number of issues to that epic provided that those issues their projects are under the structure Nesting structure of that group So if that's even enough that's Yeah, um Like a couple of reasons that they're not issues Basically, it's it's much easier and more sensible to build them At least the decision we made at the time was and I still think this makes sense to build them Adding the features that are like issues rather than removing the features that aren't like issues Because like for instance, you can't have a merge request close an epic. For instance That doesn't really make sense You can't have a branch related to an epic because an epic doesn't live in a project and there are group level repositories You can't spend time on an epic. You can only spend time on issues There's a there's a bunch of like small features where it's much easier Conceptually to like add the ones we want rather than remove the ones we don't want because it's very easy to miss out the ones We don't want okay That's not to say that we couldn't make them exactly like group issues if we decide that that's the way to go It would just require some quite a bit of free work Okay, I think I thought that just because they look almost exactly the same which is a good probably good thing So in that case, I do think that the three levels in this diagram I don't know why i'm pointing the three levels in this diagram above the issues are All types of epics that makes okay to me Right. So yeah, that's my proposal like we We're inventing these lines, but we're not inventing new boxes. It's my proposal in that show Yeah, I like that way of putting it I also think that we should consider constraints on what the lines can do I'm like, I'm pretty sure you studied math at some point right victor At some point. Yeah, I don't I don't think this should just be a graph. I think this should be a directed graph A dag Yeah Well, I mean that that that that comes back to the the the thing that we talked about earlier like the the warning things and like to me If there's a technical reason to to maintain that it's a sick like directed Then obviously we do it, but to me there's no convincing user reason and then Right now, but you know Annabelle will probably have one and so then I'll be convinced but that's I don't want to create things for the sake of creating them until it's it's clear we need to do it because yeah We can definitely talk about that but basically when I say directed Annabelle. I mean that like so You have an epic this line goes in one direction that line goes down that line goes down that line then can't go back up Like, you know to another epic that's part of that one like, you know, you can't just sort of go Whatever direction you want you can only go in one direction, right? So from the bottom up everything only belongs to one parent Can have many children, but each child only has one Yes, but also the line only goes up um One level at a time if that makes sense So you're saying an initiative can't have a bunch of issues and ethics Not exactly. It would probably be easiest if I draw a diagram. Hang on give me a sec In the shirt on the screen I was just going to draw it on a piece of paper Doesn't zoom have some thing probably yeah So I think China saying this You can see this right Annabelle. Yeah, okay. Oh, yes. Yeah, exactly that. So there's an arrow on each line which means that um So can you see that? Okay barely Okay, fine Yeah, basically basically what I'm saying is you can't have an arrow going up Well, you can't have an arrow from this epic from inherent sub epics going to theme, right? Right. So what I'm saying is Um, but even if there was a different even if there's another initiative, right? So like inherit sub epic start and due dates Can't have a child epic of another initiative Because it's a different level other because I can only have one parent. Yeah, I think That's already told by that. Yeah, that constraint already satisfies that. Yeah, but but even that like I what I I put pretty much those two A constraints which I think covers everything like having only one parent and having a number of children Um, I I put those constraints in one of the I think in the back end issue but even that I think I could argue could be relaxed if it it's easier to Do so I think that's something that we can talk more specifically during implementation Uh, yeah, I think I think this conversation comes closer to implementation that we need now But now I just think the the design is that we need some constraints on here. It's not a complete free for all right, right, right Yeah, but but again my my point being is that That can be design led. Yeah, exactly the design should drive the the implementation The design led but then performance reasons like you like my sequel blah blah blah that will also back inform it. Um, so So going forward as I start Trying to make a design for this Is there a word that we would like to use to avoid more confusion for these different levels Like should I be doing theme initiative epic issues? Or do we just want everything to become a sub epic? I think it should everything should become a sub epic if we're if we agreed I mean you can disagree, but if we agree all these boxes should be epics um I'm just using the word sub epics. Maybe I could rename everything and just call them epic relationships or parent child relationship Epics and that's a mouth. Yeah, I kind of like epic relationships more Like an epic like in this example an initiative is both a sub epic and an epic Hmm. Okay. Okay So I kind of like the idea of just focusing on the relationships, but I Don't know if that's going to be super clear once we try and explain it to people Okay, well, let's call it Let's call it sub epic stand just because other people won't understand it. I think you're right If you don't mind we could always we could always come up with a couple of ways of explaining See if like, you know, any okay, then let's let's do something crazy. We can always change this skin lab That's just I'm just gonna after this call. I'm just gonna hang up and I'm just gonna rename every At least titles. I'm not going to go into the bodies of issues because it's gonna take me forever I'm just gonna go to all the epics and and issues I have regarding this and just change it to call them relationships And then that's it or maybe call it parent child relationship Because apparently it wasn't obvious to you too and that's that's a failure in communication already and then and then we'll go from there and then But for for animal, I think what you can do is just work on visual designs and interaction designs With the assumption that we're not creating new objects in psyche lab There's still all going to be epics, right? There's this going to be epic page and that's it But how will that how did how are things visualized there whether it's on the roadmap whether it's on the epic page Whether it's on an issue where you can point to the parent so on and so forth That I think is all up to you on how you want to do that Okay, um, and there was still an order, right like road maps was was sort of more in the future. Yes, um and Yeah, yeah, definitely in terms of priority, but I mean None of this we were shipping tomorrow either. So Um, but what I I'd like to start on on this work fairly soon like the next iteration But but you're totally right Like like to me I think the the next time we have a discussion if you have some designs on like the epic page and then just rough ideas on the Roadmap page. I think that would be great. Maybe so let me take that back just the epic page. I think would be great because um I really like this visualization. So I'll shut up after saying this point. I really oh my god, this red I really hate Because it just looks ugly. But to me, it's it's I guess it's useful. So maybe you'll come up something that actually does look like this Um, I think Dmitri created this one Oh my god, I can't undo it. Yeah. His design does look like the one that you think sort of have right. Yeah So this one Dmitri created but this was without sub like without thinking relationships. This was just one level, right? That was not in mind when we created. No, it was actually I take that back. Um So this is epic of epic, but I don't think Dmitri thought a lot about, you know, further nesting and how that would be articulated the breakdown structure But go ahead and think about that go ahead and think about whether an epic should be allowed to have both In this case sub-epics and issues. I I think it we should allow it But maybe you have some convincing design reason to disallow it. So and so let's chat about that next time All right, anything else from Sean animal No All right, um, I will stop