 All right, with that public service announcement, I guess we can get started. Excited to have both Gosia and Jeremy from the GitLab Managed Team. So without further ado, Gosia and Jeremy, I'll turn things over to you so if you can introduce yourself and then start with the talk, they'll be great. Sure, sounds good. Great to see everyone here. Excited to kick off the hackathon today. So I'm Jeremy Watson. I'm a product manager here at GitLab. I'm primarily responsible for the managed stage and DevOps lifecycle. And I'm excited to talk a little bit about manage as a stage. Some of the categories we're involved in and highlight how you can kind of find notable and interesting issues that you can contribute to here at GitLab. That's a little bit about me. Gosia, over to you. Hi, my name is Gosia Xionak. I'm a backend engineer and a managed group. And I'm at the GitLab to help Jeremy put things into life. And I'm here to help you answer any engineering-excited question or just put things on my perspective. Awesome. Thank you so much. I'm super fortunate to be able to work with Gosia on a day-to-day basis. I am gonna share my screen briefly. So I guess the content for this conversation is really talking a little bit about manage as a stage and highlighting a couple of interesting issues and how you can find them to be able to find really awesome ways to contribute to the GitLab application. So manage as a stage is divided into four groups that categorize our functionality into different areas and categories. So the first group that I'm gonna talk a little bit about is the import group. And the import group manages categories that are importers, templates and internationalization. And whenever you're interested in kind of like a particular category, the best way of kind of like looking at and trying to understand that is our categories page that you can see in our handbook here. So right now I'm looking at about.gitlab.com slash handbook slash product slash categories. And this is the best way for you to get a kind of an overview of kind of like how our functionality is kind of split between different stages. And this is really important because it helps you kind of understand the different areas of the product to contribute to and also who to ask for help whenever you have a question on a particular issue. So we're scrolling down here, we have the manage stage and we're gonna start a little bit by talking about the import group. So here whenever you're interested in a particular area, you can see that they're split into different categories each with documentation links. And I think the import group, the category that's most interest to folks is really around importers and being able to import and export information effectively in and out of the application. You can generally find like whenever you're curious about a particular category, you can do a search under the GitLab project under a particular category name. So if the category of importers interests you, you can just search for category importers and then look for accepting merge requests and then be able to see a series of issues that are appropriate for you to contribute to. So importers, you can see that generally the themes around them are specific like importers that help us get information in and out of the project, the application. And I wanted to highlight like two really interesting issues. The first one of which is related to our imported functionality and adds a force option to allow important export to work more effectively. One challenge for users that use project important export is the fact that if we encounter an error, generally more often than not the entire import job fails. And one great proposed addition is to add a force option to be able to ignore some of these errors. That to ignore some like certain errors and continue with the import and allow like a partial import to actually succeed. I think this is, you know, a great great suggestion. It's an area of the product that like the import team hasn't been able to effectively get to yet, but this is definitely a little bit like a lot of problems and a lot of challenges that some of our users face when dealing with our import functionality. The other one other category I think is really interesting is templates. And in the application, we offer templates in a number of different forms. Project templates we offer like a number of built-in options for you to use when bootstrapping a project that really help you kind of get started and you can kind of see these generally in the template area here of the when you are creating a new project. I will let that spin for a minute. Here we go. So we go here to create from template and we see a number of built-in templates that get populated. And this is really helpful for instances and for users that are looking to create a project just, you know, with a simple Rails template or a Spring template. But one really great improvement would be that when you create like one of these, a project from one of these templates, you actually see like commit history from the GitLab team member that actually created the template in the first place. And a really nice improvement would be to just squash those templates, override the author and then just have a very generic like first commit message so that we don't get confused when you're creating a project and you see someone like ZJ in the commit history who's from the GitLab team and created one of the templates. So I think the import group is a really great way of finding a wide variety of issues that are related to getting started in GitLab around importers, around templates and also around internationalization. And again, you can find these issues generally by just searching for the category name that you're interested in and then also doing accepting merge requests. Cool. I'm gonna move on to the access group, which deals with authentication groups and users. So jumping back to the categories page, you can see the access group is responsible for those categories. You can click here on the documentation, you can kind of see both our documentation for that particular category of product as well as like the strategy of where GitLab is kind of allocating our development attention to. But I think that there's a lot of really great and important issues that we just simply haven't been able to prioritize that the community is really excited about. I'll highlight two of them here, which one of which is just allowing you to star groups, which is a very simple kind of UX improvement. Right now you can star projects and it's a very easy and simple way for you to be able to find projects that you're interested in either from like you created or your organization is created, but you cannot do that with groups. And at the moment, finding groups can be a challenge. You can, you have to bookmark them in your browser or scroll through a very long list of groups under your groups and a really simple improvement will just be allowing the same pattern that we have for projects, allowing users to start groups and subgroups and introducing a new section here in the dropdown to allow you to do them. This would be a really nice improvement. I've been excited about it. The community has been excited about it and we haven't been able to get to it up somehow. The other issue I'll highlight is just simply being able to disable the explore and help URLs, which are currently available and accessible by non-authenticated users. When you spin up a GitLab instance and you disable and most pages kind of require authentication, however, there are two URLs that we expose that don't require authentication and that's slash help and then slash explore. Some of the organizations obviously prefer to have everything related to GitLab be private and route everything to the sign-in page and require authentication for everything. And this would be a really great setting for those security-minded instances to keep them secure. So, I guess in closing, like the access group is really responsible for keeping instances secure and maintaining access to making sure that users can register and access the instance easily for a wide variety of identity providers. And there's a lot of really exciting, interesting issues here if you're kind of interested in that kind of thing. I think moving on from there, there's the compliance group which is a new group that we've actually created to specialize in like instances that are compliance minded. And generally these features and capabilities are generally directed at the enterprise. I think the most kind of contribution-friendly category is really around audit management which deals with like the audit event system and the application and how we track and maintain control over an instance. One like particular issue that I'll highlight which is in GitLab starter, but we are always accepting contributions is just adding more and more events to like our audit event system. This, for instance, just adds like, project repo setting changes to the audit events that are when like someone is changing the repository settings like around push rules that we're actually tracking those changes and making sure that we have an audit history for around those changes. So like I mentioned, this is an enterprise feature in GitLab starter. There is an issue where we're considering moving some of this down into core, but at the moment, I think this is a great area of the product that's always welcoming contributions and help make the application better. And I think lastly, analytics is the final group that deals with kind of DevOps score, code analytics and BSM. This is creating insights into GitLab around how people are using the application, how you can find bottlenecks in your software development lifecycle and ship software faster. And we see this with areas like the DevOps score category feature, which is currently called the con dev index, which tells you kind of how the instances utilizing GitLab at a high level compared to other instances. Code analytics, this is a new area and then value stream management, which is primarily around cycle analytics, contribution analytics and a new analytics which are called productivity analytics that we just released a couple of releases ago. And I think there's a lot of great features here, especially if you're a front-end developer. Like one feature that I'll highlight here is just around a lot of simple UX improvements around front-end tidiness and under contribution analytics, where we have just some design and front-end issues that kind of require some consistency and improvement. So I think that analytics, if that's an area that is of interest to you, especially if you're a front-end developer, definitely take a look at that category and these categories for interesting issues there. So that's really managed. That's kind of a highlight and a high level of kind of what we do as a stage, the areas that we focus in. And really how you can contribute as a contributor is just by taking a look, understanding those categories a bit better, find interesting problems to solve by searching for accepting merge requests and by either the group or subject label, like I mentioned before. All you can do is you can either click on this link for an example or when you're searching gitlab.org, search for the category that you're interested in and then also make sure that you check accepting merge requests to find interesting issues that are accepting contributions. And also I'll call up, please don't forget to check the group not own label for issues. There's a label that we use for issues that don't really have a strong owner in terms of a stage or a group. And this is also a really great way of finding issues that could use contributions simply because they're not being prioritized actively by the gitlab team. And you can kind of see a lot of interesting issues that are about 52 here around like retrieving uploaded files using the API, reflecting like the time zone throughout gitlab. All these are great improvements and because of the fact that they have this label, they're not being actually prioritized and we definitely welcome contributions there. And then lastly, if you have design or product questions, feel free to tag the PM for the relevant group in the issue. And you can generally find like the PM that's responsible for a particular area by again, visiting the categories page where I highlighted these categories before with the documentation strategy links. And you can see up here that the first person in the group is the product manager. So you can see that if you were working on like an issue that has access to group and you can find that generally by looking here on the right hand on the sidebar and noticing that there's a group access label that's applied to it. And most issues will have like a group label for you to kind of like look at when you're trying to understand who to kind of contact with a particular issue. You simply go to the categories page here, find the product manager that's responsible for it. When you click on their name, it'll take you to a page like this and you'll be able to click on this icon here to find their gitlab profile. And then you can see that my handle here is actor. So you can go over there and add mentioned me in the issue and I'd be happy to jump in and clarify whatever product or design questions you might have and get you unblocked. So that's all of that, but thanks a lot for contributing. I'm excited to kick off another hackathon and thank you so much. I appreciate it. Cool, thanks. And then I think Dennis just posted a question. Not sure if you probably didn't have a chance to look at it, Jeremy, but I think this also brings up sort of the, one of the points that you brought up. I mean, although like issue might be labeled or a specific group or stages, I mean, it's not surprising that, I mean, manage is very broad, right? I mean, there might be an element that's very relevant to manage anyway. So I mean, don't, I mean, my one feedback is don't get too encumbered by DACA groups or DACA DevOps stages. Like if other team members need to get involved, I mean, obviously well, but Gosha or Jeremy, I don't know if you have anything else to add to that, a specific issue or others like it. What I can say from my perspective, it's just, please don't be afraid of the vast code base of the lab because we've all been there. It is a very big project, but it is actually really easy to wrap your head around it. And like, don't be afraid to contribute because even if you don't know the project as well, we get you back because you will have like our best people to review your changes and have a very nice discussion about what's going on there and everyone is really willing to help. Great, yeah. And then I mean, the one thing I mentioned and probably every hackathon as well, it's completely fine to add mention somebody on issues or merge requests. I mean, just because you're not part of GitLab doesn't mean that people aren't gonna respond to them or pay attention. I think all of us have like a pretty strong open source background or passion for it. So like Gusha said, we know where, how frustrating it could be when there's a dead silence for a few days. So that's not a normal practice. People can be busy, but let me feel free to add mention anybody and then to get our attention. I mean, one, I guess, question for you, Gusha. I mean, this might be a little too broad or general, but I mean, you've done a lot of reviews for MRs from both community members and GitLab team members. I mean, what are some of the like a quick, like one or two advice that you wanna provide to community members as they think about contributing? I think the committee members have the same experience as any of us who just started with GitLab. So a bit of a fear of contributing to this big bit, just start with, I think the best thing is just to start with some small issue and just gradually make your way. The great thing about GitLab is that, and I say to everyone that if you look for something you will find it in the way, in the place that you are expecting it to find it, which is very, very nice. And it's not the rule in every project. Another thing, the test coverage is really, really good. So I'm not afraid to comment my changes because I know that if someone, if my change may harm some other place, it will be probably caught by our great test coverage. So it's very reassuring for a developer or a community contributor to know that the test coverage is so good. Cool, thanks. And another question from Dennis. I mean, thanks for your questions. Would it be appropriate for takeover an inactive merge request from a hackathon? I mean, in general, I would say yes. I mean, one of the things, I don't know if this would be doable in the two-day period during the hackathon, but leading up to it, if there's an old MR that hasn't been actively worked on for the past several months, I think I'll be happy to do this on behalf of you, Dennis, or you can do this yourself. Just ping the contributor, the original contributor, and if that person's not responsive within a week or so, I think it's completely appropriate. I don't say any reason why you can't do it. So, I mean, you could, for example, do this like a week or two before the hackathon starts, and if that person's not responsive, just open a new MR that's completely appropriate. I mean, sometimes it does happen when two similar MRs come in addressing the same issue, and then we'll figure out how to deal with that. I mean, usually, if they're almost identical, it would be sort of first come, first serve, but Dennis, if you find something that hasn't been worked on, feel free to point them out to me and then happy to have it continue or complete the work. Thanks. I agree. And one thing I'll add into Ghosh's comment was that GitLab is super iterative, and if you decide that a problem is interesting to you, but maybe the way that proposal is too large or too challenging, and if there's a thing that you can shift that's smaller or that just moves us in the right direction, even if it's just like a copy change, like we would definitely welcome that contribution. Like if you see an issue and you feel like it's too large or it's gonna take too long, but there's something else that we can do that solves a part of the problem, like GitLab is great about getting smaller changes merged in. Like no one is going to reject the change because it isn't large enough. On the contrary, like we welcome really small changes. So please keep that in mind and don't just take the issue as like the only way of solving a problem. Like I would read the problem statement, think about like, oh, how can we solve this in like the smallest way possible? And then if you can break it down even further, like please do. All right. Any other questions or parting thoughts? Ghosh, Jeremy, thanks for joining. I mean, Jeremy, it was great to get it. I think you gave us an overview of managed stage about a year ago, but we've gone through so many changes over the past four quarters. So the refresher was definitely great. And Ghosh, get an engineering perspective and your participation was much appreciated. And thanks for others who joined in and I'll get this posted shortly on the Hackathon page. And yeah, Jeremy, if it can get me a link to your slides as well, they'll be awesome. So people can view it for those who weren't able to join. Sounds good. Thanks, everybody. Have a good day. Thanks a lot. See ya.