 Yeah, so I think this is pretty much a think the first two, but so as we spoke about last time, Yakuza 100% of 50% at the moment. So some of the rest of the team are taking some smaller issues like bugs and polish. There's a couple in there for the rest of the team at the moment. So we'll probably keep doing that going forward because we don't really want the people working on portfolio management to spend a bunch of time fixing small issues like that. It makes more sense to spread that around a bit more. You set up a thing to automatically create the retro issue, which I don't know if it's working, but then I thought that it might be nice to create the issue earlier because you might think of something during the release and the reason I didn't do that before with the automated thing was because I wanted to get the list of issues that shipped and issues that slipped, but we could just create the issue and then update it. That's like solvable, like you just did two different steps. So if you have a strong opinion, add it there and I'll take a look at it when I get back. I didn't add it here actually, but I've spoken to a few people. I'm out from 7th to the 28th of September. So see you after this, basically. Ramya, you're next. Sorry for interrupting. Looking back, Sean, to 1B, I think I missed what you said there. What do you mean you have six weight available from rest of the team? So if we assume that the person who is working on portfolio management will be 12 weight if they're dedicated to it, but Yaka's at 6 weight because she's working part-time, then we have 6 weight for the rest of the team to spend on portfolio management as well. I think we had Shenzhen running 4 or 5 on or something to the rest of the team, so it was pretty close. Okay, and then just curious, your capacity is that I know we keep changing, so we wanted to know the latest. Is that based on some GitLab thing or is that based on like the numbers or is that based on GitLab? Like we have some standard, right, according to the handbook. Is that based on that or is it like velocity? I don't know if the handbook MR's actually merged, but there is a handbook MR that Dower created that describes this. But you know, the estimation is deliberately lightweight, and so the capacity is also lightweight, so we don't want to, like I said, we can, and we did go over a bit for some people and under a bit for other people just based on the distribution of the issues they have, like if someone's got bigger issues, then maybe they can't take as many smaller ones because they'll be dedicated to that one, but if they've got a few smaller ones, then it should be easier to get through, but yeah, it's not a science. Okay, yeah, no, maybe I'll take a look at that later or whatever, but that's fine. Cool, just a suggestion, should we just put the availabilities at the top of the thing? Sure, it'll be in my, it's already in my calendar, in my slideshow. Yeah, I think it makes sense at the top of the agenda. All right, so back to Ramya. Yep, so this is about the test plans that I had been writing, so this is just a heads up, like going forward for every issue that's going to make it to a particular release will be linking a test plan issue as well, which will list down a high level overview of what kind of tests will happen and also it'll have the kind of tests that would be automated as well. So as a follow up for that issue, we'll be automating those features as well and adding it to the existing test suite. So this would happen. So just wanted to give you a heads up of that and just today I added the test plan for a couple of issues and I think, I think the developers who are working on those issues and also Victor, so would that be okay or should I mention someone else? Just the developers would be good enough? You mean to review the test plan or? Yeah, to review it. I don't know, what do you think it's for Sean and Andre? Do you folks want like a rigorous process or is it just like people looking at it or? Well, engineers is enough, at least, Victor engineers because there might be something that missed on the test plan, I think. Yeah, I think letting the person know who's working on it and also reviewing the tests and their amount will be useful. Okay, so I just want to mention, I don't want to block Ramiya on work. So unless Sean and Andre or other people on this call disagree, I think it should be like Ramiya reaches out to people she thinks is relevant and then this call will let her know who those people are, but I don't think we need a strict process to say she has to bug people to sign off on a test plan before working on it, that type of thing. Yeah, yeah. I have a question regarding the test plan. So I saw that you created an issue with the test plan for a couple of other issues. How is that issue closed? Is after you run through that script successfully, after it's merged? So what I'm thinking is like once I have the automation for that written and once it's added to the test week, that would be the end and I would be closing the issue after that. That's deliverable. Okay. And will that happen before or after the feature is merged into master? Ideally, I would prefer it to be merged when the feature is being merged, but then realistically, I'm not sure if this is possible. So we are just giving it a try and just trying out few things. So I agree. I think the goal is that, but Yeah, first iteration, I think we should, especially since like, there's at least one issue I commented on that that's already merged. So like, it really breaks the rule. So I agree. We should. Yeah, I think it's a good goal, though. It's a good goal. Like once we catch up and we're working on new features. And so Rami is, I don't know this. So the automation code is that that's not in GitLab C or E. It's a separate code base. Is that correct? Um, so the feature tests, right? I think it's a part of the club C. Okay. Yeah, currently, yes. Yeah, the UI driven tests. And we are also planning to have API level tests as well. So and are those so so are those checked in? So those are automatically run when the pipeline runs? So so once those are in, you don't have to do any extra work to make sure those tests are having value because every new developer that is trying to merge. Okay, that makes the sense. And then does your test plan include any manual tests or is that separate? So if there is a manual test needed, we would be adding it as part of the plan as well. But we're planning to keep it as a at a very minimal like, ideally, as much as possible, you want to automate. Because the question that is lately exactly like Andre's question, how do you like, where is that? How is this issue considered closed if there's a portion for manual part? Like, do you document it somewhere? And then even if you document it, it's useless unless you actually run the manual tests, like with like every regression, like there should be some schedule. So like, is there any thinking there? Yeah. I mean, you don't have to have an answer yet if you don't. Yeah, actually, I don't have an answer. So maybe I'll see maybe for one iteration, if I go through it, I get a better idea. Yeah, no, no, that's good. So let's let's, I'd say, at least for a platinum, let's the criteria to close. I think that's important, like Andre said, like, so we don't have these test plan issues lingering. The criteria to close it is to merge the automated tests, and then any manual things can be, you know, we'll just document what we'll comment along in the issue. And then as a second iteration, we'll figure out what we want to do in plan and across GitLab, how we want to document those and run those because it's, it probably makes sense that it should be separate issues anyways, but right now for now, I don't think we need to add too much complexity process. Yeah. Yeah. So and one more thing is like, we are actually maintaining a master test case sheet. So which actually has a bunch of all test cases, either manual or automated, all of that will be recorded in that sheet. And we actually have categorization in that sheet as well, like which of these tests are automated, and which of these are UI automation and API automation, or which of these are not automated at all. So that sheet would be like the place where we keep updating. So maybe to answer your question, there's actually one place right now. So too quick follow up one follow up comment, one follow up question, follow up comment is eventually somebody will tell us to build that feature into GitLab. And then this team is possible for it. So so you might as well start creating issues and thinking about that. Of how to get that the functional functionality of what you're doing in that sheet into GitLab. But what's interesting to me is that because that we have never done anything like that, or GitLab doesn't have any type of testing, like sweet, like test management, or like HPQ, what those are called. And so and customers are actually asking for those types of things. So it does make sense that we eventually build it. It's not clear to me when we build it or do we even build like a small slice anytime soon. But my so so that's the comment. My question is, will there be any plans for GitLab to, to use a different tool beyond sheets cool sheets? Like will we ever use a real testing tool to document all this? Is there any thought to that? There are a bunch of test management tools, but then I'm not sure of the future plan. This is the first step that we've taken to record all the test cases in a sheet. Apart from that, I actually came across a couple of other issues as well, which were requested by I think customers or users about something called the quality center, which is something similar to what we are discussing. So exactly. Yeah, I don't know. I don't know about the future plan. Right. Yeah, no, no, that's Yeah, something to think about because I don't know at GitLab, we never use another tool or sometimes we like some teams do do but like it seems that every time we use a non GitLab tool, it's going to be like Google Sheets or like Google Docs or Google Slides, right? But we don't use a real Yeah, like we don't use like, like, all I know is HPQC because I've used that before. I know there's like what rational there's probably some other tools that that do like store test plans and test scripts and stuff like that. So it'll be like interesting if like, Ramya, your boss and and and then all the bosses, bosses and like wants to use any of those, because then we'll we can actually look at them and then like get some ideas and then bring them into GitLab, because that's actually better than bringing the ideas of Google Sheets into GitLab because there's not a lot of ideas there. But if we're actually using other tools, we can actually learn a little bit more and force us to learn those other tools. I know we never we don't like to do that. I don't know for some reason or another. But anyways, that's Yeah, actually, I've used a tool called Test Rail, which has a lot of cases in itself, like it helps you to pick test cases that you want to run, and schedule or run. And it's actually has a lot of integrations with Jira and other third party tools as well. So something similar, some similar capability in GitLab would be like, really awesome. Great. Awesome. All right. That's all the question. There's nothing else we can go to Pedro. Cool. Yeah, thanks for me for explaining that I'm going to take a look at the issue as well. There's anything I can help with. So I wanted to do this quick demo of a tool. Let me share my screen called Podio. I don't know if anyone has ever used it or not. I just found it out because my wife is using it for a project. And I stumbled upon it. I was helping her like configure something here. And then I noticed that it has a lot of project management tools here. And yeah, I just wanted to check it out. And I thought it was very interesting the way that they organize all the tasks, how they view the different statuses, their kind of issue board view, their issue list, the team views, private views. That's how it would be interesting to give a quick demo here. And since this is being recorded, maybe we can then trim this and sharing the product channel if someone is interested in taking a look as well. So here in Podio, they essentially divide each. So they have what they call workspaces, like this is the company, you can create workspaces inside of your company, which is more or less, it's kind of a group, what we would call groups inside of GitLab. And then inside of each group, you can then add different projects, deliverables, meetings, and you can add other functionalities. They call them apps. And you can even duplicate apps so I can have different or deliverables if I want, for some reason, and they function around this notion of apps. And all apps have a very similar visualization. So for example, I'm here in projects, and I can even look at projects in the list view, or I can switch to card views if I want to see projects in the cards or in calendars. So they all function in the same, more or less in the same way. I'm just going to focus this on this one that is called deliverables because it's similar to what we do with issues in GitLab. So the interesting thing here is that when you start out, and you don't even haven't even created anything, the default view is this one called all the deliverables. And essentially, it's not a filtered view or anything doesn't have any filters applied. And you can then start creating, let me just minimize this. And you can then start adding issues or in this case, deliverables, you click here, you add all of the data, you save deliverable, they have this funny thing that you can like create a duplicate from what you've entered here or create another one from scratch. And you can then populate whatever you want. And if you want to have a focused view, so in this case, I've already created this plan view, work in progress deliverables for inside of the team views. And I've also created these private views, which are only available to me, called my deliverables and then table and I'll explain what they are. So the thing is that this all deliverables, which is the default one, you cannot apply any filter to it, or the better way to say it is you can apply a filter. But once you apply a filter here, so I go to here and say, for example, I want to see only deliverables that are work in progress, you will notice that the list is now filtered. And it says here that this is an unsafe view. So you're prompted to save it if you want, or you just keep this like temporary view of whatever you're seeing. And then I can click Save, give it a title, save I want to place this view in my private view views or team view. Or I can just click again all deliverables to clear whatever filter I had. And you can configure this all deliverables view to have a different layout. Right now, this is the board layout. And once I switch the layout, for example, to a table, which is similar to our issues list. It again asks me if I want to save this view. So essentially views are collections of filters that you've applied, but also the layout that you're using. And so, like for example, here in this plan view, I have kind of a card layout. Here I also have a card layout. Here I also have a card layout. But when I in this one called table, I have a table layout, which has some filters applied to it. So the views also affect which layout you're using. But again, you can quickly switch between which ones you want, and you don't have to save anything. You can do this on the fly to activate whatever you want. And then you can save it. Another cool thing that they have here is the fact that you can define a default view. So this one has this little dot saying that this is the default view. And I can then drag this view to the top. And so, this view that is closer to the top is now the default view. And so for each person that now arrives in this app, they're going to see this view as a default one. But for me, that I'm just like looking around and clicking and browsing through views, if I refresh the page, or if I go back to a different app and then into deliverables, it, it respects whatever view I had viewed the last. So it will stay at my deliverables, even though this is the default view. And this is very customizable. You can even like hide this sidebar if you don't want it, you can show it full screen or not full screen. And for example, for my deliverables, I can say if I want how I want to organize the columns here. So if I go here to options, I can say columns based on status or owner or related project and rules based on owner status or related project. So if I wanted to do, for example, rows based on related project, I would see that all of the tasks are in the GitLab Community Edition project. Let me switch this one to a new project called GitLab EE. Okay, this is a GitLab EE project. Okay, cool. Sorry. Okay, GitLab EE. And so if I refresh, I will see that now, not only am I organizing the columns on status, but the rows are now based on the project that I'm working on. And basically, this is defining columns and swim lanes. And I can do whatever I want here, but notice that it's not saved the view. So what I have to do is click Save, and then type whatever name I want and saving my private views, for example, and now it's saved here. But if I needed to change something simpler here in the My Deliverables, and for example, let me filter this by, I won't filter this by owner, I'm going to filter this by tag. So I only want to see issues for plan and status, work in progress, for example, so now I have two filters, I can then click Save As, and it asks me if I want to override my current view or create a new view. So I'll say override current view, and now this is saved. And I can then make a team view if I want out of the private views or just keep them separate. And so this way of organizing things I thought was pretty interesting. It also have the reports here, which is kind of a dumb report because it's only counts. But it's interesting that they've kind of integrated everything, both lists and boards and whatever you want and the different views into a cohesive UI. The only thing I'm not that much fan of is the layout being kind of hidden here. And also the filters, you don't know which filters are applied, you always have to click here to see which filters are applied, which is kind of dumb if you only have one. That's the same as the GLAB, isn't it? If you've got safe filters on the board. Yes, exactly. It's the same. Which I'm not a fan of as well. They're really that. Yeah. Yeah. And this is what I wanted to share. I don't know if anyone has any questions or comments. I'll just add that I just that I like the ability to create private and team views and tweak this and they will remember the settings that it was set on. Yeah, when you set the table view, like you remembered that view in specific, I find that pretty neat because sometimes some data serves a different kind of representation and being able to set that in stone for future visits, whether it's teammates or private, I like that distinction, which I know that it's in our goal to clean that up and to find that make that more useful. But I like that distinction in particular. Do you know what happens if there are like 50 team views by any chance? I don't, but it would be probably interesting to have some kind of search here. I haven't created that many views. So I don't know. Yeah, but that's a problem that we have to the right. We have so many different boards. Yeah, Pedro, do you mind going back to the view with the actual board? So this is the default one, and you can even configure one thing I forgot to say is that this all the liverables, which is the one you cannot delete, you can delete all of them except this all the liverables, you can go here to the app settings and configure the default. So yeah, the standard layout. So I can say that this is table, save. And all the liverables is now a table. So you can also set which is the default view you want for this catch all team view. Right. So they've combined, which makes sense. So we have lists and boards and then it's one thing for them. Or it's easy to change them. And then what happens if there's multiple columns? You know, multiple columns, you just keep any more and more columns. Oh, I think so here, let me see. If I can, let me switch this back to status. You just get Okay, yeah, so you get these and you have these arrows, which I expect you then be able to navigate here in the table view can see this working. So I assume that this is probably the same that will happen right here. Yeah, they have a lot of what's interesting is they have a lot of views. Right, like the same the same data is shown. Pretty much the same data shown, but it's just rearranged, which is Yeah, they have this badge view, which is kind of big, not that organized view you can sort, you have a lot of sorting options. And these are just big badges. Right. Then they have the table one, the card, which is a Kinsor issue board, they have an activity one, just activity of whatever you want. But this one is not filterable. So it might not make much sense. And then you have the calendar, which makes sense for the way that some teams work with due dates, for example, it might make sense. Or like if you try to apply this, so this we're looking at the deliverables level, imagining like they have projects here, and you can also do that with projects. So if you wanted to see in calendar view, like how your projects were starting to starting or finishing or even in between if we had epics, I think it's a very flexible. I think they have a very flexible system for you to be able to do whatever you want, essentially. But I don't think it's very complex. I think it's easy to get going and understand what this is all about. Great. Yeah, I so one thing I can do for whoever's interested, I can, I created this free account and I can invite other people if you just want to like mess with this, it's totally fine as well. So let me know if you want it. Yeah, I'd be happy to play around with it. Just to kick it's tires. Cool. Yeah, can you invite me too? Sure. Or I can invite everyone if you don't want just disregard the email. That's easy. Cool. Yeah, any other questions? Yeah. Okay, so thanks for sharing, Pedro. Yeah, I thought it would be interesting to take this time also to share some things not necessarily concerned with what we're doing right now. I don't think we have anything else in the agenda. So I'll let me just add one thing. I didn't add it. I didn't add any point to me from me because I'm still on the process of finishing up the planning for 11 for Victor. So by tomorrow or something, I'll have a better view of the particular issues. And I'll have some feedback for you. What I do have is that the issues issue boards cars that Constance is working on. Pedro did a review yesterday and it just so happens I might have forgotten to raise that but Constance is on holiday. It's off this week. So there might be some constraints there getting that in before the freeze. But I'll stop check with him if he can still I fix those things. But since it's off, it might be slipping a little bit. Yeah, I think that when I just raised points regarding just the desktop view, I didn't even look at all of the responsive use because it was already so many points to to check. So I'm yeah. Yeah, it was good to start with this issue because we have a couple of redesigns coming and they all have all of this breakpoints that you've designed the mockups. And I think it's a good lesson to see that we need to account for those on the review, which will always raise a lot of issues. So I'll revise the weights of the future ones as well. Yeah, I think in this case, let's see how it pans out. But I'm also wary that it probably won't get in. And yeah, in this case, it was the way it was, we had the summit and all of that. But it's, it's, yeah, it sucks both ways when when the review is only so when the MR is only ready to review with with so little time. Yeah, I agree for the freeze date. But yeah. Okay, thank you for saying that to me. Yes, you're welcome. But that's it. That's all I have for now. But I hope to have something by tomorrow and I'll bring you over through the channel, as usual. Nothing else for me. So wrapping up. That's it. All right. All right. I'll put this on YouTube unless people disagree. One, two, three. No, all right.