Hi, my name is Peter Marie de da Silva and I am the senior product designer for the source code group in the create stage of get lab.

So today, I'm going to share with you the issue or the work that I'm excited about in the 13.2 milestone, and that is the ok are that we're having this quarter to improve the livability of marj requests to refine the experience of one of the main driving product areas, and so, as part of that okay are. One of the key results is to validate the current lovable category maturity rating of code review, so code review is one of our product categories, and today the we have rated. We have self assigned a maturity rating of lovable.

We our maturity rating. You can see them in this page. We have different maturity, levels from plans, minimal, viable, complete and lovable. Lovable is the top level and, as you can see here, code review is that the loveable maturity rating, as well as a few others, and but this maturity rating was self assigned, and what we want to do now is validated with users and based it.

On actual user performance of people using the features that are inside the code review category so to do that, we're going through this process called category maturity, scorecards and basically, what we will do is define and recruits users that we feel are representative of the user types that are the main users of the features and have them go through a bunch of scenarios to see how much they, how they score the abilities of the features, the ease of use if they have, if they are successful in completing the tasks.

How long do they take to complete the test and what errors do they encounter, and so to do that? I created this research issue which currently the details are confidential, but I can share a little bit of that at least the top part of the issue without giving too much away so the the three user types that we're targeting our engineers non engineers that contributes or review changes to code our documentation. So these could be people with job titles like managers, designers or writers.

Then we also have technical roles that are responsible for setting up project rules, work, full rules and processes for the team and each of these user types map to specific scenarios which I have drafted in this working doc that you can see here. It talks about the different job to be done that we're using and also what are, the different scenarios that we would like for participants to go through and test the features. So so yeah, that's that's! Basically it that's.

What I'm excited about right now we're in the recruiting phase and next we will conduct a pilot session and then conduct the actual testing sessions so for the testing sessions and in this category maturity process. One of the things that we have outlined is that we need to recruit five participants from each user side.

That's the ideal number and, as I showed you just now, we have three different user types, so that would be 15 sessions and it would be very difficult for me to moderate all of those 15 sessions so I'm reaching out to anyone. The UX department netiquette lab to help us with this, and to do that, you can go to this issue which I'll share in the in the key cough updates issue and- and you can volunteer here, we have a thread going on here.

You can volunteer to moderate one of these sessions saying what is your availability? What is your time zone? How many sessions you're able to moderate and also you're telling the calendly link, which will allow people to book a session with you and so more participants? We have the easier, it would be the easiest it will be to to run these sessions and we will be able to share the workload. So so. Yes, that's what I'm excited about thanks for your time and yeah. Let me know if you have any questions or feedback bye.