 Good morning, good afternoon and good evening. My name is Sarah and I'm your quiz host today. So we're starting with some very exciting news. It's time to announce the first one of the UX Research Quiz. So we took all the high scores from January, February and March as UX Research Functional Group updates and we drew a winner from the names. So I'm pleased to announce that Bob, you are the winner. Congratulations Bob, you've won yourself a pair of GitLab sunglasses. So if you're wondering how you can win some GitLab swag then you need to be an active participant in today's Functional Group update. So I've got to ask you a series of questions and I'd like to guess what the answer is by entering your choice A, B, C, O, D into the chat window and you need to do that before the countdown ends. You can only guess once per question or you will be disqualified. Keep a note of how many answers you get right as I'll ask you to post your scores on the chat window a little later on. So what's in it for you? Now as we've entered a new quarter, we have a new prize on offer. You can win a highly desirable and highly functional GitLab water bottle. All you need to do today is correctly answer two or more of the three questions that I ask. And if you manage to do that, you'll gain an entry into the prize draw in July. To take a deep breath, concentrate. I'm about to ask you your first question. So in my last update, I explained that the UX research team had created a survey to test some assumptions that we had about operations engineers. And as a follow-up to that survey, we asked a couple of users to speak with us in more detail about their answers. And with the aim of understanding what we could improve or add to GitLab to support them in their job roles. And as you might imagine, a monitoring solution is crucial to those working in DevOps for what did users want from a monitoring solution? So I can see a lot of these. That's good. Oh, one B. Couple of A's. Cool. Okay, three seconds, two seconds, one second times up. If you said D, all of the above, you would be correct. So the majority of people we spoke to tended to track deployment and application monitoring through two different tools. And subsequently data had a tendency to be unreliable due to thinking issues. So being able to see the effects of a deployment on application health on the same graph, that's both pre and post deployment, would allow them to quickly identify whether an issue has occurred as a result of somebody changing code. And again, the majority of our interviewees discuss how they are part of an on-call rotor and they receive alerts regarding application failure to their phone. So an end system is used to pull data from the various operations tools, but that end system isn't always reliable. So interviewees reported that alerts sometimes got stuck between tools. So the alert didn't reach the end system or between devices. So the alert reached the end system, but it wasn't pushed to mobile. Existing community support is crucial as it's good to investigate how other people are using monitoring tools. And it saves the need for people to reinvent the wheel and build things from scratch. They can just adapt what other people have done. And most importantly, these are all not like standalone requirements, the people we spoke to want an all-encompassing tool that can do all of these things. So question two, based on what you now know about DevOps engineers and what they want from a monitoring solution, what do you think is one of their biggest pain points? So A is going strong. Okay, three, two, one, time's up. If you said C, inability to choose the tools they want to use, you'd be wrong. So from all the research we've conducted so far, the majority of DevOps engineers have the freedom to choose what tools they use. If you said A, too many notifications, which a lot of you did, you would be correct. It was clear from both the survey and interviews that we undertook that DevOps engineers feel they have been bombarded with notifications from the various tools that they're using. So due to the nature of their roles, it isn't as easy for them to just simply switch off or ignore notifications as something may require their immediate attention in order to prevent or rectify a problem. So users discuss the possibility of waiting notifications. They'll still receive the same amount of notifications, but perhaps as a clearer way to distinguish which notifications are more important and which should be read immediately, versus those which could be read in bulk at the end of the day. So question number three. I have a co-host today. So Catherine, over to you. Yes, hello everyone. So we recently conducted an internal survey regarding the ways that engineering team managers are handling issue assignments and their workload. So what was the top challenge faced by the teams who completed the survey? Okay, I'll give it five more seconds. Five, four, three, two, one. If you selected A, you'd be incorrect. So the answer was C, both of the above. The top answers in general were capacity and predictability, but also followed by communication with other teams. So these challenges arise for a number of reasons, but can often be attributed to shifting priorities, lack of visibility into what is being worked on by others, or delayed decisions on critical aspects of the product. So while the topic of team management requires broader conversation for any changes to be made, we're aiming to improve the process of scheduling, assigning and tracking issues using issue boards in 11.0. Back to you, Sarah. Sarah, you're muted. Thank you, Catherine. So that's actually all our questions for today. So please now total up your stores and post them into the chat window. Whilst you're adding up your scores, I'm going to share a little bit about myself and what Catherine are working on. So I'm investigating what areas of GitLab.com are areas of friction for new users. And we're also trying to find out why paid users typically churn, so that might mean they downgrade their plan or they leave GitLab.com altogether. I'm also looking into how easy it is to add an SSH key to your GitLab account. We found that a lot of people are searching for SSH in their documentation, so we want to understand why that is. Catherine is currently investigating a way to create a searchable archive of UX research. So all our findings are normally captured within issues in the UX research project. However, the amount of completed studies has grown. We've had a few comments that it's quite hard for people to find research that's relevant to what they're working on at the moment. So we're trying to make this a little bit easier. And Catherine is also digging into the expectations users have and what it means to be participant within an issue. So it looks like all scores have now been posted. So well done to all those who scored two or more. You've gained an entry into the prize draw. So I'm happy to take any questions about the research we're currently working on, all that we've done. Hi, Sarah. Great update. I was wondering if there has been any research around like what's preventing people for adopting a broader range of our features, like what would prevent someone from adopting CICD or some of the new security features if they're already using a different part of GitLab. We've not done like a broad scope. We tend to concentrate when we're doing a research review on a particular area. So we might do something that's just related to CICD, for example, but we haven't done a broader investigation into why they might not be adopting it. But if you like that piece of research, just raise an issue in the UX research projects and we could definitely look into it. Okay, that's it. Thank you very much for taking part. Enjoy the rest of your day.