 Okay, it's the top of the hour and a clock. So I'll get started. My name is Sean McGiven. I'm the lead for the discussion backend team at GitLab. And this is what we've been up to in the last five weeks since my last update. We shipped 9.5 almost a week ago now on the 22nd of August. We didn't have a huge amount of capacity for that in the backend part of the discussion team. So we didn't ship any big features. Some things that we did ship that are awesome is that the Jira settings are now simpler. Previously, we asked you to enter a project key, which is a unique thing in Jira, which is like the prefix for all your issue IDs on that project, but we didn't actually need that or use it in a bunch of places. And it was kind of confusing about whether you could only use it with that project when you can't, Jira integration is actually a bit more flexible than that. So Yarka fixed that. Also, Oswaldo made a really cool change, which is that before, we managed merge request locking using the database. So it would trigger a background job when you clicked on merge. That would update the merge request as locked. It would then try and form the merge and then it would unlock it if it failed or if it succeeded. But sometimes it didn't get unlocked and we had a limit of 24 hours, which you had to wait while it was in that locked state. So Oswaldo has made a change that we track the actual ID of the background job. So we can track it more closely and we can see if the job exists or if it's no longer present and then we can unlock the merge request that way. So now it will be stuck for at most two hours, but we still hope to improve that even further. We also had quite a big background migration, which is a migration that we run asynchronously and that took in total a couple of weeks on GitLab.com. So I think in sort of just runtime, it took about five to seven days, but now all merge request diffs and commits should be in the new format on GitLab.com, which lets us implement some new features, which I'm going to talk about in a second. One thing that we were hoping to ship last month that we didn't quite make it was group issue boards. So that's I think the back end for that is pretty much done and the front end is getting there now. Felipe and Simon have been doing really good work on that. Simon's also been a release manager for 10.0, so he's sort of had to split his time between the two, but it's coming along really nicely and it's going to be super awesome. We're going to use it for GitLab development, which is in my book, the highest bar for a feature to meet. The one that we actually use ourselves all the time is the super cool thing. The other thing is in 10.0, as well, though again has been doing some really cool stuff, so we're hoping to show link to the Jira development panel by pretending to be GitHub Enterprise because we can't integrate with Jira any other way. So that should be in 10.0, which is awesome. So we just mimic GitHub Enterprise's workflow and API that Jira uses. Yaka has picked up an old community mode request that never got finished to allow people to lock an issue so that only project members can comment on it, which is a long requested feature and one that thankfully we don't have to use too much for ourselves, but it's going to be really useful for smaller projects, especially. Valerie is working on speeding up mode requests with lots of resolved discussions because when you have lots of comments on the diff, we go and highlight all those, even if they're collapsed by default when we could just get them when you expand the diff. So that's going to be cool and should save a lot of time. Rebase errors to users, Douglas is finishing that up and a really cool community contribution at the end here is that in our filter bar, you'll be able to filter issues and MRs by your emoji reaction to them. So if you like starred them, you can search for all the issues that you starred or all the ones that you gave a thumbs up to or all the ones that you gave a thumbs down to if you're the kind of person who goes around giving thumbs down to things, which hopefully most people aren't. So yeah, that's super cool. It's by a community contributor and it's a really great change. On a team level, Janine's no longer with GitLab. Her last day was Friday, which is quite sad, but she's going to do something very exciting. So that's cool for her. Mikael has joined, he starts today. So the timing was coincidental, but that gives me a lot to talk about here. So the first thing he's working on is a first-time contributor badge so that when someone submits their first emoji request to a project there's a little badge that says, hey, this is this person's first contribution. Maybe be even nicer than you already would be. Obviously everybody on the GitLab project is extremely nice anyway, but be even nicer because it's their first contribution. And then beyond that, we haven't really thought it through because his first day was today, but he will be working on other discussion things. My next point on this slide is actually slightly updated. I think we are hiring more than one backfill for platform and one more back-end backfill developer for discussion, but we've still closed the back-end developer job opening just because we have so many awesome people in the pipeline that even with more openings, we're still going to have to reject some great people just because we don't have enough physicians available. In future, Felipe and the front-end team are working on a really cool feature which is to let you comment on an image diff. So just like pick some coordinates in an image and click there and add a comment thread there, which is really cool. Something that was enabled by the merge request schema changes that I mentioned earlier was that we can now easily show you the commit. Sorry, if you look at a commit, we can show you which merge request added that commit. So I was actually waiting for the, see some celebrations going on. I was actually waiting for the background migrations to finish, but the same community contributor as before, here at Yuki Sato, just picked this up and implemented it. So we're working on getting that merged. It's super cool and it's just really nice that we can finally do that. And the final thing is we've still got a lot of areas to improve performance-wise. One thing that's been bugging me particularly lately is that when you push to an open merge request, updating that merge request is slow. So we have some inherent delays in that it gets processed in the background and we have to wait for it to be queued and to be pulled from the queue and to be executed. But even when it's executed, it is still slow. So we can fix that last part easily by, I say easily, we can fix it as a development team. It's like within our area of expertise by profiling it and making it not slow, basically, is the process there, find slow thing, make it faster. So yeah, that's it. I'm just gonna go through the chat quickly. And if anybody's got any questions, you've got another sort of 30 seconds. So Kim's excited about group issue boards and yeah, Gistly team will love it. I think every team will love it. Even back-end teams and front-end teams because we work on C and E and just seeing those issues together and for product managers is really useful. Tone, yeah. So for the locked, the issue that reopens itself that Tone's talking about basically doesn't issue on the GitLab CE issue tracker where someone's written a script that reopens the issue. And once we implement the lock issue feature, that script won't work anymore. But for now, if we try and close the issue, it just gets reopened automatically. So we can only close it once we've implemented the feature. It's a really cool way of demonstrating that we don't have the feature. And Kim also asks, is the first time contributor project per project or per user? So it's per user per project. So it's for your first merge request to a particular project. And it only shows when you're not a team member because if it's like a company scenario where you just joined the team and you got access to the repository, it's less important, right? It's more important for open source projects where you can fork it. But we could change that in the future. That's just how it's implemented at the moment. So yeah, I didn't see any other questions. So thanks very much for your time, everybody. I will see those of you who work at GitLab in 21 minutes for the team call.