 Hello, everyone, and welcome to Friday, June the 1st, and it says five o'clock on my clock. So I will be starting with the front and functional group update. So let's see. What happened in the team? We can welcome two new team members. I'm very happy to have both of them on the team since the last weeks. Both have already contributed and delivered even deliverables to the current release cycle. So welcome to Paul and Sam again. I'm very happy to have you on the team. We have hit already the three of three hires for Q2. So the third one will be starting in mid of August due to three months leaving policy. Mike Graving and Clement Hall were promoted to senior front-end engineers. And we're having a good pipeline at the moment and get a lot of attraction to the front-end engineer positions so we get a lot of applications, CVs, et cetera. But please, if you know anyone still direct them to our direction, our target is 23 for the end of the year. So we are always open for new applicants. Any accomplishments and updates, the OKRs respecting the deliverables, we have reached 30 of the 38 deliverables and reached four out of 12 stretch. As said already, the hiring is going quite well with the sourcing. It was an issue that we were first concentrating on all the applications that were coming in. And we have a little bit of a problem as the current positions are quite far out of our network because database engineers are normally not that connected to front-end engineers. But we are trying our best. Eric Eastwood moved to the Gitter team. So he's doing a really great job there. What makes me also very proud of the team is that, again, the front-end team has contributed a lot to the contact day and has reached also position one again. I know that they have put in a lot. So a lot of broad posts are coming, a couple of talks were given. And in retrospect, if I think that especially with applications and hiring, this is helping us a lot as we are having a very good position in the community that a lot of people are seeing what we are doing and are then also interested in our positions that we are opening up. One of the biggest things that happened, one of the three things, is the Webpack 4 upgrade. Thanks to Mike again. As you can see, we have a lot of performance improvements on the build timeline. Also, he has documented that we have more capabilities to do prefetching and pre-loading. That means that a part of the application is only loaded if a specific action is happening. For example, the JavaScript part of a dropdown is only loaded. Then the button for it is clicked, which helps us to reduce the starting loading time. And it's really giving a much better UX and performance on the first name. The other big thing which was merged last week is the Bootstrap 4 upgrade. This is huge. This was a huge undertaking led by the front-end team, by Clement Annabel, Jose Simon, and Eric Chipp, also in. Thanks again also for the front-end reviews, because as you can see, there were 700 plus five changes. And I think it was a really great team effort together with the UX team to find out where our showstop was, what are the things that we need to fix. And that was all brought down to zero. And now we are basically polishing. So if you are still seeing stuff, take a look at the issue list. Create an issue and label them Bootstrap 4 and we will have everyone who is currently free is doing polishing there. Why is this so important for us? This gives us the opportunity to bring in, this is the base and cornerstone to bring in view Bootstrap, which is the chosen UI component diary that we want to use. And with this we can, in the next iteration, really start to integrate those and that helps us a lot. And of course, we get a better CSS framework underlying there. As a lot of work went into Bootstrap 4. Much request refactoring, as we call it, the big elephant in the room. But we have fit over the last months, and really is a high spec situation, which is not great, but at some point it was like, we need to get through it. And I'm very happy and thankful to, especially Winnie and Simon, who also helped now Fatih over the last weeks to get this moving. As you can see, even on the last three weeks, we had 200 failing tests because all tests also needed to be rewritten. There's a lot of functionality hidden inside the merge request refactoring page. At the moment, we are below 20. So I'm really looking forward to do with everyone who's involved with Victor and also all the engineers on Monday, go and merge check. So if we are green on all the pipelines, if we are happy with the code and can go forward with the merging. One thing that we have fit is also catch 22 situations. So we were rewriting the merge request page to make it much faster. But we were having with the current one to review the code for that. My biggest learning and I think the biggest learning for the team is really to, that we will never do again such a refactoring. This is for me out of question. The direction to do something like this in the future will definitely be to do a complete new implementation of that feature so that we reimplement the feature itself but have it either through a flag or have it as a different, like a side route so that we copy everything and have everything in a new route so we can push to master, we can get a lot there, have a small child cycles there and go from there. So as said in the headline, it's 98% done and we hope that on Monday, Tuesday, we will have to find a state and hopefully get this now finally through the finishing line which will give us the opportunity. First of all, it will be much, much, much faster merge request page and as it is now a complete new application we have tons of opportunities to do performance improvements, et cetera, et cetera, et cetera. So let's see what is the next page? What are the current plans? One of the big next steps for the frontend team, as you know, we are now at 18 people in the frontend team will be the structure and sub teams. This will happen over the next weeks. We will dedicate engineers to specific product areas as it is also in the backend area. So this will be one of the big plans and also challenges of course. And as said, the UI components, the GitLab UI is one thing that we are pushing forward which was the base for that was the bootstrap for upgrade. And we hope we can get this moving now in Elevent.1 that we will have the first view components that we can reuse in our application overall and have that integrated. Challenges, again, as the last time, hitting the 100% delivery of deliverables and also introducing the usable UI components. I think this will boost our productivity by a huge percentage, but on the midterm run. So first thing is we need to find out our workflows, how do we handle the external package, how we handle different workflows of reintegrating this UI component library, et cetera, so there are a lot of still question marks, but as we go, we are figuring out step by step how we want to go down the path. Yeah, and that's basically what happened and what we want to achieve over the next week. So I'm open for questions. Philippa, there are a few discussions on Slack saying the merge request isn't faster with the refact and that there are a few obscure UI bugs will this be fixed before being merged? Yes, so first of all, it is faster in my opinion. There are still some errors which can be improved, but by example, scrolling, I've already seen it with my branch that's scrolling with 100 file changes is much faster and much smoother. And also the async loading makes it appear much faster, but as said, we will have tons of more things that we can reiterate on it. UI bugs, yes, we will fix everything that we see as a showstopper. If we see by example, something really edge casey, really tooltip is not showing up if you're on Firefox and move around the mouse, then we will mitigate that to afterwards. It's better for us now to get it merged, have this big elephant done and then really make it much faster in smaller durations to fix those bugs as we do it in a bootstrap for merging to really polish and go for the smaller things afterwards. But we will definitely, what I want to achieve is really get all green lights from all the different people so that everyone is happy with the current state and then we will move forward. So do we have any metrics on how much faster is it for a given merge request? We will have these metrics as soon as we have it deployed on gitlab.com. So we have numbers on the current side speed instance and the merge request page is the slowest. We have, by example, one huge merge request that we are tracking since months has a final, a full loading time of 60 seconds. And I'm pretty sure we will be able to make this much faster, especially simply, we will still be loading the same amount of data, but as we can mitigate different loading points to asynchronous calls, it will definitely feel faster and we shouldn't be able to also make it faster from the scrolling perspective, from the initial loading perspective, but we only will have numbers as soon as we have it deployed because locally, I must say, the measurement is quite hard always to get proper numbers there. So I would rather want to wait until we have it on gitlab.com. Any more questions? Cool, then I counted a five, a four, a three, a two, a one and thank you very much for listening. Thanks again to the whole frontend team for all their contributions and your hard work over the last weeks. Have a really nice Friday and enjoy your weekend everyone. Take care.