 Welcome to the product update of June 20 which is today. It's a great, great day because it's only two days before the release. But before I start talking about the upcoming release and a little bit about the one afterwards, I want to address something as I always want to address something else besides what is coming up. And that is feedback. It's super important to share your feedback. And you hear this all the time and there's a lot of slack channels to do this, but I can't emphasize enough how important this is. If you have any kind of feedback about KidLab, the product or the process whatsoever, let someone know or preferably, I think I have a slight on this, find or create an issue and then being a product manager. The reason for this is that you have valid opinions, right? So we usually deploy the new versions of KidLab early on KidLab.com so you get to try things. And your opinions are usually very important because you're one of the first people to try it. You're using this to do most of your work or you might be speaking to a lot of customers. It's hard to overemphasize how important it is that you share your feedback. So if you have any kind of feedback from yourself or from a customer, find or create an issue or in the KidLab C issue track or KidLab EE and then being a relevant product manager. If you don't know who to ping, there's a really clear guide there in the product handbook and you see exactly who you can message. All right. Now to the cool stuff. KidLab 903. Thursday we're releasing KidLab 903. And as usual, it's an amazing release. I'm pretty sure it's the best release we ever did. And this time, there's some such cool things. I'm really, really proud of us, the whole team of delivering this. It's really cool. The first thing is KidLab code quality. And it does exactly as it says. I have to say the first large part of this, almost all of it has been built by Dimitri by himself for a few months, which I think is amazing that he still does this. But what it does is it uses the code climate CLI to give you an idea of the quality of your code. So when you're doing code review, normally you look for a few things. Does it implement what we want to implement? Does it do it in a correct way? Is it readable? And part of that work luckily can be automated nowadays. For instance, checking for complexity or checking for certain style errors. And using this feature, using KidLab CLI, you can say, oh, I want to check for this kind of style errors. I want to check for these kind of things. KidLab will then report to you in the merge request, whether the changes introduced in the merge request change the quality of the code. So there's a really powerful way of getting a first hit on that code review that you want to do, getting a first overview. I think it's extremely, extremely cool. I'm very proud of us having delivered something like this and built it inside of KidLab before you had to purchase additional products and you have to integrate them. And I mean, this works so much better. It's available in E-Startup and E-Premium. Super excited about it. Next one. So you're all very aware of KidLab CLI and the whole pipeline, pipelines that you have inside of KidLab CLI. But what we had until now restricted you to have a pipeline in a single project. Or at least you could do things between projects, but there was no way to visualize it. So it was very hard to see how one pipeline affected another project. And this is the first step in consolidating that, in bringing the pipelines of different projects together. So in this way, you can see here, in this case, for instance, you have the KidLab Shell project that's linked inside of the KidLab CLI. And you see the status of that and how that affects the entire pipeline across projects. Super cool feature. And it's the beginning of something very huge. Having the ability to build something out of multiple projects is essentially what many projects do. So visualizing that is extremely powerful. And I mean, this is super cool. Enterprise is in the premium, this one. Segian S, regarding the code quality, Segian, is a JSON outcome shown like this whereas it has been fixed. As far as I know, this is how we show it, but there might have been some changes. It would be good to check, but I think this looks all right. And I would be happy if we make it more fancy. Next up is the conversational development index. So say that you're using KidLab. Most organizations started to use KidLab initially because they just wanted to have their source code somewhere. And at one point, we integrated KidLab CLI and we discovered, wow, it lowers the threshold so much. It's so much nicer to have things in a single product that we started to think about the benefits of having a single tool. And over time, now we have this whole framework, of course, of going from IDE to production to getting feedback through monitoring and then you cycle all the way back. Now that IDE is really nice, but if you're a large organization and you've not rolled into this magically like we have, then getting an idea of how well you do or getting an idea of this entire scope can be hard no matter how usable our product is. So the conversational development index gives this to our users. So what it does, right now if you're an administrator in the future, it will bring it to more users, what it does is give you an idea of how well you're utilizing specific parts in going from IDE to production or every single part of KidLab and how you compare to other organizations using KidLab. And it gives you a similar index. So it's very easy to consume, right? You just see, oh, I'm doing this well. And if you're doing better, you'll have a higher percentage, if not a lower below 100. So you know that you can improve. So if you look here at the screenshot, what you see is that, oh, this organization is using service desk, but the average, the issues created per active user is a little bit low. So maybe, and this goes back to the first thing, is that maybe they're not creating enough issues, right? Maybe they're not jumping enough when someone has an idea or has feedback. And they can use it in a way. And what we do is we link to resources that can help these people, these people that can help anyone to improve in this particular aspect. I think it's a very cool idea and it fits very much within our thinking of psychoanalytics. And now we have the Conversational Development Index. And it also helps us help our customers because we can say to them, hey, we see that you don't score that high. We can help you. Let us teach you where it can be better. All right. As Simon actually asked, what happens if they aren't using our issues? For instance, the third party tool. Well, Simon, in that case, it will not show there, right? It will just show a very low percentage. In my experience, what actually happens is that larger organizations never completely not use any part of KitLab. Because we make the threshold to use a different part so incredibly low, what you see is that adoption slowly starts to grow. I know, for instance, one customer of ours that decided to not use KitLab CI and slowly but surely KitLab CI is pushing out Jenkins in the organization because it's more powerful, it's faster, it's easier to use. So in the end, they will see that this starts to grow and they will want to adopt this. But yeah, if you're not using it, of course, the score will be fairly low. All right. Centralized Audit Log. So conversational development index is for all versions of KitLab available. Centralized Audit Log only for Enterprise Edition Premium. So we had audit features in KitLab for a while and they were scattered throughout the application. They were not very detailed. We made a simple, well, simple, powerful audit log that you can log in, you can filter and sort. And it's available to administrators. We record some or user actions and that's what it is. It's hard to overstate how important this can be to organizations because as you know, all organizations nowadays are software organizations. So if you're building cars and something breaks down, you have to be able to tell what happened and why did this happen. And a tool like an audit log gives you the ability to go back and see exactly who changed what and why did it change that? Why did someone get access to a particular resource and made a particular change? So this is very important. It's very important to our customers. I'm very happy that we made this improvement even though it might seem a little boring at first. It's actually very important. All right. And then there's a gazillion other changes. And actually, this list is constrained by the font size which I couldn't change for this template. It was actually much longer and I had to like select which one I thought were the coolest and it was very, very hard. So we are starting to improve the settings pages. Setting pages at GitLab are a little bit messy. And we started with the repository one where we grouped them. And we looked at Slack. They do this very well. So it's very easy there to now find the right settings. We now have quantified performance impact. That sounds very magical. But what it says is that GitLab just tells you, hey, this merge request, it decreased memory usage. And that is literally what the merge request will say. And I think that's a very powerful idea. It builds on top of the previous things that we introduced, which would say, this is the change in memory. We now have inline editing of the issue description. So if you edit an issue, it will just stay in the same place. It's a slight change, but it gives you a much better experience. So I'm always happy to highlight these kind of things. The issue board backlog in closed columns, you can now fold them in. So if you have a particular use for an issue board where you don't want to make use of the backlog or the closed columns, just fold them in. There's highly requested for all of those people that daily ping me, why don't we have X or Y on issue board? We're working on it. There's a lot of changes coming, group issue boards being one of them. We translated the project into repository pages. So you know, we're working on translation. So very happy with that. We improved subgroups. So now if you look in the groups view, you actually see them as little nested folders. It's very, very nice. Another very cool thing that we started to do is parse particular files in the file view. So if now you go in the repository and you look at dot GitLab CI handle, it will say on top where it's a valid file. So previously there was a little bit of a pain to do this. Now you see it right there. If you have a license, it will say what the license is and you can learn more about that license. So very nice feature. And I hope we start introducing more of these kind of things. And as I said, there are so many more cool things. You'll see the release post, but this is really another release to be proud of. So I'm going to just highlight a few small things about GitLab 9.4. We're still working on it. So it's all very much still up in the air. That's why I will leave it small. We're shipping finally related issues. It slipped two releases, unfortunately, but we'll finally have related issues in enterprise edition starter and enterprise edition premium. And this will be the first step of introducing relationships between issues. So this one will just say these two issues are related in the future. We'll add specifications, right? You can say these ones are blocked or not. But this is already important because if you have very long issues with a lot of references, it can be hard to discover which one are actually directly related to this issue and which were just referenced for some other purpose. So you explicitly relate issues. We're adding protected environments, which is similar to protected branches where you can say only particular people can make changes to these environments. And as we are retouching more and more environments from branches, this becomes very important. We're adding group milestones. This is because we want to have group issue boards. So having group milestones is a good part of this. And it will make it much easier to work with milestones across projects in a group or multiple groups as we have now. We're finally adding discussion threads. So right now you can start a discussion already in an issue, but you can start one from an existing comment. It's a little bit silly, but it was the smallest iteration that we could do. So it made sense to ship it. But they're fixing that and making it much smoother. And in the future, you don't have the option anymore to say, I want to comment on the discussion. Now, every comment can just become a discussion. We're shipping Postgres HA. Now, I think I've been saying this every release for a long time, but we're very good on the way. So I'm just going to leave this here. And now something super, super cool. We've been working on a new navigation in GitLab. And for a long time, people have been saying, well, the navigation, is that a weak point of GitLab? I disagree. I think it's great. But there's a lot of room for improvement, especially with subgroups. It's very hard to get a context like where am I now? Am I in a group? Am I in a project? Where exactly am I? And how can I navigate to the most important places? One of the things that we saw, for instance, was that issue boards was only found by one in six people when we asked them to find issue boards, right? It's because you have to go to issues and then you have to click on boards. Well, that's not a sustainable situation. So we're working on the navigation. And in 9.4, you'll be able to opt in to the first iteration of that. So it means that if you want it, you can try it out. It won't be the final one. That's why we're not shipping it to everyone. It will be a big change, a very disruptive, but you can opt in. And I actually have a sneak peek for one of the mock-ups made by Chris here. I think it looks pretty cool. I'm a big fan of bright colors. So that might have to do with it. But here, you can already see. I'm not going to go deep into this. We'll make many changes to it. I am also not the one creating this design. We have an amazing UX team that's been doing that. But I mean, it's super exciting to me. This will just highlight so much more of kitlab and it will bring important features much more to the service. And there's almost nothing more important than that. Making great features accessible and usable and making users aware of them is the only way we actually get to use them. And if people use our features, then people like our product. And that was everything. I think let me know if you have any questions. And I will have a look in chat for any upcoming questions. Let's see. What is the difference between those? I and question mark, I can see in the conversational development index. That's one will link to a resource and the other will just explain what we're actually measuring there, I believe. Let's see. What else? A Portland asked, how does the lead determine? Like, how do you stack up to other users? Well, we only use data from the usage thing, and it will only work if you're using the usage thing, meaning that the data we get from everyone is what we compare you to. So it's yes, it's a benchmark against the score from all users. But most of the scores we normalize in some way, right? So we compare it to an active user. So it's not biased by the size of the instance. Of course, it's not one on one. But without people giving us more specific data about the organization, this is the best we can do. And it's pretty good. Well, we start to say teams that use all are X percent faster, anything like that. That's a great idea. And it's something I've been thinking about. We don't share the data yet. So we don't have access to the psycho analytics data yet. And so we can't actually say this, we can't actually correlate this. I'm sure that's the case. And that I think is where we should be going. Let's see. I'm going to change the slide. No matter how cool it is, we give it literally slows on the computer. And would it be possible to add to the conflict features into Salesforce for existing customers? In fact, Peter, we are doing this at this very moment. So we're working on making sure this kind of data is all there. Andrew asked, yo, what's the markdown presentation to use? It's called back set. It's the best. It's very, very good. And it's very powerful because if I just change slides, I can just change the theme and then everything will look different. So that's, that's very nice. I like it a lot. It's very much worth this money. It's like 15. The new audit log is the activity also reflected in the application logs. Brian asks, so this is actually not an application log. We log it in the database. Ask Mike and ask Mike for more, more detail. Mike Bartlett regarding getting coffee in the Salesforce, Victor puts the link. Jacob says, what moonshot are you most looking for it to do or your most desire? That's a good question. I'll think about that and answer the next questions first. Cortland, can people are not sharing users data still make use of the conversational development index? No, they are not able to do that. And all right. So the moonshot I'm most looking forward to our most desire. I have several. My idea of the future is that if you're building any kind of applications, application, you don't have to worry about deploying things. So the evolution of auto deploy to me is the most disruptive change we could possibly make to the industry. Just the idea that I push a project and it just works. It just deploys and it just works. And I don't have to think about it. And if I want to scale up, I just don't get left to scale up. But if I want some control, I can just edit that as well. And that is so powerful. I also love things like having an IDE inside of GitLab and having everything be real time. But the idea of really making enterprise great, like complex applications easy to deploy. To me, that's the ultimate thing because programming is creating something new. And the only big threshold we have now is actually sharing that with the world because it's a pain to deploy. So making it easier I think is the ultimate goal. And I think we'll be able to do that actually. I think we'll be well on our way. All right. I see no more further questions. So you got three more seconds. Otherwise, I'll end it here. Three, two, one. All right. Thanks, everybody.