 Okay, it's time. Hello everyone. Welcome to this new Edge Functional Group Update. I'm Remy Koutable from France, it's 5 p.m. And we'll get started with some achievements. So in 10.3, we merged 45 merge requests from the community and in 10.4, we merged 42. As you can see, the number of merged community contributions is declining. I'll get back to that in the concerns later in this presentation. Let's focus on achievements for now. Then, regarding the community contributions, I highlighted a few ones here. Oops, yeah. So yeah, we've had great contribution from Blackstone to actually limit the labels that are displayed in the auto-completion when you have an issue of merge request that already has labels and you type slash a label, for example, it will not propose you the labels that are, I mean, it will only propose you the label that are already set and so on. So that's really a small thing, but really great for user experience actually. It was long awaited. Thanks, Blackstone. Another one from Blackstone. He submitted a merge request to improve the empty state for merge request changes tab. So instead of having a white area, we now have a nice image that is more engaging, sorry. Then we have a contribution from Marcus Kohler, who is a regular contributor now to be able to add custom text on the new project page, like if in your company you have specific rules for projects and you want to highlight them at project creation, that's a cool feature. Thanks Marcus for that. Then we have two API improvements that basically adds ordering and sorting for project contributors and tags API. Thanks Jacobo, Bessie and Asib. And we also have another one from Mario De La Hossa to be able to quickly pose or resume project runners instead of having to go in the edit page and set the runner to active or inactive. And then the last one is to expose participants in issuables, so merge request or issues in the API. So that would be really useful. So that was for the community contributions. Still on the community side, we now have James Lopez from the team that is now a new merge request coach. So it will help crushing the backlog of community contributions we have. Thanks James and welcome. And then on two performance improvements. Last time I told you about a first pass of improvement from Genshin and the branches page. And now I'm happy to report that compared to 10.1, 10.3 is two times faster on this page. So from 4.6 seconds median to 2.3, as you can see, you can also check out the live graph. So thanks James and for that, and we'll continue improving the performance of GitLab for the upcoming quarter. Then regarding quote quality, we extracted the Rubikop configuration. So Rubikop is a static analysis tool to enforce consistent styling in our code base. So instead of duplicating all the roles per project and also enabling different roles sometimes, we extracted the GitLab CE configuration into a new gem, GitLab styles. And we are now using this shared configuration in GitLab CE, GitLab QA and Gitali with a few specificities for this project, of course. But that's great to share a common base for that. Another big one from Blackstone again is to replace a method to add a user with a role to a team. We deprecated the double bracket in favor of add role and add developer, add master, add guest, et cetera, methods in tests. So that was a big one and a longer way to do. That cleans up our code base a lot. And that's great to share a common base to help our code base a lot. And the last one I highlighted here is from TM Lee and he submitted the refactoring of some views, member views by using presenters. So that's always great to have contributors caring about our code base quality. Next up, documentation. So we had a new documentation from Genshin suggested by Robert to document some utilities that we use in our code base. And GereGorge also submitted, contributed a doc about end-to-end testing and GitLab QA tests in our public documentation. And speaking of GitLab QA, we started implementing a scenario to test deploy keys. So the first iteration was to register deploy key and then the next iteration will be to actually generate a dynamic path of key and actually use it in a CI job. So to ensure that this full scenario works as intended. Another achievement. So last time I told you about the automatization of the CE2E merge requests. So last weekend we've had a few merge requests automatically created and I was really happy because a lot of them only had like two conflicts, one or two conflicts and there was even one on Sunday, but don't worry it was automatized, no one worked for that. The one on Sunday had no conflict as you can see. So it can happen sometime and that's the goal to have fast merge cycle from CE2E so that we have as less conflicts as possible and yeah, that's reaching the plan. And yeah, we also had an improvement submitted by Jenshin to assign the automatically created merge request to the most mentioned person and then each person that have to resolve a conflict should assign the next one in line so that the goal is that the CE2E merge request is never forgotten and moves forward and can be merged as fast as possible. And then yeah, an improvement to come is just to post a link to Slack to get attention on this automatic merge request and yeah, that's almost ready. Last achievement about testing, it's actually something that Tomas did, basically he improved our runners to basically like gave them more, gave them more CPU and memory and the end result is that our pipelines are even more faster as a result, as you can see. So there was some discrepancies as you can see but it was while Tomas was fine tuning the settings. And now the whole test parallelized take, as you can see in average, less than 30 minutes. That doesn't mean the pipelines take less than 30 minutes. I will come to that in the occasion. Now some concerns about communities. So last time I told you, and this time too, I told you that the community contributions are declining a bit. So I've created an issue and we started to ask why is that? So I've also extracted some data. And so we have backlog of around 190 merge requests from the community that is pretty stable over time. And we see that the number of community contributions that we merge declines. So that only means that we get less new community contributions basically. So Connor suggested to actually send a survey to our community to understand why they contribute less than before or why they don't contribute as much as we would like, at least. So I think that's a great idea and I will follow up on that next time. As you can see, I've also contributed the ratio between community merge requests and compare to the total of merge requests. I've just refreshed the page to see the graph better. So as you can see there, we were quite consistent at maybe 18% in average from 8.12 to 9.1 approximately. And then we had a drop in starting at 9.2. And now we are more around between like 10 and 15% of community contributions merge per milestone. So that's, and since it's now stable at this lower ratio, it means that we actually also merge less merge requests in general. So that's maybe another problem, but I think that this data was interesting. And yeah, so now on to the OKRs for Q1. So we have a few of them and I will let you take a look what's the OKRs that I'm the most excited about the run to reduce the average C pipeline duration to 30 minutes or less. Right now they are more about 40 to 45 minutes in average. I'm gathering data on that too. So next time I will have more data. And another one that I'm very excited is to have 90% of the CE2E merges with less than five conflicts. So that means that the CE and EE code base will be well separated and developers take care of doing a good job at avoiding conflicts also. And yeah, so and a few other key results like about GitLab QA of course and performance improvements as always. And the last point in today's presentation is about hiring. So BJ is focused on hiring these days. So we have two world's open automation engineer and test automation manager. So tell your friends, we already have some candidates in the pipelines and yeah, we are building and making a strong process currently. So we will start technical interviews next week. Actually this week even. And yeah, so yeah, tell your friends. There's some cool position. And yeah, that's it for today. I will open the chat. Lower test times. Yes, that's always better. Do we have less issues accepting merge requests? That's a good question Bob. Actually I don't think so. Last time I checked, you can check right now. I think we have a few hundred issues to work on open for community contributions. So I think, I mean, we should ask the people if that's the problem, if they don't find issues to work on. But I think we have plenty of issues open. So I don't think that's the case. But I don't know if we do a survey, we will for sure have more definitive answers. Yeah, so I didn't read Mark's answer, but yeah, we try to open more and more issues to community contributions. Did we measure the time it takes for us to accept a merge request? So that's interesting question, Christian. I try to extract data on how many user notes. So comments we have per merge requests. And my idea was to maybe find a correlation between when we merge many community contributions and if these contributions have less comments than when we merge less. Like meaning that when we merge less, it means that the merge requests were bigger and have more back and forth and feedbacks from reviewers and maintainers. But I didn't find a good correlation. Let me give you the link, I have the data somewhere. I just gathered them yesterday and today. So you can look for yourself. I will give you all the link, this one. So you can look for yourself and there's a few data. What I really wanted to extract was extract the size, like the number of changes on average per merge request and because maybe that will give us a better correlation between how many merge requests you merge and the size of the merge request compared to the number of comments. And I mean, is there a correlation between how fast we respond to the merge request? Like if I do a merge request to get lab now, do I get a response within a business day or something? That's a super cool question. And the thing is, yeah, we could probably extract the first reply to a merge request. So I think just to be more concrete, yeah, I think we reply quite quickly to the new merge request. So I don't think that's the problem. But what is, I didn't see anything in the plans about moving all the EE code to the slash EE sub directory. Is that something we're gonna do? Or is it not a, is it not an equality team or what's happening? Yeah, yeah, that's something we already started and that we will continue doing. Actually, it's related to having the CE to emerges with less conflicts. It's one way we will do that is to better separate the two code base. And yeah, we are doing this actively and that's something that we are doing and that is moving forward quite good. Okay, is that something that's gonna be achieved in this quarter? Yeah, I think we are not so far from achieving it. Right now, I think we still have some JavaScript files to extract code base. That's probably the oldest one. But yeah, I think that's possible to do it this quarter. Yeah. Cool, sorry, you talked maybe you said it, but the self-service metrics generator, I don't quite understand what that is. Yeah, so basically that's something to be defined but the goal is to, so yeah, I've linked the issue. There was another issue where there is more comments. The idea is to get insights of our projects like as you can see, it started about the issues and merge requests like as you asked like how fast are we to reply to incoming merge requests? What is the burn rate of closed issues with open issues and a bunch of other metrics? So that's still something to be defined. The goal is actually to define that and to start prototyping something. I'm not sure if this, I think that probably should be a GitLab feature at some point, actually, so that's something we need to figure out basically. Yeah, I agree this issue could just be a feature in GitLab. Yeah, I think so. Cool. Okay, so by the way, today someone who works on integrating Mercurial into GitLab, you wonder if we will accept these merge requests. Okay, Christian, don't hesitate to give me the link if she wants. Cool. Thanks everyone for the questions and attention and I will see you in the team call. Bye-bye.