 Cool. We'll give it 10 more seconds in case others are going to join. I guess Vinny and Robert are not going to be able to join. But yeah, there's an agenda for the call. All right. So let's, without further ado, let's get started. So welcome to the April court meeting call. So we might have one more person joining. Hi, Remy. How are you? Good All right. All right. So yeah, we're just getting started with the agenda. And it looks like you're always joining too. Hello. Good morning. Good morning, everybody. Thanks for joining. So yeah, we're good crowd today. So we have a couple of people that can't join. But I think we have a good forum here. So just several things on the agenda. Starting like sometime last month, I started sending out the survey for first hand contributors when I was thanking them for their first MRs and sending them their gift. So the response rate has been great. I mean, you probably, if you, in case you've seen the slides, there are already 30 people who responded to the survey, which is great. So usually like a survey, the response rates like really hard to predict and hard to get a good number. But I was pleasantly surprised. So we'll go through some of the data that, well, we'll go through the data that we've gotten so far. And you've probably seen the Twitter posts or message on Gitter about contribute for prize. We'll have a brief discussion on that. And speaking of Gitter, there's there was an issue, I think, George, that you opened about remain renaming the channel because there's a confusion about the purpose of the channel, I think, which is a good point. We'll talk briefly about contribute, which is coming up in about four to five weeks, I guess. I mean, I think some of you won't be able to join, but we'll have a brief discussion on that. And as we talked about in on the Slack channel, there's the schedule for the future court meetings. Anything else that we're missing here on the agenda or just keep going? Okay, so the survey results. And I'm glad, like Vinny, who's not here today, he I think he sort of seeded that idea. And we have like created a short survey about eight questions. And you should be able to see this see the survey results in this link. If you're not able to please let me know. I thought I created a publicly viable survey result. So let me know if you're not able to see it. But you should see something like this, it's it should be the same link. So for the first several questions, these were, you know, multiple choice type of questions, you had a couple of options on things like, you know, how long did it take you to set up the GDK? And were you happy with the response time so on and so forth. And the other half were more qualitative questions about what were some of the challenges when your first major contribution. So quickly go through these on the question of the GDK. I mean, I sort of expected this because I mean, a lot of people some of the contributions were more documentation related for that. Obviously, you don't need a need a GDK. So about half the people said they didn't actually have to deal with GDK is what they've said. And the other half who work with the GDK, surprisingly, the amount of time it took them to get them going was was was lower than I thought it would be. So which is good. So people able to figure things out in a couple of hours to get things going. So that's the question on GDK. The next one is, I mean, were you, you know, pretty happy with the response time from the GitLab team members and vast majority of them are happy to see that they said no. They said yes. So I think it looks like only two people said they weren't happy with the response time. Reading some of the subsequent question that looks like I don't think this was like the initial response time. But I think some of the MRs for one reason and another took a while to get them merged. So I think that was their concern. I think at least the first time response, I hope was was reasonable enough for everybody. But regardless, I think pretty positive in terms of happiness with response time. And in three was on on the feedback from from reviewers. And I mean, none of them said they were not happy with the feedback they got from the GitLab team members or or other people that were participating in the review or discussions, which is good. So so far so good. And the other question was, you know, did you were able to get the help that you needed in case you needed them? And again, the vast majority of people said they were able to get help and the other responses, seven of them said, I mean, they actually didn't need any need any help at all in terms of their MRs. So again, pretty positive, which is good. And so the rest of the survey with the exception of the last one, I mean, the last question basically asked, like, was you contribute again? And you know, fortunately, everybody said yes, they would definitely be interested in coming back and contributing more, which is what we want to see. So the questions like next several questions like why you decided to contribute. So these were I mean, texts. So I kind of summarize it in the slides. Difficult part of contributing, I try to put them into different categories. And improvement, I mean, suggestions for improvement to help to contribute contribution process. So these were more like a descriptive answers, not multiple choice. I try to summarize them in the slides and the last question I mentioned already. So I'll go back to the slide here. Reasons for wanting to contribute. I mean, I saw broadly three reasons. I mean, the first one, I think this is similar to what a lot of you started contributing like you guys have been users of GitLab and found things that needed fixing, whether it's just documentation or some of the features that people didn't like. So that was pretty common answer from several people and somewhat related to that where I mean, they've been a big fan of GitLab. So I wanted to find ways to contribute, which is a good thing. And a few people said they actually had a feature they wanted to add a feature to support their needs. A specific use case or a specific needs they wanted to address. And one way to do that was to directly contribute. So I think there were a couple of people who mentioned that as a reason. So I don't think there were a whole lot of surprises there. But I mean, feel free to go through. I don't think there are like 30 answers necessarily. I mean, some of the people skip some of these more qualitative questions. But I mean, these are the sort of the broad themes that I saw in terms of why people wanted to contribute. So I don't think there were any surprises there. But let me just quickly pause here and see if you have any thoughts or questions. I'm not sure if you had a chance to go through the answers that people provided. But, but yeah, I definitely didn't see any any surprises here. I have a question here. Yeah, it's a little bit unrelated, but I don't have their missions to the Sorry Monkey page. I don't. Yeah, okay. Okay, is that true for others as well? Or I opened that link. Yeah, on the screen right now. And I got you do not have permission to see this page. Okay. Open fun for me. Same here. Okay. Hmm. That's odd. So I wonder if this is like blocked in because I know like in some countries, like, I think I think it was China that Survey Monkey may have been blocked at some point. So I don't know if that's the case here with you, Vitaly, but I can save the file and send it to you if that helps. So I'll just try to use VPN, something like that. Okay, yeah, sorry about that. But cool. Okay, any other comments or questions on that specific question? Or if not, I'll guess I'll just move on. And the most difficult part of contributing as a first time contributor. I mean, some of these weren't that surprising, like if finding finding an issue to work on, I mean, that's sort of the common feedback I gotten from people. And so setting up the GDK, I mean, this was brought up by like a several people, which was I assume this these these came from people that took it took more than just a couple of hours to set up the GDK. So I mean, I've gone through this like personally, based on my experience. And I just found out that something's wrong with my GDK that I didn't know about. So I was trying to fix it. So some of that could be like a similar experience that people have been having. So something that I need to talk to GDK team about. But I'm sure like a documentation and others are some of the areas that we can improve. And I think there's there were some questions that were posted on Gitter over the past couple of weeks as well. Some people some one individual I think was having difficulty getting things going with the GDK. So that definitely is is concerning. And I mean, the third one, I don't think it's that surprising, because I think this is what I mean, people go through is as you work with like a new tool or new new community. So the work processes and tools and etc. are not familiar. So that's something we need to get used to. But those were some of the feedback on difficult, what, you know, the most difficult part of contributing. I'll pause here here as well to see if you any of you have any feedback. Not sure if you have any thoughts on on the GDK issue on on how to make that easier. But So can you hear me? Yeah. So I guess I've you know, this is been I've done a lot of contributing on the documentation side and like probably only a little bit really on the the GitLab side. Right. So like one of the issues that I personally have ran into with the GDK is like, I'll spend more time setting up the GDK than it does that takes me to actually do what I'm trying to do, you know, trying to test that I changed in GitLab. Right. I mean, especially if it if it has to do with like basic UI type things. Mm hmm. So I guess that's just an observation. Like it would be nice if there was a less than, you know, two hour option to get set up and test something. Okay. So basically it takes more time to set it up versus like the time it takes to actually use it for testing or or anything else that you need to do. Yeah, I mean, if you're if you're going to set it up and you're going to use it a time, then it's certainly useful. But if you're like a one time contributor, and you're trying to fix like, I don't know, some basic problems and basic typo something, you know, actually want to test it and like, real code as opposed to make the merge request and hope they changed it correctly. Mm hmm. It takes quite a bit of time to get it set up. So I don't know if we have the setup right now or not, but I would think that there should be some way to have like some sort of review app type version of GitLab that people could play with. Okay. So yeah, that's an interesting idea. I mean, yeah, they're not available for Fox right now. So that's something that ideally we should be able to do that for security reasons. It's a bit hot. Yeah, and then I don't know if this is like a common issue with other people, like, I mean, once you install the GDK, like, I wish there was like a quick way to test it and make sure that it actually works. I'm not sure if there's an easy trick up for for doing that. Like, once it's installed, like, how do you I mean, I'm not sure if there's a way to like run some kind of a script to make sure that everything's set up correctly. It feels like you discover something when you actually try to use it like a later on. But I don't know if that's just my personal experience or others have heard or experienced a similar thing. But yeah, I think that's mostly how you find issues with your GDK by using it. I think I installed the GDK maybe not only once, but a few times in the three years that I'm here at KitLab. I don't usually have issues. So maybe it's luck. But yeah, I mean, please create issues if you have problems so that we can, so that we know what are the issues at least. And we can address them or document them. I know that there's a there's quite a there's a troubleshooting documentation in the GDK project where there are a bunch of like random issues that can happen. So I would definitely recommend to check that out. But yeah, otherwise just create issues I would say. Okay, cool. Thanks, thanks for me. I mean, actually this is something I wanted to do like when I'm with, I'm a contributor face to face with some people. I wanted some people to take a look at my installation and see if everything's actually working. But I might corner one of you guys during the rags and see if we can figure it out. But yeah, so that was sort of the feedback on that question. And then thanks for bringing that up. And let's see, let me move on here and suggestions for improvement. So I mean, first of all, I've heard this in the early days and not surprisingly this is still an issue. Make it easier to find who the reviewers and maintainers are. I'm basically, I mean, I try to triage new MRs and sort of copy the like, for example, product managers or engineering managers. So community managers know that it's okay to like ping those people if they're not responsive. But I think it's, I think we've done some documentation in our handbook of reviewers and maintainers that we probably, it's probably worth taking a look at. And the second one, so this came up in, I think even even in the previous question, people wanted a better, like documentation of the GitLab code base. So this is something I wanted to ask all of you about. Like, I wasn't sure how to like address this. Like, is this, I mean, I would assume, I mean, most of our code is, I guess, in Ruby. I thought like in Ruby, the way things are structured was like pretty standard, but I'm not sure if that's what the concerns are from the respondents or if you have any thoughts on that issue. Yeah, I'd also like to have better documentation about GitLab code base. But in the ideal world, the code itself should describe itself what it's doing. But since we're not in the ideal world, I think have to have to have comments in source code. And that's one of the reasons I faced when I firstly opened the source code. And I mostly didn't understand what was going on there, especially in Banzai, in Banzai model, when it's not easy to understand what's going on there. And as far as I know, some employers of GitLab still don't understand how it works now. So I think it would be very great to have some more documentation, inline documentation or some separate pages describing about how GitLab is built or GitLab in general or something like that. Right. Yeah, I think third one is somewhat related. I mean, this applies specifically to documentation, but I mean, I've seen this discussion happen in issues and other forums where they don't know how the creation of the documentation is actually done. So that's something I could talk to the docs team about. But I guess somewhat similar to how it's hard to understand our code base. Any other thoughts or comments on the survey? One thing, but it's not strictly related to this, is that what I find out personally is that contributing to GitHub C is quite easy. But sometimes if you need to also update other projects such as Gitaly or some related projects, it's not that easy. Because while they see it's well documented, the Gitaly part is a bit harder to find what you need to do, what you need to tweak. But that's just my personal point of view, though. Okay. Well, that makes sense. I think one of the answers for this question was also to use tools like codecrumbs. I'll put a link in the chat. I think that's something that we could try at least just to visualize the code base a little bit. You say codecrumbs, Hannes? Yeah. That was the one that was mentioned there, so. Okay. I see. Cool. All right. Thank you. Yeah. Anyhow, obviously, the survey will keep going out. I might tweak the survey questions. I might make some of the questions multiple choice after we get, if I sense there's a critical mass of answers or certain options that are popular. But at least for the next several months, I'll keep sending out the survey to first-hand contributors. But I thought it was interesting looking at the data. I mean, I was happy that mostly people were happy. It's probably because they're getting a merchandise from GitLab. But some of the suggestions for improvement I thought were pretty constructive. Cool. And then, yeah, obviously, we won't do this like every core team call. But maybe in the next few months, we'll revisit the survey results once we get more responses. Cool. So if there are no questions, I'll just keep, I'll move on. So contribute for prize. So you probably remember at the last hackathon, we labeled some of the issues as priority items during hackathon. And we had extra prize for people who worked on those issues and have the merger quest merged. That was pretty successful. I think we started with eight issues and five of them were picked up. I think a couple of them ended up being more involved than we anticipated. So at least one of them, I extended the deadline. I allowed that person to spend more than 10 days on completing it because it got pretty complicated. So what I wanted to do was to not wait until the next hackathon for people to work on some of the priority issues, but work with the product managers at GitLab to add a label, contribute for prize. So there's a sample query there on CE. I think there are about 20 or so issues that are labeled with that new contribute for prize label. So we have a GitLab Moleskine notebook for people that are working on those issues. Like the last time I checked, I don't think anybody was working on any of them, but I need to broadcast this a couple more times, I think, on Twitter and other channels. But obviously, I encourage all the core team members to look at those issues and and work on those issues that grabs your interest. And I also updated my handbook to add details on the contribute for prize. Let me know if you have any questions and again, I encourage you to start working on them. And I think for each of the product teams, I think we set a limit of let's only have about four or five of those issues at a time. We didn't want to create a long list of them. So there shouldn't be that many at any point. But we'll after a few months, we'll change the GitLab merchandise so people aren't just winning the same thing and getting the same merchandise over and over again. But he was on the blog already. I'm sorry. was on the blog already. For now, I just posted on the Twitter. So and I'm not sure if you saw a new blog post that I'm working on, it's supposed to go out next week. I'll be mentioning there on the blog post. So it should be going so that blog post should be going out in the next couple of weeks. But it did go out of the Twitter space. And I know a lot of people I saw a lot of likes and retweets. So there are a number of people looked at him. But yeah, it'll be on the blog next couple of weeks. Okay. Moving on. So the Gitter channel. So that's the issue there. Let me click on that link. So George, thanks for starting this conversation. I mean, there is still I mean, this this was an issue from the beginning, I think. So there are basically two main Gitter channels, one for community and one for I mean, basically GitLab HQ. I mean, GitLab HQ has a lot of traffic, but this where, you know, most of the support and using GitLab questions should go. But you do see maybe a couple of times away, people posting those types of questions in the community channel. And I think there are a lot of proposals and discussions on what should be named us to. And I think we settled on contributors. So basically, it'll be GitLab HQ slash contributors and also update the description. Let me see what the description right now is. It says chat about contributing to GitLab, but we can change the description to room for GitLab contributors. So it's a little bit more explicit on what the channel or what the room is supposed to be. George, do you have anything else to add there? I think this is it more or less. It has caused some confusion in the past, especially after a small change where we changed the default room name for a Gitter. And I think this got even worse because people were directed to the community channel at first. I think contributors sounds good. We can change that. I will only check with Eric if there is any usage of the GitLab HQ channel just because before remaining, I'm not sure if you agree renaming GitLab HQ also to the community default. Okay. Yeah. I mean, I think he has to do this anyways, right? Because I don't think I have the right to change the name, for example. But yeah, that's a good point. But yeah, before I do that, I mean, I want to make sure that other core team members were okay with moving forward with these changes. No objections. Let me get myself an action item too. Sorry, did somebody have a comment or question? So it looks like we have a consensus and I'll ping Eric. And so make sure there are no issues with making these changes. All right. Yeah. Thanks again, George, for starting that conversation. And we can move on. All right. So contribute. Yeah. Unfortunately, I mean, not all of you will be able to are going to be joining us in New Orleans in about a month. And I mentioned this in the core team channel as well. So we scheduled the so something that that's different this year versus like the last year. I mean, basically every dinner, like you were like all together, you're eating at the same place. So but they changed it up so that like on Sunday evening, like each group gets to have their own casual dinner in a smaller setting. And then you get to pick your restaurant. And so I mean, developer relationships team isn't large. But so we wanted to invite the core team members. And we also have two other community members that are coming to contribute. So all of you are obviously welcome. I mean, this is not mandatory. If you don't want to have dinner with us, we won't take it personally, but you're invited. And it's I forget the name of the restaurant, but it's going to be a local Louis, Louisiana cuisine. So the restaurant looks really interesting. So it'll be fun. So that's Sunday evening. And then also want to make sure that you you probably got an instructions and an email from Kersen about signing up for workshops and UGC sessions. I mean, if you haven't done that, please do that soon. And for so this is the last item is still work in progress. I mean, there's a discussion about having a panel discussion featuring some of the community members. I mean, you were on the panel last year with Robert and Takuya. But I mean, this year we might I might pick like a different court team members as an example. And George, Ben, I might talk to you if we decide to sort of go this route. It's I mean, don't worry too much. Like the panel seems like very formal, but it's going to be a casual conversation on stage and I'll likely participate. But talking to my colleagues in the marketing team later this week on what the format's going to be. But we wanted to highlight community members and contributors that are that are at the event. So that's that's being talked about. I'll share more details. And if I want to invite some of the court team members to the panel, I'll definitely let you know. We're not going to surprise you like we did last year with our court team members. I think they found out like they were to before. But we'll give you ample heads up on this if that's going to happen. So that's what's happening and contribute. And the last side of my head, I mean, so there are discussions on this about the future team me future court team meetings. It doesn't look like there are any issues like switching this to a day later in the week. So basically in Europe and in like Asia Pacific region or the far east of Russia, the meetings right now are on Tuesdays, but we'll just move it to a day later on Wednesday. Because Robert, that definitely seems like at least for the next several months, he's got a conflict. And it looks like it works for the rest of us as well. So and like we talked about last month, we'll cancel the main meeting because a lot of us will be at the at the contribute. So we'll just cancel the main meeting. We'll resume in June on a on a Wednesday at the same time. Yes, we'll keep the same time to just to make it easy. So I think that's it. Let me make sure that I covered everything. And thank you, Remy, for taking detail notes. It's making my job easier. Cool. Any other topics or anything else we need to discuss? Thanks, George, for adding that action item. Cool. All right. So I guess that's that's in the that's in the I'm sorry. That's it then. So we'll end the meeting about 12 minutes early. Sorry, it's it's a little late at night. I'm getting a little tired. So can't speak clearly. But right, well, thank thanks for joining the call. And I'll definitely see some of you in about a month. If not, we'll see you guys online or another meeting in June. Thanks, right. All right. Thanks, everybody.