 It started on the first point. So I wanted to bring this up of something that I wanted to do. So with all things, it's a proposal, in my opinion, until we start developing it, right? So I have all these plans in place, but I'll move quickly to put these things in. But then people should be welcome to challenge it. But we're also not going to wait for anybody. So one thing in particular is value stream management. So it's sort of this cryptic thing that we haven't really been able to define very well. And so, but at least Hannibal did a good job sketching out one design and concept for the September 20th event that Mark Fuensack proposed. So if you still don't know what VSM is, that's a good place to start. And so essentially, we had a couple ideas there. We said that we wanted to track the time that you would be within a certain stage, right? So if you're in the in-dev stage or in the in-QA stage or in UAT stage, how long does it take for somebody to be in one of those stages? So what are the statistics? What is the average of that per team? What is the worst time and the best time and so on and so forth? So I wanted to mention that initially our thinking was that, OK, let's continue to use the Issue Board, because we have the Issue Board. We have that. And then we have labels represent workflow stages. And we have labels represent a lot of things. So we've ran into a lot of trouble in the past with labels representing stages. And the original thinking, like half a year ago, said, OK, that's fine. We're going to charge ahead. And we're going to use labels to still represent stages. And we're going to build VSM on top of it. And we also did some upcoming work, which is label tracking events to help with that. The past couple of weeks, I've been thinking that if we continue to do that, it's going to be very messy, because not only are labels representing stages now. And I mean, they are doing that right now. But if you look at GitLab, labels representing stages are limited to an Issue Board, but nothing else. We don't build on top of that understanding. That understanding is there, but we don't build on top of that. So if we build on top of that and have the expectation, if you think about all the designs and all the things that come after that, it's going to get a lot messy, because sometimes labels don't represent a stage, and you have to account for that. And so I saw an opportunity for an idea is we already want to do enforced workflows per group as a separate concept. And so we wanted to say, sort of like approvals, like you have a whip, and then you have approved by whoever in a merge request, and then that blocks it to getting merged. So that workflow stage you're gating is something customers have been asking forever. It's something that JIRA supports. And then I'll let Sean go to his point in a second. But it's something that clearly the market wants. It's something that we scoped out that we want earlier. So I thought, why don't we build BSM on top of that, since we need that feature anyways? And if we do that, that's going to be a lot easier to build BSM on top of. So in particular, what I'm suggesting is a letter C, we have enforced workflows per group. So at a group level, you would say that every issue goes through INDEV and QA and UAT, and then closed. And then there's some details there that I put on that topic or issue. And if that's at the group level, you have a board which can inherit. So you can have a special type of board which uses that enforced workflow automatically. And then once you have that, then you can build BSM on top of that very easily, because you have stages or states. I call them stages for a particular reason. And then you can build BSM on top of that. And then my last point before I'll let everybody jump in is that my concept right now of enforced workflows is that we're not going to introduce additional states. So we're always going to have two states. It's going to be open and closed. And the reason we want to do that is we don't want to break GitLab. We don't want to take like 10 months building code that will take forever to be released. But my proposal is that within the open state, you have multiple stages. So even if and then those stages are customizable per group. And so even if we release the first feature, which is literally just transition issue from one stage to another stage, but still within the open state, all your features in GitLab will still work, because every issue will still have an open state versus a closed state. And that is still clearly well-defined. And this is on top of the existing open. So I'll stop there. Shana has a point, but anybody can feel free to jump in on anything. So I mean, if Sean wrote to me first, I guess he gets first steps. He already answered my point, I think. So that's good. OK. So at GitLab, we dog food a lot. We don't dog food everything. We don't dog food LLAP, for instance. We don't dog food Elasticsearch at the moment, like we've discussed. There's a bunch of specific features that we also don't need. That's a difference. We don't dog food. There's a bunch of stuff we don't dog food. A bunch of reasons. Yeah. Would do you see us as wanting enforced workflows, or this just being more fair, more bigger enterprise-type customers? I can definitely see us. So that's a great question, Sean. I always find it, I love being on the plan team, because it's so easy to build things, because I don't have to worry that nobody's going to use it. And so I always think about this point. And so this in particular, I think we can at least use the version that is not that restrictive. And so for example, you can imagine our first version, you have all the stages, but then there's no restriction that, this is one idea. I don't know if we will build this. I don't know if you would have multiple stages. In general terms, you would have the states, but everyone will be able to transition to every other one. So in general, you have to do transitions. Exactly, so that's what we're going to do. Yeah, and the enforced workflow thing is you can say, OK, from in Dev, you can only go to in review, or you can go back to not started, but you can't go straight to UAT. Or you can go straight to UAT maybe. But in Jerry, you can configure all that. So OK, so your idea is that we would probably maybe use the states like we do with the in Dev and in review labels, but we wouldn't enforce the transitions between those for ourselves. There's a couple of ways I can think of it, because if we don't enforce it, and then we build a feature later that requires enforcing, that's additional configuration and that might be a bad idea. How I can envision one way that we get around this ourselves when we use it is that our first feature, it's going to be linear transitions only. So you can jump around and have that stupid graph that Jerry does, but we might need it in the future. So I guess it's not stupid, but you can jump to a later stage, but that's essentially GitLab clicking five times for you. So you can drag it over, but then GitLab just and instantaneously, it's moving through in Dev and QA in UAT for you automatically. So that's a different way around that as well. And then, so for example, the closes, I thought about how merge request closes an issue automatically. We obviously don't want to break that, at least as a first release. We don't want to change any of our internal processes. So maybe that would still work and you need to have the right permissions or something like that. So I haven't gotten a lot of, I haven't thought in detail about that yet. Oh yeah, but that was the thing that I really hate about this thing with JIRA is that you could set permissions on who could move things into each state, which sounds good because it gives you control. But if you only let the QA team, for instance, move it into the out of QA state and they're not available, then you're kind of stuck. And it might be something that doesn't actually need QA because it is, for instance, a change log. So yeah. Well, then like a big enterprise would say then your requirements should have a checkbox that says it doesn't need QA, right? So like, we can go on. You have to do it. Yes, exactly. That's what JIRA is. Just if anybody here hasn't used JIRA, that's how you do JIRA. Exactly, so that's how we have to be really, so I think we have to be doubly smart here. Like we can't reinvent JIRA, but at the same time, or not, and also we have to invent it in a way that we can use it because we want to keep using our own software as much as we can. So I think, but I don't see any inherent fundamental philosophical blockers to anything I've proposed yet. So I think all these things can be designed correctly. But those are super valid concerns that I was thinking about as well. So thanks for bringing those up. Thanks for summarizing, because I'm not going to type it. Other, oh, how is JIRA? If we're not enforcing the transitions, I don't understand what this is about then. So there's the enforcing the transition and then there's logging the transitions, right? So both are important from like a enterprise-y thing. So enforcing the transition is exactly like Sean said, like roles and permission, enforcing transitions, you're not allowed to get passed. And then the logging the transitions, both are a way to incent behavior or correct behavior, right? So if everything is logged, right, then you're still responsible or the actions you take are laid for everybody to see. And therefore you would be incented not to do something incorrect, right? So I can see a mode of that or I can see a version of that where as a developer, right? Or we have that right now in GitLab, everything we do has most or more or less as a system though, and everybody can see what you did. Like I mistakenly moved something from an issue that Brett Arner-Tum was working on and he got really pissed off, rightfully so. So then like everybody can see in the future that like Victor screwed up there. And so that would be an example of how not enforcing it could go. And then even within enforcing, like I said, you can have the really tight version that Shaum is alluding to, which is to get out of the QA stage only QA role can do. So that's one version. Another version is or less strict version that you just have to go through all the stages step by step and then, but like anybody can do that. So what I'm asking is if we're not doing the enforcing of transitions, we're just enforcing a specific workflow. How, then you can still see the timestamps of every one of those things happening, right? There's still a lot of them there. Exactly, so we already have that today and we're doing the events thing for changing labels. And a person can already create a board with the workflow that they want. And so it's just dragging and dropping and you can jump from one stage to the other or from the first one to the last one. So I don't understand. No, you're right. I think you're right. Yeah, I think, yeah. The enforcing of transitions? Yeah. Well, I think, I think. What are we doing differently? Or maybe it's the experience that you want to be different? No, no, I think you're right, Pedro, because we can, the experience would be a nice to have, but in talking with customers they don't, they wouldn't think what I just said is sufficient. They would definitely want what you said. Definitely that enforcement. So we have to like figure out what that is. Is that gonna be permissions? But something a little bit tighter. There's probably something in between. I can't think of something, I can't think of something I'll have to tell in detail right now, but I don't wanna necessarily build in new roles right now. We can definitely use our existing roles to do it, but I don't wanna build in new roles because there's a bazillion reasons why we don't wanna do that. And so we don't wanna add yet another reason to do that. Yeah, so basically, we already do everything that is needed except the rules, except enforcing that of whatever specific work for the company has. Like this person can only move from this stage to that stage or it has to stay this amount of time and that's the, I don't know, crazy rules, right? And that is what JIRA has. Not saying that we should do it exactly like JIRA has that functionality and maybe that's what people want. Right. So just to understand, so if we take out the enforcing of the transitions and the rules, we already have everything they need, right? But the experience gap is still there though, right? The experience gap, like nobody, that the experience gap is still there. So it's not as great, but I'm pretty sure, not pretty sure, like I'm 100% sure some companies are doing that and saying that I want enforced workflows, but right now I have, they're using stages on a board and then it's not a great experience and they would love to have enforced workflows. Okay. And have you heard this from customers that are not using boards? Or is it only from people that are using boards and they are not? I don't know. Yeah, I don't know the answer to that specifically. Are you saying that, are there anybody not using boards because we don't have enforced workflows, right? Or we don't, yeah, like we don't have this type. Or maybe they don't know about boards or they don't have not looked at boards in a way that allows them to do that. Maybe they just went to a board, it was empty and they're like, oh, I don't know what this is for. So let me go back to the issue and see if they have any control, like change to status or change to stage. And we don't have that. And maybe they were disappointed because of that. Yeah, no, it's hard to know that because that's like arguing from nothingness, but for sure, for the opposite is that like they do find these features. And for, I haven't had a customer come to me and say, I wanna do a workflow board, like can GitLab do that? Like customers have asked that, but it's like they just haven't used GitLab before. But any customer that's already using GitLab and wants to know that feature is always using that feature whenever they come to me as a customer, like in a sales car or something, that they already have it. And it's always like one customer had, it was crazy, they had a product board and an engineering board. So the product folks would move things through and I guess designers, I don't know if they had designers, but they would move things through and then they wanted to copy that issue. And then they wanted like, are copying thing is not good enough? And they would just not copy, sorry, they would move an issue from that project, the product project or group or whatever it was, I forget, to then engineering equivalent and then it would transition through their board. And I was telling them, no, no, no, that's crazy, just have one friggin board or just have one project or one group and then have one single source of truth issue. So that project can do boards or one board. Exactly, so that's usually, that's more characteristic of where we need to improve of just making the experience easier. Yeah, that's what I, yeah, not the discoverability of the future itself. And maybe it's both, right? So, and that's what I want to understand is, is the problem like people look at boards and they don't understand how that can help them do workflows or is it the other way around and some people don't even know about boards and maybe we need to service that better inside of an issue page, for example. Right, right, right. And because they're looking at the issue, they're going to close the issue or I don't know, they're looking to move the issue. I don't know, somehow we need to see what are the hints of someone going to move an issue to another stage. Exactly, and once it's, yeah, exactly. Once it's a stage, a proper stage and not part of a board or a label, then it's a lot easier to handle. Like, exactly you said, like, people have been asking forever, I want to know the board stage on an issue or I want to move an issue to another board stage while on the issue and like we can do that but not really right now and the reason is because it's hacky, right? So, I had an issue a while back that says that workflow stages should be scoped to a board but when I thought about it like last week it didn't make sense at all, it should be scoped to a group and then the board should inherit that automatically. And then so once you have that then it's all consistent across. So that's yet another reason we, this will help. Fatih, which thing were you cringing at? There's so many things we talked about. The last one you're talking about, you know, having the boards and moving the issues around that one. Okay, okay, okay, good, good, good. I didn't know if you just didn't like the concept of enforced workflows in general. So, I think, I think your lab in general is warming up to more structure and enterprisey things as we scale, but we still have to be super careful like about this thing. Yes, the cloning of the issues was particularly mouth opening but one of the things I wanna mention now at this point picture is that when you talk about inheriting this sort of stages into the boards one of the things that I didn't see in this issues highlighted is that idea of having a board created just as we have now with assignee's list or milestones list or whatever and still being able to distinguish the stage of the issues that they're in. I see that the group board with enforced workflow will basically enforce the workflow throughout the board. Imagine a plan board where I have like all the assignee lists that have their issues and one of the things that we discussed past I don't know if it was in particular about swim lanes or not but having basic transition to the bottom part of the board because it's already in review that sort of thing. Yeah, I don't think it's covered. Is it on this bulk of work? Yeah, definitely this is what I've sketched out is definitely a thin slice here. And if you look at like EFG then forced workflow is a stepping stone to get VSN, right? So like I said earlier, there's definitely a market need like there's like a whole VSN, a Forrester thing that we did okay with so that's why it's on our homepage but definitely that's like a driving point here. And like when I showed this to Yope he agrees with it like we wanna move fast but we wanna still build like solid foundation. So as I thought about this more I was fairly convinced that if we build VSN per original plans it's gonna be really messy. So I think at least my boss would be okay with us taking time to build the enforced workflows to a point where it's good enough that we can build VSN but like what is that line? How good does that enforced workflow have to be? And then one of the things that Andre I think you're exactly saying is that if you have an enforced workflow board by definition it's more powerful but maybe you don't have the mixed board functionality you don't have that anymore or it's harder to do a sign-in list and stuff. So you use that type of functionality but like again if I were to design in 30 seconds yes I would just add that additional dimensionality which is swim lanes the horizontal dimensionality you could use that to have a sign-e's or even mouse ones would be crazy but even labels right you can have labels board into multiple labels. So I think that would be that's possible but like I think it would be interesting if and when we released enforced workflows it would be a different board type at least how I envision it right now but it will be like almost like I don't know if like we wouldn't definitely wouldn't say market it as it's just a step back where we say it's something different which it is we would be- I see it as a, sorry to interrupt but marginally related but different scope effort which was more about the swim lanes than the enforced workflow. However, we will inherit that information and the stages that will be used on that scope. So yeah. Yeah and then the other thing as I thought about that particular point more is as you, so I should do a better job of writing these things down. So the great thing about that is say you're a team like you're the plan team right and then you can still have so maybe we'll have views or maybe we'll still have multiple boards when we're doing this we're gonna still have like a back-end board a front-end board and a sign-e board that has both back-end and front-end folks and then we'll have a different board just for the workflow stages. So from that perspective I'm really excited because like how we've designed boards up to now it's still flexible so you don't lose all that functionality right? So you're using GitLab Ultimate you can create all if you're using GitLab Premium you can, okay so if you're just using GitLab starter you can have multiple boards and one of those boards would be workflow boards with labels then use GitLab Premium then you can start using a sign-e list and milestone lists then use GitLab Ultimate then you throw out your workflow board with labels and you replace it with a workflow board using stages right? So that I think again that's all consistent and that's how we would use it I imagine and so I'm excited that it's not like we're switching to this other mode and then like all the other things that we're using on a team-based level would have to be reset we're just asking for a customer to say oh before you had like workflows and labels now you're always gonna say like build an importer or an upgrade path where you take those workflow labels and you turn them into like custom stages right? And then you would have a board and then that would just work like he's gonna say you need that for adoption which I'm gonna agree and cringe but yeah so that I think that those use cases will still be there so I think that's great but very good point and then what did I wanna say last? Oh yeah so with the swim lanes how I've sort of reserved that right now or like how that would be super useful is if you look at letter G sorry not letter G a letter F so that's a concept that Anibal put together with a lot of direction from Mark and so the concept there is that there's an active state and idle state there so this is still really really just me thinking in a cave so it needs a lot more collaboration to nail this down but the concept here is that in VSM we really wanna identify whether a issue is idle or active or not an issue but just at the end of your iteration at the end of your quarter and then you're like Tommy right who's Sean's boss right now and then Tommy and then there's also Dowey and stuff like that and he wants to see like across all the teams are as a roll up like how are the teams doing are all the teams stuck in in Dev and inside in Dev or in QA and then within that stage is there a lot of idle time there is people actually like doing active work or are they always blocked and then we're doing too many things at once so this would be super helpful to characterize that and so my first concept is that you just simply say that an issue if there's no activity an issue then it just becomes idle and then in the database you just log one day that that's idle there and then that's all you do and then visually on the board it just drops down to that second swimway so that is my awesome idea that's not really mine at all I think it's pretty much Mark's idea he created an issue way back when but that's the that's as I was talking about like yes enforced work flows is not too exciting or is exciting but really the main goal is to really bring this to the VSM land of getting this type of metric and process of having more visibility so that's how I was envisioning using the swimway so if we do that then how do you add more swimways for labels I have no idea like do we not let people do that so that can get pretty hairy really quickly so maybe we need like a third dimension like 3D chess and Star Trek I don't know how that will go I think this might work with with labels still it just needs to be a different board because here what we're doing so if you remember like that discussion that we had initially about swim lanes and there could be a lot of things that we could do with a sine swim lanes with labels swim lanes and one of the examples I gave at the time was so you had the workflow columns and then you could have like in our case for example two or three swim lanes which could be for example two, 20 seconds and then like the catch all swim lane everything else or deliverable and then stretch and you had those swim lanes but I think if you try to put all of that together with also the if it's idle or not right right over complicates because you are also then mixing the fact that like each column might also be associated with a different role right and so I like this design in terms of having swim lanes to say what is active what is idle and I think that we can piggyback on I don't know about the automatic logic of what you were saying like that's definitely the amount of time it changes but let's imagine that the active and the idle swim lanes are actually labels and each time that's for example it's in dev and now you want to pass it on to QA what you would do you go into the board and you would drag that card from in dev active to in QA idle right right because if you pass it to in QA it's automatically or most of that until someone picks it up and then when someone picks it up they would put active and then from in QA to in UAT they would go to idle in UAT and so it will be like a zigzagging pattern I can see a variety of I don't want to get too much in detail but you're totally right Pedro like there's so many concerns there one of them I had my initial design here is based on I don't want to introduce a new state and I just want to like that's super exposed to the user and because the main reason is because that this idle and active is more for after the fact analysis and less so for like operationally you're looking at what's idle and active because you don't really care right now right you just care that there's something to work on and you're gonna work on it and then but I think what you're getting at is that that reflects more reality and what you propose you could actually like measure to the minute and so I'm arguing that you don't need that but maybe that's more natural so that's why I don't want to disagree or agree with you and maybe the first step that allows us to be flexible as well is just to not have those fixed active and idle swim lanes but just allow people to add as many label swim lanes as they want right right they could use that for priority they could use that for activity like active idle or anything else that they want basically it's just a matrix right you're seeing right you're trying to compare that with another level of information sure so I think for the first step just right off the bat I would say that labels could be label swim lanes could be a good thing but I don't know we still have to look at it yeah we have to figure out yeah I know swim I love swim lanes because there's another dimensionality there's vertical with less horizontal with swim lanes there's board config which is saved to the board and then there's the search which is in the search bar so there's essentially four dimensions per board which is amazing and then if you have multiple board views per one quote unquote board that's like a fifth dimension so you can do a lot there from a design perspective I think what were you thinking and of all when you were working on this for the vision which concerns did you have about this yeah I don't know where the actual design went on the issue but I was throwing away everything basically it was just you know here are the stages that you can go through with with any given issue and it followed basically the example and you know dev qa uat deployed that kind of stuff and then the swim lanes were only two idle and active it's exactly what you said so it's kind of it's basically assuming that you're going to have one board that is this enforced workflow and then other boards for everything else so you can't really do a signee I mean you know you can't really do a signee lanes or anything like that for what I was thinking so I'm not sure yet yeah yeah the signee swim lanes would be a different thing but do you think so when you were designing this like looking at those two swim lanes did you initially thought it would be okay to have this in a fixed manner or or didn't you give it much much thought it was just to get out the division quickly yeah it was just for the demo but what do you mean by fixed fixed in the sense of like being not necessarily a type of board but like we give this to you like GitLab we build this kind of board where you have the active and idle swim lanes and that's it you cannot do any configuration and they're not labeled they're not like they're not anything we're not relying on anything that already exists we're creating this new paradigm out of a fixed sense of active and idle instead of allowing users to build their swim lanes I was kind of under the impression that it wouldn't be a true issue board and this would be really value stream management alone so you'd have your issue boards with whatever configuration you want for milestones assignees that kind of stuff and then this would be vsm and then idle and active act like labels but they're not really labels in that in my head I was thinking it would be completely automated so you're not you are zigzagging in a way but you're not dragging it because you don't really know when it's idle that would kind of throw off the whole point of tracking how much idle time and active time there was so I was thinking the user or the owner of the whole group would would set sort of or use time tracking or something to display how much time it should an issue should take in each stage and then depending on not so much the activity in the issue but how long it's been in that stage it would start moving automatically this is not for first iteration in any way and I'm not really sure how this would happen but that was in my head so yeah this was just kind of its own board and it was just for the demo so I didn't really think of all the cases or any of them actually yeah I think one thing and correct me if I'm wrong Victor but I think one idea or the way I look at this in terms of like vsm and issue boards and it's like vsm is I didn't think of it of like even maybe having that name somewhere in the interface and in the product it would be like we do vsm in the same way that we say oh we do agile or we do scrum yeah that's that's right I always thought of it like it's a yeah it's a category or solution we have to figure that out product marketing is something yeah we have a we have a page it's slash bsm and we have slash forester dash bsm it's our lessons learned from engagement with forester but you're right like I don't see us having that anywhere but yeah no no I I echo what when I was putting this together at least my version I was thinking along the same lines as edible like the the idle and active are automated dragging between stages I think Mark said oh I was thinking that it should be automated again I agree it should be automated but then we probably can't automate it yeah we can automate everything and like we're not going to have merge requests on a board anytime soon and maybe we do I don't know how that would work but um there's gotta in my opinion there's always going to be room for some manual dragging on a board yeah definitely and and just to get into specifics that the automated part some of it was more obvious like if you've got a related merge request that is work in progress and then you move work in progress then it would move to you know review or whatever that next stage would be and then it would there be some sort of hook that would tell if it was deployed to staging and then it would move to the next stage um but some of them would definitely need to be manual cool thank you all right so we have 15 minutes left I don't want to take too long but um but yeah so everybody please dig into the epics and issues and participate I temporarily put this at like if you look at the first epic like actually pretty soon so we'll figure out how this rolls out but um I think we have to solve enforced workflows per group we have to do uh custom fields as well and so that's another epic um so so those are sort of the big areas where it's very enterprisey and we have a label called governance that I've been using and it's like a very enterprisey word and not everybody might like it so I didn't come up the word it's and it's on the homepage of gilab about dot gilab dot com it's one of our three words at the bottoms so it says like governed and something else and something else so it's a it's a it's a word product marketing uh what's the use um so I'm using it and it's also I think is it is I think it's also one of the categories that we were evaluated on on the vsm forester wave thingy so it's consistent there so anyways um uh so this is gonna be coming up pretty soon but for the rest of the year we should be focused on uh what yob calls boring things which is pretty funny because like everything we're doing is boring until it's not um so boring things in in the sense that really obvious features that like ui polish and debt in terms of features that that we don't have yet so so these are things upcoming but really quickly um two a notifications and to do is anvil you said that you haven't gotten chances to start working on this yet so um and so and while you're also working on epic relationships I don't want to have you like over over uh overworked or whatever so well what are you focused on right now yeah I am working on epic relationships although I haven't done anything since the last meeting really when I presented those designs so I'm not really sure what the next step is with that okay so so I think last time we said that we wanted to do the have some views for the the roadmap view so are you planning to work on that oh yeah that's what it was yeah okay so do you want to jump on that first before doing to do some notifications or like I think both are important so I don't have too much of a preference but it's I'll probably start the roadmap because that ties in more directly with epic relationships okay um I also just wanted to give you a heads up that I talked to Clement earlier and he's got some plans for a CSS lab this release so technically I think I'm kind of 50% on that okay so 11-5 right uh what are we about to release 11-4 wait we're we're gonna release 11-4 in uh 19 no I can't do math okay but we're starting 11-5 development um but I also don't know the CSS lab thing is is not part of the repo of CE and EE right so is it separate or is it is it is separate but I think we're trying to follow the same sort of really so yeah 11-5 okay okay yeah just just let us know that um well we did already so we'll we'll we'll we'll I'll still pin you as much but maybe I won't expect you to respond as often or if I sense that the backlog is a lot I'll sort of like tone it down but thanks for the update did you go ahead yeah Annabel do you know if those issues for CSS lab are already like the scope of what you're going to do for 11-5 is already defined are you with something with issues already no Clement asked me what my availability was and I it was I don't know so I just figured if we just assume it's 50-50 for this release then that'll just make things easy well not easy for you well I mean that there wasn't wasn't that the initial expectation or communication it was yeah okay I think that's fair yeah I mean I'd love to have you 100 but we have to respect the initial conditions that were introduced um which sucks um anyway so Annabel again so you more more questions from you so I did see your comment um I didn't respond to it yet but uh did you want to bring up whatever a query you had for this one yeah one second um labels with the same name yeah I was I'm not sure what oh this is so annoying what is the expectation because I didn't see that the combined to-do label in a project but I'm not sure so this is basically a consequence of we have project labels then we had a group labels then we made it possible for you to use a group label from a parent group so it's possible to have I think it's possible to have all three at the same time where you have a label called to-do on a group then you have a subgroup and you have a label called to-do on that group and then you have a project in that group and you have a label called to-do on that project and if they all have the same name because we group them by name in the drop-down I don't even know what labeling that with to-do would mean which which label should you pick should you pick the the most general one the one from the group or should you pick the most specific the one the one from the project I'm pretty sure you should pick the one from the middle but who knows um so it's kind of a mess it just it's just a sort of historical um artifact because when we added group labels we didn't make it impossible to have a group label on a project label with the same name I think you can't add one way around but you can add the other way around I don't remember exactly which way I think you can add a group label if you've already got a project label with that name but you can't add a project label if you already got a group label with that name and same for subgroups so it's not super clear what it means and also if you move a group from one place to another like you know you kind of want the labels basically I think we should not spend too much time on worrying like about making this perfect as long as it's something you can actually like use so if that's like putting the group name or the project name in the label drop-down if there's more than one then maybe that's what we do like just at the moment it's like unusable like as in literally you can't do anything with those labels um but if we could make it usable but terrible that would be quite a big improvement yeah yeah so it looks like right now when I picked the combined color one it assigns the project one if I'm within the project right I think the problem is if you already have the group label assigned or something like that then you can't unassign any like you can't unassign the label at all but there are separate labels right because when I went to the project labels it showed the group label to do and it showed the project label to do yeah and either one of those it only took me to the list of issues in the project yes so they're the same but but we filter them by label name not by label ID so it doesn't matter which of them they have if you filter the label the issue list you will see both so yeah so so it's super confusing yeah that's that's the point right it yeah the same name it will probably have the same meaning so I mean we're not probably going to do that but why don't we just if you already have a group label with that name why would we even allow people to create the same label at the project label is there any because we did that because we I don't think we'd actually do let you do it that way but we do let you create a group label if you already have a project label with that name um and basically a bunch of people have already done that not a huge amount but some people have already done that so I think some of it's automatic too because I think the reason I even have those duplicates is because I created an issue board with the default labels right yeah that's that's probably true and the other thing is um when you um I forgot what I was gonna say when you before we had group labels if you search for issues of the group level and you wanted to use the label filter we would blend together labels with the same name for exactly that reason like you know you don't want to search by label ID because then you only see issues in one project you want to search by label names you can see all issues with that label name so like Pedro said it's the name that's the important thing but then I mean one solution to this could be just of the the back ends at the front end just pass the name all the time and never pass the ID and just say like add the label to do to this issue remove the label to do from this issue and then it's up to the back end to figure out if there is a relevant label with that name to match and if there is it does it and if there isn't it doesn't um because at the moment it's sort of a weird mix of using the name and the ID um but I don't know like I said I I don't want to get too ambitious here I just want it to be terrible but you can somehow muddle through and get what you want uh yeah and I think you were looking at this as well right with um luka oh again gone never mind he was so in the in the true description the expected expected thing is three different to do labels and a bad solution or a boring solution would be just to add the project name yeah or even just not have the project name would even be boring for um yeah I mean just three different labels even without the project name I think will be kind of boring and still kind of work because if one doesn't work you just pick the next one in the list and then you just pick one after it like just tell them to use different colors for now right so yeah or different names or whatever yeah just use different name yeah yeah so yeah so I think I don't think we intend like from what you were describing char I don't historically I don't think we intended it to be smart but I think because we were so smart and when we built on it it became smart and just combined well maybe the combined colors thing I don't know how that came about but that looks like somebody coded that the combined colors thing but the the fact that it's it's combining labels as of the same name I think that's just a consequence of us showing names and not IDs or yes ID right right yeah it's because we group my name and we also do that on the dashboard which I think I mentioned in the issue but I am not too worried about the dashboard labels this because it's basically unusable pretty much anyway so yeah so so Annabel what I wanted to do and I think Sean is agreeing is that right now there's some weird cases if you look into the description sometimes it's combining and sometimes it's showing three separate I just wanted to make it explicit in the code or in the functionality that every time you assign a label you can the GitLab tells you all three are separate or all five or whatever and then you can click and you can select and deselect any of them and then it's consistently separate and so you can see everything consistently and then an iteration after this is to present where it originates from if we need it and then beyond that then we we look at the searching functionality on a filter bar because when you search on a filter bar you can just search by name but not by ID so you could maybe like search by three different to-dos so how do we handle that I don't know and I don't care at this level and then maybe even further down the road we address all those edge cases where when you're creating a new label does GitLab tell you that you already have one of the same name and validations and stuff like that so I think all those are really far away but if we just address this initial thing that that I have at this issue I think this will go a huge long way to just bringing sanity that what labels are uniquely independent in the database and thus as also presented to the user which it should be. Yeah the only argument I could think of against that was the situation like I said before where you had different project labels but you didn't have group labels at all and you were trying to filter at the group level now we would just say like if you see any results from one project that's because you're using project labels just promote them to group labels if you see results across projects because that's how you do that. Cool so Annabel that was probably way more info than you were expecting. Does that help? Yes and no I need to I need to create some more projects some more labels locally and just see I'm still not clear on these duplicates but I'm gonna play around with it a little bit and then I'll I'll ping you an issue. I have just two questions does anyone know for sure what it where is the the place where the combined colors appear is it on the issue sidebar or epic sidebar or I think it's any way you can have a label drop down so either when you're assigning labels or filtering by labels basically I think any of those can potentially show a mixed color label. Yeah the example I posted was on an issue a project issue and I was just trying to assign a label and they're two different to-dos. Okay so for if if you already have and those to-dos were two labels in the same project with the same name or were they project and group? Project and group and I think that was just an option of creating an issue board in that project and then I don't know when I promoted one to group but yeah I mean I think the separation makes sense but at the same time I don't know if we're actually improving anything we're just doing it differently because you still don't know like other than the colors and if you're colorblind that's even worse but you don't even know where they belong to so you don't know if you're selecting the project or the group or even inside the same project which one is it? I think it's a net improvement Pedro because literally in some cases again feel free to try to generate all the scenarios that are available but at some point I gave up because they're so complicated so be warned but why I think it's a net improvement Pedro is because what I'm proposing as a result of this change at least for any new data you will always be able to add labels and remove labels uniquely right now there's these weird edge cases that you know Luca brought up where you can't you can't even there might be like three to dos on an issue labels three to labels on issue and you can't remove like one of them or two of them or all of them and there's just these weird edge cases where the data is just stuck so what I'm proposing is that you're making it unstuck so you can actually reliably add labels and remove labels on any given object so I think that's got to be a net improvement um even yeah it's awesome definitely yes even and yeah I don't think there's any negative because like the negative is that there's like three to dos instead of one to do but like that's not a negative that's like maybe a lateral movement of understanding right so that's why I think it's a net improvement from that perspective yeah yeah it's it's not a lot but it's a little bit of improvement yeah I just think we should we should try to very quickly have a solution yep yeah to me it's like we're stopping the bleeding as well with this one so yes exactly like stop the bleeding but yeah at the same time yeah exactly let's even if we use the same issue to do it let's just discuss some sure quick ideas to to solve this like I don't know if you select the label instead of an issue it will always be the project label and never the group label if you have the same names or we put we put this the the the path the project in a group paths or something well I think that's what's happening by the way when you select the combined color label it does assign the project label yeah so so that that's good but I don't know why we have the two colors that's the all right uh I think time's up so I will put this on the internet this video and we'll go from there thank you everybody see you all next week