 Okay, welcome to the first tutorial session for this Q2 hackathon. My name is Ray, I'm the Community Manager at GitLab. And just going to cover a topic titled Contributing to GitLab and to be honest, this is probably something that I probably should have done at previous hackathons. We have a lot of new contributors that's joining the ranks for each release and at each hackathon. So I just wanted to have a quick overview of where and how you can contribute, where you can find resources to get you started, and also how you can get help as you started your journey in contributing to GitLab. Let me mute that other line there. So yeah, definitely want to make this casual. And my manager, Dave Plinella, is also on the line. He'll chime in as well. And I want to make this interactive. We have several people online, so feel free to interrupt us with questions either verbally or feel free to type them into Zoom, Wendell. So as for agenda, I think I mentioned a couple of areas already on where you can contribute and how to get started. Also want to share some community metrics, the common questions that I get frequently is how many people and how much contribution that we get at GitLab from the wider community. But as I mentioned, I mean, don't wait until the Q&A section at the end. If you have any questions, I mean, feel free to interrupt us. Ray, just quick note, you might want to share the slides to presentation mode. Yeah, let me start off that way. I'll be jumping back and forth on different panels. So I might have to go back to the regular mode, but yeah, let's get started with the full screen. So in terms of metrics, so what David and I have been doing is looking at the community metrics, particularly over the past three years. The reason why we focus on data from 2016 is I believe we introduced or added a label called Community Contribution sometime back in 2015. So we've been focusing a lot on issues and MRs that have that Community Contribution label. So we've been focusing on data from 2016 onwards. We obviously had contributions from the wider community from before 2016, but since the label wasn't created until shortly before 2016, we'll mostly talk about metrics over the last three years. But if you look at the chart on the upper right, in terms of number of people that have had their MRs merge over the three-year period, it's been pretty impressive growth over, I mean, 200% growth between 2016 to 2018. We had almost like 500 people or contributors that have had their MRs merge across pretty much all of our projects. It's not just CE and EE at GitLab. It's things like Gitter, Shell, charts, GitLab development kit. So pretty much all projects that we have, we've had wider community members contributing. And the growth is even more impressive if you look at just the number of MRs that have been merged between 2016 and 2018. We basically more than over 500% growth in terms of MRs that have been merged. So this is what makes GitLab as a product and community great. It's not just people at like a GitLab team members that are contributing, but we definitely appreciate not only the quantity of work that's coming in from the wider community, but different perspective, especially as user that all of you provide. And the other number that we have there, I mean, in 2018, the average contributions per month in terms of MR for each release is about like 150, which is a pretty phenomenal number. So I mean, I think we mean what we say when we say everyone can contribute. So everyone has been contributing from the wider community and we definitely want to see this going. David, did you have anything you want to add here or? No, I think that's just sort of just fantastic. I mean, I think quite a lot of the contributions that we've had have helped us as well improve how we handle those MRs requests and how we are most effective in terms of being more responsive and also reducing our cycle time in making sure that we get those contributions merged. And I think one of the things that we looked at a few months ago was improving the GitLab bot so that there's more automation that helped us humans reply to those MRs. And one thing that I would like to highlight, and you might have this later in this and like this, the work of the MR coaches. It is a team at GitLab that essentially is the front line, is the first set of people that the committee, whether committee members see and they try to help them getting their merge request in, be it with the first review, with assigning reviewers or answering questions. I think this is an important part of what we do as well, having this human interaction as well with first hand contributors and contributors in general. Cool. Okay. I'll just move right along. So where do people contribute? I mean, open source projects, people typically think of our focus mostly on code, but we have several different areas where people have been contributing and where people can contribute. So let me go back to the regular view and get out of the presentation mode. So, I mean, to get started, the first place you can visit is this contribute page that we have. So, I mean, this is in the process of being redesigned. We realize that this is a page that's gotten a little long. So we have an issue to help improve this page, to make it more digestible and make it more graphic. But I mean, after introduction, we elevated the getting help section, which I'll cover in a minute, but we want to make it easy for people to get help. And we have four different areas where people have been contributing, like traditional code development, documentation, translation, and UX design, and which I'll go over in a minute. But if you're just getting started, this might be a page that you want to come and visit. And like I noted, you'll probably see some improvements that we're going to make in the next few weeks. So going back to the slides, so I'll cover these four areas in an opposite order, since like the UX design, it's sort of at the bottom of the page, because we listed these areas alphabetically, but we'll go from the bottom of the page up to the top. So the first area is, I mean, UX design. So this is an area we've seen contributions from community. I mean, basically, I mean, people are suggesting like a different color palette as an example, so that obviously doesn't necessarily require you to have like in-depth knowledge of Ruby or Golang or other languages that we use for development. And so you find a list of issues that UX team had like a maintains. The craze taken a little long, I apologize. But we have over like thousand issues where people have open issues where we're accepting like merger requests from the community. So if you're interested in UX, and if you want to look at issues that you can start contributing to, I mean, here are a list of over a thousand issues that you can look at. But you can obviously narrow this down further. I'm going to add a way to one to find the easier one of the easier issues that that people can work on. So that narrows the issue down to like three from over a thousand. So if you're interested in contributing to the UX, and if you're looking for a level of difficulty that is the lowest way to one, I mean, here's one way to look at the look at the query and look for issues that you can contribute to. And the other area that I wanted to other page that I wanted to show was design system page. I mean, this is where you find all the resources and like a design guides and philosophy behind GitLab. So if you would go there, I'm just going to give you a quick overview. So even things like our logo, like our colors and topography, like how our philosophy behind it, you can look through these pages to get more background and same thing on our products, like color palette. I mean, like I mentioned, somebody, one of the community members suggested tweaking the color palette and one of the pages, and this is where you get the background information for our product and our brand on the website, for example. And I might be going a little quick, but wanted to highlight another page down here. So if you scroll down to like get started under contribute. So this has like a detail steps on how community members can contribute to UX design and proposals. I mean, by obviously filing an issue to an issue tracker and how to find like a UX review or a maintainer if you need to ping somebody. So if you click on a review or maintainer page here, it lists all the maintainers and reviewers that you might want to ping if you have any questions or on or or help getting started. And the other thing I wanted to highlight for the UX. Yeah, so at the bottom of the page, it's basically detail steps on how to contribute to a merger class. If you find an issue that you want to work on. I mean, basically details out what you need to do step by step, like forking the project, making changes, and, you know, again, pinging the right review or maintainer. So, I mean, if you want to get started on if your passion is user interface and UX design, I encourage you to get, you know, spend some time on this page. I think it's got the name pajamas because basically says we want to make it comfortable for everyone to contribute. So it's got a cute name. So do spend some time on this page. If you're interested in UX design, and I mean, this is like, again, this is an area where I mean, if this is your passion, and then you don't necessarily feel comfortable with Ruby and other programming languages we use, and this is a good area for people to get started. And we also have a tutorial video. I believe this was from the first hackathon that was done like a few quarters ago. I mean, feel free to spend some time like watching through video to get more background on the UX design. The next area is translation. So, I mean, this is a, so let me go to our crowd and platform where the translation is managed. But I mean, one of the things that a lot of people don't know is that, I mean, GitLab is translated in many languages, and this is done mostly by community members. There are some GitLab team members that have been helping here and there, but this is driven mostly by community members, which I've been very impressed with. So if you want to check out the crowd and platform, just go to translate.gitlab.com and shows you how the progress that's being made in various languages. If you look at languages like Simplify Chinese, it's like pretty much 100% translated, whereas some of the other languages like Albanian and Arabic are just getting started. But we're happy to see all the community members from different parts of the world contributing. You'll see a whole list of them. And when I count it last time, I mean, there are about like a 15 to 17 languages that were more than like 50% like a translated, which has been, which is pretty impressive. So just to give you a quick tour of the crowd and platform, I mean, if you, I mean, I've been contributing to like a Korean translation as an example. So I'll just go there. So if you want to look at what strings need to be translated, just go to click on this file dot POT file, you know, show you a list of strings that are sort of highlighted in red on the left that needs to be translated. So I'll just click on like one of their strings as an example. It also gives you like suggestions for translations based on like a Google translated and other translation tools. You can click on any of these if you're happy with them or just enter your translations directly here. So, I mean, if you speak a different language, and if you are looking for ways to contribute, I mean, I mean, translation is another good way of doing this. So I encourage you to check this out. And there are also a couple of other reference materials. Another tutorial video that was done by one of our core team members, Hannes, a couple of hackathons ago on translation. And I also posted a blog post, I believe it was back in January on, I mean, some of the things I already covered, how, you know, you can basically set different preferences on your profile page to see GitLab in another language, and, you know, how translation has been done on the crowd and platforms. So I encourage you to check that out. It should be a quick five minute read. So let me pause here before I go into the next slide to see if there are any questions or anything else I may have missed. If not, I can just move on. All right. And the next one is documentation. So, again, if you don't have a lot of a programming experience, but you still want to learn how the process works in terms of like submitting an MR and getting the MR merge, I mean, documentation would be one great way of doing this. And I mean, a lot of times if you find, I mean, not surprisingly, you'll typically find like a spelling and grammar mistakes that you want to fix. And this is usually a good way for a lot of new contributors to sort of get started to submit MR with the fix. And I'm going to show this page as an example. So whether it's docs or a web page, what you'll see at the bottom of the page is edit this page link when you can also open in a web IDE. If you happen to find a simple typo or a simple fix that you want to do, the easy thing to do is just click on like edit this page link. It'll basically show you, I mean, where the file is located, where the file in question is located. So obviously you probably want to create your own fork before you start working on this, but at least you'll know the path of the file that where the file is located. So you can start editing the file and submit a quick merge request. So we want to make this like a pretty simple to do, whether it's a website or even let me go to like a docs page to illustrate this. Yeah, so this is sort of a, I mean, I just picked the documentation page at random, but at the bottom of this, you'll also see like edit this page link. So documentation or website, if you want to do a quick MR and get familiar with the process, I mean, documentation is a great way of doing this. Cool. And last but not least on contributing code or development, if you're contributing or making code changes, we strongly encourage you to get started with the GitLab development kit. And this basically takes you to believe the readme file. If you don't have a GDK install on your laptop, this gives you a step-by-step instructions on how to prepare your computer, set up GDK. I mean, basically GDK, it gives you the whole development environment on your laptop or computer system that you use. So once you get this up and running, I mean, when we pulled a lot of the first-time contributors, I think more than half of them said that they were able to get this up and running in a couple of hours. So it's hopefully it's relatively pain-free. Once you get up and running, it should definitely ease your development effort that you need to do. And there's also an excellent tutorial video that featured tone from the GDK team. I believe it was on the first hackathon. It's probably one of the most watched like a tutorial videos. So I encourage you to take a look at that if you need more help on getting GDK set up and using GDK. Just a couple of points that I want to highlight that this often comes up. If you're making a feature change that impacts like users in particular, you'll probably get a request from the reviewer or merge request coach to also update the documentation. So there's something to keep in mind. If you want to learn more about luck and development guidelines, I have a link here that you can look at later on. So let me stop there as well. David, did I miss anything on those four areas where people can contribute? No, I think that was really good. One thing to mention on the GDK itself is that it is not a tool. It is a tool that is used by everyone who's developing at GitLab. There's no difference whether you're already developing GitLab on your spare time or as part of working for your company or working for the GitLab team. This is something that GDK is something that every developer uses. So expect it to be up to date. And if there are issues, then they're generally noticed quite quickly by the GitLab developers. Cool, thank you. All right, so moving on a couple more slides. So once you get started, whether it's like a UX design, documentation, or code, or anything else, I mean, first place that you can get help at probably the easiest place is the contributor's Gitter Room. So I'm opening it here. And yeah, over the next 20 or 30 minutes or so, it looks like there are a lot of questions and answers going back and forth. There are over like 230 people that are on the channel. So if you have any questions, this is probably a good place where not just GitLab team members, but other community members can help each other. So if you have any questions or if you get stuck on something, feel free to post questions here and ask for help or ask your questions. And the couple of other areas that I want to mention, and David's already mentioned this early on, I mean, first is a merger request coach. So these are GitLab team members. Basically, they volunteer to help out wider community members with any of the merger requests that are coming in. So if you have any questions or if you want to escalate something, I mean, you can mention the merger request coaches by typing in this string in a comment for your for your merger request or even an issue. So this will get their attention. And then if you want to see who the the core team members are, go to the company team page and under filter by department, you can just select the merger request coaches. And you'll see the list of eight of them here. And also list their areas of expertise and what they're reviewers for and what they work on. So if you want to specifically like call out somebody among the merger request coaches, this is a good page to go to to find out who could who can help you out. But like I said, I mean, it's it's completely appropriate to just ping everybody if you're not sure who you need to ping among some merge request coaches. So feel free to ping them on your MRs. And if you want to learn more about merger request coaches, we also have a tutorial that was done by Clement, who was a merger request coach at the time. So it's a quick like a 15 minute video that you can check out at your leisure. And the other thing that I went to point out, if you want to find out who the reviewers or maintainers for for different get that projects are, feel free to go to this link and you get a whole list of like reviewers and maintainers that you can ping. And I mean, this is something that, you know, both David and I are, I mean, try to stress to everybody new in the community, it's completely appropriate to ping anybody within GitLab if you have any questions about your contributions and merge request. So don't feel shy about like mentioning any of these people in your merge request. If you have any questions or if you don't feel like things are getting reviewed in a timely manner. And so just want to emphasize that. And then if you have any other questions or feedback that you don't think can be covered by merger request coaches or reviewers, feel free to send an email to this contributors alias. And both David and I are on this alias. So we'll get back to you as soon as we can when you send an email. Okay. And the last topic here. The other, the common question I get from community members is, you know, how do I find issues to to start working on. So I mean, one of the easiest way to find issues is to just do a query and look for a label accepting marriage request and has a backlog milestone. So here's an example that I'll quickly show. And this also has a we also added a way to one. So the level of difficulty is the lowest. So right now there are about there are 16 issues under under for like this is an example for CE that are accepting merge requests. And then the milestone of backlog. I mean, what this means is that various product team members and this, this is the way for them to mark these as something they want to see, but they just don't have like a specific milestone assigned to. So it's there's a higher likelihood that you'll, you'll get the attention of like a product manager, for example, if you want to start working on any of these issues. So look at these issues and and feel free to just mention me or David and say, and just let us know that you're you're interested in working on them. So we'll make sure that these issues get assigned to you. And so you can start working on your on your MR. And the other thing I want to quickly show, I mean, you can obviously further refine your query. Whoops. So for example, if you're just interested in like a documentation under CE, for example, I can further narrow down the query and see for some reason. Oh, there we go. I guess there's only one issue that meets the criteria. But this is way for you to further narrow down the query to see if there are issues that that you might be interested in working on. So but you know, as this last bullet item says, even if you don't have an issue, if even if you there, there isn't an issue that are that are created right now. But if you feel free to create any other issues and I mean, don't feel like you need to be encumbered by whether the issue is open or not. Even if there isn't an issue, we've had number contributors just start either creating a new issue or just creating an MR to get started. And that's completely appropriate. So I think I may have rushed through the last couple of slides, because I'm looking at the time in the three minutes left. There are any questions or David any comments that you want to add here, like I sort of rushed through the last couple of slides. Okay, just checking the chat here make sure there are no questions. Yeah, even after the call or for people that are on the, you know, watching the recording, if you have any questions, I mean, feel free to post them on the on the Gitter channel. And we'll try to get back to you as soon as soon as we can. And just, I mean, let us know if you have any, you know, questions about finding issues to work on or, you know, how to get in touch with, you know, various people that get lab if you have any questions about your your merger quest. Cool, I guess we'll just end the call here and we have another tutorial starting in about two minutes. So I'll see me some of you there.