 Let's do the demo for Squishaw. I'd like to do that. Sure. Let me share my screen. Oh, hi, Squishaw. I hadn't seen you on my phone. Hey, Pedro. Yeah, so as you can see, it appears exact same. So we have the header, the description, related issues, and discussion area. Only the sidebar is not present here. So for sidebar, what we planned to do was to create it as a shared component and reuse it from there. So that it is available in case we want to refactor sidebar implementations for both issues and MRs. So that is why sidebar is missing here, because it will not be part of the same code of the app as the app itself. And the changes for this app are currently under this branch, which is 7.7.5.0 epic app refactor. I'll open MR for this, because the shell part is pretty much done for this one. I'll create a shell for the sidebar on this one. And in case anyone wants to test it once this code is in the master, then it is currently behind a cookie flag. So there's a flag called load new epic app. So I'll leave the details within the MR once I open it. So if you do these changes, like setting this flag to true, then it will load up the newer app. So if I just reset it, like setting it to false, and then reload the page, then it would load up the older app with the sidebar. So as you can see, nothing changed as far as the center content is concerned. Only the sidebar showed up, because it is now coming in from the older app. And I can already see how simpler it would be to test this newer app, because while we have reused all the smaller portions, so the description field, the related issues are all the reusable apps, which are part of the core code base itself. But the header area, the sidebar, once it is implemented, will entirely be created from scratch, except for the smaller portions within those components. And it would be much easier for us to test it. And yeah, it is only going to make my life easier to test and debug it. So yeah. So that is all for the demo. Obviously visually, there isn't much difference from the older ones. So once it is ready, I'll still anyway have it assigned to Pedro to look for anything that I might have missed out in the newer implementation. So that's it. That's great. Kushal, you said this is in French or in master? I thought I heard that. No, it is currently in the branch. What I'll do is that I'll open the MR. So I was wrapping up the portion that we planned for this release. I'll open the MR. So I had this discussion with Andre as well. So right now, not all the new features that we want to test, only in small portions of users are behind cookie packs. We have a proper backend process to do that, like if you want to roll out a certain feature to certain percent of users into the GitLab.com, then there is a way to do that. But for my convenience, because since I wanted both the older and newer app available to me at all the times to compare both of them side by side, I used a cookie flag mechanism to toggle between both the apps. But there is another way to do that as well. I had this discussion last week with Andre in my one on one. So I'll explore what are the options that we have. Because in case once we have this app ready and be part of master, what we may want to do is to roll it out for a certain number of users. Again, it is not a visual difference. I don't see why we would want to do that. That would help us only if we are performing some kind of UX research where we want to see how users would respond to a newer implementation, a newer design of a certain area. It is just a refactor of an existing design. So this is still something that is an open discussion for me. But yeah, in any case, what I'll do is I'll make sure that the code changes are still in the master. And that is where that flag thing comes into the picture. Because if it is behind a cookie flag, then maintainer might not be confident about it, like whether we want to merge it or not. Because if someone enables the cookie flag, then they would end up seeing an incomplete app into the production. Which is why we would hold off in case we want to merge it to the master. Give it a context. That's great. Yeah, if anybody complains about that, Kushal, feel free to take me. And I can also take part in the conversation. I'm not going to override anybody's decision. But I would want to understand why. And because I think this is a great mechanism, this is great work that you've done. It's super flexible. And if this is a production, like you said, that anybody can test it. To me, it's totally safe, because you can't expect somebody to hack your console. That's not fair game. Because then there's a bazillion things you can do already in the console. And you're not exposing any security thing either. It's just functionality. So even though people who use GitLab totally know how to use the console, but it's still not something that I think is a valid argument to protect against. And then your other comment regarding feature flag versus cookie flag, it's called a feature flag, for example. It's a feature. So we're not flagging or toggling a feature. And I think you're totally right. The purpose of that, to my understanding again, is more so if not totally just for testing new features and not testing stability. And then obviously, it can be to be tested for stability. But I don't know if that's the intention. Or what might be features, you also have stability from a bug regression perspective and from if anything broke. So it's like stability as well. I think the correct term would be from a regression. Peerly, no change in technical update perspective. I don't see any inherent benefit to roll this out in changes because if we're doing our QA properly, then we should need it. So we should be confident in that and not mix concerns. Because if we do this, then we will start relying on this. And then the QA person, Ramya, will trust this. Not consciously, but sort of like the process will break down because then she will never have feedback that something broke. So we have to force her to shift. I mean, it's not only her job, of course. At the level, everybody's job is QA. But you know what I mean, right? We want to make sure our QA process is still good. That we're still doing QA. We're still doing future assurance. Well, in this case, we're just doing QA. Because there's no future assurance. It's the same feature, right? So I would say that QA should be the responsible, not person, but process to make sure that a refactor is working and not a feature flag. But the cookie thing is great to do it in steps, right? So that's how I see it. It's great to do it in steps. You know, thanks for sharing that. So that's my opinion. You didn't ask for it if you're going to have an MR. And then that's probably what I would say if somebody needs to do that. So the other topic, unless somebody added anything else on the agenda, looks like nobody, is the promote issue to Epic. So what should we talk about first? Let's talk about the easier thing or less controversial thing, which is migrating the notes over or the system notes. And then I think, Yarka, you put a comment saying that you pretty much want to migrate everything all in this issue. Is that still the current plan? Is everything feasible? Yeah, copying everything is not a problem. The bigger problem is handling the text, meaning we have to move uploads that are in description or in notes. And we also need to change extractive references because all references are in the issue. Either in description or in notes have to be repressed, basically. Extract it again. And we don't have it ready for groups because when we move issue from one project to another, it's still project for which we have Banzai ready for, but not for groups. So that's the thing that I found, basically, yesterday evening. Right, right. Without that, it would be quite simple, but with this, some additional change, those changes might not be difficult, but it will be very difficult to find what exactly I need to change. Right, right. So known unknowns, I think. Yeah, exactly. Okay, so not too bad. So we're past unknown unknowns, right? So we were unknown unknowns until it sounds like last night you did somewhere, so now we're known unknowns. So, sorry, I missed what you said. Did you say images or references or both? Both, both uploads and references. Okay. Because we do have uploads in projects and we have to move the upload from that project to group. Right, so you mean like that. And we have to upload it for a group. So it might, I'm not saying very difficult, but additional changes require. I mean, it seems like a pretty sizable. Yeah, I'm thinking what we can do there. So you mean there's, let's focus on upload first. So when you say upload, it means images, any binary file you can upload in MP3, I think. Yeah, exactly. Yeah. It doesn't matter from implementation perspective if it's image or not. And then you're saying both in the description and you can upload binary stuff in the image and in the comments and then when we. Yeah, but that should be the same method, so. Oh, it should be the same. Okay. Okay. But the uploads are scoped to the project. Yeah. So they, like if I'm not to, for example, if it's a private project and there is an upload in that private project and I'm an anonymous user, I cannot see that's uploads. Is that it? I don't think it's a permissions. That's it. Yeah. So is everybody choppy or is it just me or am I? No, I lost. Yeah. Yeah, yeah, Pedro, I don't think we're talking about permissions in this particular case. We're seeing that when we promote an issue, it's an epic, I mean the next topic is permissions. But for this particular case, we're seeing like when you promote an issue to an epic, the issue lives at the project level, the epic lives at the group level. And I think what Yarka is saying, when we upload stuff, binary stuff, content to an issue, it's in the background, in the background, it's at the project level. So now we're copying over stuff to the epic and so naturally the stuff has to be moved to the group level. Yeah, exactly. We already do that when we move, if you issue to another project, we just move files of copy files from one project to another. But now we also need to do it from project to group. Right, right. And then there's no Yarka, sorry, I cut out there for 10 seconds. So there's no, there's like, we don't want to do anything where we reference it. So bad word because that's where you talk about next. But like, if the object is already in the project, we can't refer to that object directly. No, we should copy it. We do it for when you move issue from one project to another, we also copy files that issue to another project. So I will basically change this functionality to also for groups. Can you talk briefly why that's the preferred strategy? Yeah, that was, that's my question as well. Because how the references and the uploads work now that we also basically reference from when you have issue in a project and you have uploader, it's always reference to that project. Okay, but like, I'm not, you know, we're not going to change your decision, this is more curious, more curious. So my understanding is that all these images, for example, are scoped to a project namespace and then they're not exposed to the user, like the URL or anything, or like that's not a requirement, right? It doesn't matter what the URL is, they can copy it, whatever, but it's in the background stored somewhere, it's one object, and then now we want to display or render that same image in a different location. So why is it technically a better thing to make a copy of it and not just point to it? It seems like it's a saving space, it's already there anyways in the storage, why does it matter that it has to have its own copy? Is that just- Well, I think it makes sense to have a correct project, otherwise it could get messy. I didn't make the decision, I don't know what was behind that. Maybe when the project is deleted, the file is also deleted? No, it's not because we keep the old issue. Even if you keep the old issue, right? They're just references to images, like I'm not gonna keep pushing you, I go, maybe we can just take this off. Yeah, yeah, yeah. It was curiosity as well, yeah. Yeah, I think because we have to have some other ways, it would get messy. Okay, yeah, no, I'm not convinced it's messy, but I'm also not an engineer. So that's what I don't know, that's not- That's when it was made a couple of years ago, I was not there, so. No, and so we can challenge that right now, right? Like we can, and if it's relevant, and like if we can make a decision, then it makes your life easier, let's do it. But let's go with your suggestion, I'll just start a conversation and Slack up, pull in Sean and other people who ever wants to chime in, can chime in, and then, but let's not block you. Yarka, let's proceed with your current design, and then we'll go from there. And then the other thing I wanted to ask is, when you say reference, what do you mean by reference, like issue references? Yeah, exactly, issue reference, well-requested reference and things like that. Okay, and then that has to be all parsed in epic group lands because it could be different. And so there's like you have to run the code again or whatever to do that. Yeah, we have to basically extract that there. Okay, okay, so that's the complexity there on the back end. Great. Okay, so it sounds like everything is still under control, but you found some additional things, so that's great. And then if there's no other topic on the back end, on the front end, we have the, so this is related to permissions, but I don't want to add any logic to check permissions. So if you look at the thread, we had a lot of discussions about that, but what I wanna do is if you have an issue and you, if you can access the issue, then you should be able to promote the issue to an epic. And Yarka, is this correct? I always get this backwards. If you have access to a project, do you have access to the group automatically? You too, right? So you can have a private group, but not a public project, right? Because it can't go backwards. It has to go in one direction, I believe. That is actually- Yeah, you can have public group, inside the group, you can have private project. Right, right, but you- Exactly, exactly, so not the opposite. So that means, my point is being is that if you can see an issue, so there is one edge case I didn't think about, which is confidential issues, then you shouldn't be able to see, okay, so there's more weird edge cases. We'll document them one by one, or we can leave them, but in the general case, I think like 95% of the case, if you can see an issue, then you can see any epic in the parent group, permissions-wise. Yeah, I think so, yeah. Right, and so if that's the case, I want to allow you to always be allowed to promote the issue to an epic, but you just have to be careful. It's your responsibility to be careful, and then we wanna show additional UI to help the user be careful. And then so what I'm proposing here is that, especially for the first iteration, we don't check whether it's private or public. We just always tell them, anytime you promote, be careful, right? And then so there's no logic to check the permissions because everything is inherent. And if that's the case, I think I'm leaning toward design-wise is what Annabelle has, and Annabelle responded, but if you look at Annabelle's design from adding the banner from one day ago, I like that design. And so the latest discussion is just when to add that banner or how, and then let's see what Annabelle said. I don't know the idea of highlighting a whole row in a quick action yellow all the time, either, let me think about it, okay. Right, so Koushaw, my answer to your comment about being it like a lot of work, which I think it would be, I think what the original design is, the banner appears whenever the words promote appear, or with the slash command obviously. Yeah, so a quick update. So when I left my comment regarding, I just wanted to evaluate whether it could be efficient enough to monitor the comment changes and then show or hide the banner. So I debugged it and apparently it is easier to do that by basically monitoring what are the slash commands which are present within the comment body and then show the banner accordingly. Now Annabelle has left a comment regarding how we want to show the banner. So right now, if user clicks on the preview tab, we already show what are the commands present within the comment body and what those commands do. So that is more of a UX decision, whether we want to show that banner as a part of preview tab or if we want to show that danger banner like Annabelle mentioned because slash promote is much more destructive action possibly like it would end up doing a lot of modifications behind the scenes. So whether we want to stay consistent regarding how we want to show those warnings, whether in the preview tab or whether we want to show it as a banner. But if we do want to show it as a banner in real time like when the user is updating the comment field then it is again easier to do as well. Right, right. I would say we should do both to be consistent. Well, the preview tab we should probably do and do we get that for free? I don't even know. Is that inheriting the, no, I don't think we get that for free because like the milestone one looks different. Anyways, to me that's like almost independent because that's nice to have in the preview but it doesn't solve the UX problem of like we want to warn the user, right? So I would push Annabelle and Kushal yourself to figure out whatever is easiest to solve that particular problem. And then the preview tab thing, I mean, to me that's just a poor design currently and like we should have an issue to address it anyways, right? Like if you don't click the preview tab you don't even see that message. And so that's how you do it. 80% of the time I don't click the preview tab as well unless I have like pasted a giant comment with a lot of options to make sure like everything looks fine or not. Exactly, there's like three issues with the at all and at people, like at all and then there's like a warning somewhere and then I forget where that appears but it's related to your preview tab. Sorry, go ahead Pedro. Yeah, I was going to say it related to what you were just saying with the all and here and everyone that was that issue where I suggested maybe we used a two step process where people had to confirm that they want to do a certain action. And I think in this case, if there is a possibility of unintentionally disclosing private information, confidential information, I think we should have like, it doesn't need to be on this issue. This is like something for the future because a lot of people use epics, maybe it's just us and a few customers and maybe there's not a huge risk of right now disclosing confidential information but maybe in the future, we can have another iteration where we show a confirmation dialogue like are you sure you want to promote because like this issue is confidential and the group is public. So shit might happen essentially. But that's another thing. I have to check the design that you're talking about but even if it's just a small note or even highlighting, sorry, sorry, it was an ambulance. What I was saying is that even if it's just highlighting the texts, the promote epic and showing that it might lead to that, I think it's enough as a first iteration. Okay, that sounds good Pedro. And I like your suggestion because it would apply not just to this, we can use it for like the all thing. And then- And we can use it for even the button action, right? So this would be for big action, but if there is the regular button click action somewhere in the UI, we can also reuse that in the future. And the same for assigning a lot of people, right? If you, for some reason your mouse goes crazy and you click like 10 people or 12 people at the same time in the drop down of the assignees, we should have a safe mechanism to make sure that you're not doing an error or doing something wrong. Yeah, I think a good rule would be like anything that's not immediately undoable. So promoting isn't like- Exactly. You can undo it, but it'll take like 10 steps. You have to delete the, well, it's actually not that bad for promote. You have to delete the epic. Well, I guess- I think it's three or four kinds of risks. So one of them is over communication like spamming. Another one is financial risk, which is like being built for something that you weren't sure you're going to be built. The other is private information, like something in your personal profile and you didn't know that like this information could be public. And there was another one that I'm not forgetting. But something like that, yeah. Yeah, I need to have a step back. Yeah, like, because I'm thinking like related issue of quick action, which a community member is working on, right? That is like you wouldn't add more friction there because you could immediately just undo that action really quickly. So- Exactly, exactly. But promoting epic, you could delete that. You could close the epic, but you can't even delete it. And then if you have permissions to promote the issue, you don't have necessary permissions to delete the epic. And then exactly like you said, you have to go into the epic, you have to delete all the content that you don't want to be shown. And then once we have description history parsing or tracking, then you can't delete that either. So that's coming. So all these things that you write incorrectly in the description are that it's embarrassing because you made a typo. Those will be logged forever, sometime in 2019. So that's a good point. So, okay. So why don't, yeah, why don't we let Annabelle continue with this? It looks like at least Yarka is chugging along there's still more work anyways. So hopefully this won't be delayed. We're at the 16th now. So it seems that we have, we're not even halfway yet, but we'll keep monitoring this. I think this is a great issue. Anything big else, Yarka? I know Kushal is pretty much in the clear form. I just wanted to add that we were talking about promoting issue to Epic that went permission problem, which is not having a problem, but we do have the same when moving issue from for instance, private project to public. So maybe we should keep that in mind. Yeah, yeah, we should log in there. Sure. I'll create an issue. Well, yeah, I'll wait till the design settles. No, no. Yeah, yeah, sure, but just not to forget that. Yeah, no, no, I should never do that. That's an anti-pattern I feel that don't wait just to commit an update. So I will create an issue, but I can wait because I have a crap load of stuff to do. So that I can forgive myself. Well, no, I shouldn't forgive myself. Okay, so you're just gonna watch me create an issue. So anything else we need to talk about? I'm gonna create the issue now. Anything else Yarka on? Is Yarka frozen? Nothing from my side. Okay, so let me let me check quickly for following management stuff. Is this the big one? Like this is the big new feature for 11.5, right? Like we have a bunch of smaller things. Yeah, I think so. But they're not new. Yeah, they're not new. Yeah, I'm looking at the 11.5. They're not new features. They're all improvements to existing things. Notifications is a big one I guess for closing ethics. Okay, great. Okay, I'll create that issue right now so I won't delay. All right, thank you Yarka. Thank you for your all. Thank you Pedro. Talk to you folks next week. Bye.