 Okay. Next up, I'm happy to have James Ramsey on our next tutorial for GitLab Create. So James, I'll turn things over to you. Just quick introduction and tell us everything about DevOps Create. Sure. Thanks, Ray. Nice to meet everyone. I'm the product manager for the Create stage of the DevOps Lifecycle. So I think the first thing to explain is how we break things up at GitLab. GitLab structured around the DevOps Lifecycle. And so we have different teams for each stage. And I'm particularly focused on the Create stage, which is how you create and review your code. So practically, breaking that down into a bit more detail, that includes source code management. So the Git bits, which includes LFS, protected branches, and forking workflows. Create also includes code reviews, which merge requests, the diffs, highlighting approvals. So yeah, those are probably the most obvious areas of the Create stage in the DevOps Lifecycle. But also part of it is the Web IDE, which is a really great way to write code in the GitLab interface, particularly if you spot a small change or want to work on a project that you don't have on your local computer or you're on a tablet, you can use the Web IDE to make changes and commit them. We've also got snippets, wikis, search, so code search. And coming later in the year, we're also looking to include design management processes, because the UX design process is a really important part of creating new applications and creating new features, and also live coding. So making it easy to collaboratively code in real time with your peers and colleagues, and also work on wikis in real time. So that's a really exciting thing that we're looking forward to later in the year. So that's Create in a nutshell. So I guess to help you think about ways that you might want to get started and contributing to create aspects of GitLab, there's really a lot of places you could start. And so I thought the best way to share that would be to show you some recent contributions by people who added things to GitLab. And so the first one is around displaying empty dips. And this is an example of a pretty small front-end change. There's lots of issues where you can search for create issues in the issue board. You can find UI polish issues like this. And so this one, they noticed that empty files in the diff view didn't really look right. And so what they did is they improved the way empty files look. A similar sort of change maybe for people more back-end inclined with more rails experience. Someone recently updated the way the target and source branch selectors worked for branch filtering. And so that makes when you're doing comparisons much easier. It allows you to filter with regexes and stars and globs and things like that. So really nice improvement for someone who is more familiar with Rails code. But then anyone can contribute to GitLab. It's not just people who know Bue.js or are familiar with Ruby. Documentation is a really important part of GitLab. And there's lots of improvements you can make to the documentation. So a recent improvement to the documentation I think in 11.8, so not even released yet. Someone wrote step-by-step instructions how to set up push mirroring with another GitLab instance. And here are some other examples of maybe a little bit more complicated improvements that you might be inspired by. In the web ID, someone added the keyboard shortcut to quickly commit whatever is in the editor. So you can now click command-enter or control-enter on a Windows computer and commit whatever you've got in front of you. And just live on GitLab.com is a few days ago is a new summary of how many approvals there are on a merge request. So this nicely brings together some front-end and back-end elements. I think, Brendan, if you watched this morning's Verify video, Brendan talked about the Git push option to skip a CI build. This one's really back-end for those who don't like to use the front-end that makes it really easy to skip a CI job. And there's all sorts of opportunities to find features like this in GitLab. If you don't want to touch the front-end, you can just build nice little back-end features like this. And then a more complex example of a feature that was built by a community member is instance-level license template. So file templates that can be specified for an entire instance and then they now appear in the file template dropdown. So for licenses, GitLab, CI, YAMLs, other kinds of file templates. So hopefully these give you a bit of an overview of some of the smaller, simpler little issues that you might want to think about working on to some of the more complicated issues. And all these improvements sit within the create area of GitLab. So where would you get started? If you're looking for a first-time contribution, documentation or small UI polish issues, a great way to get started. You might not need to change more than 10 lines to make a really useful change to GitLab. If you're looking for something more complicated and a little bit more exciting and you're an experienced programmer who's wanting to do something really interesting, these are two suggestions I wanted to put out there. We currently have file templates for GitLab, CI, licenses and things like that. But it would be really useful to have completely custom file templates. So that might be useful if you've got a blog and you wanted to have different blog file templates. So when you create a new blog post, you could just use full dropdown in GitLab to create a template. Another example of a feature that could be really interesting to implement is codoners. So we introduced GitLab codoners in Enterprise Edition. And it's very focused on integration with merge request approvals. But we have an open issue about bringing the non-approvals part of it down to GitLab Community Edition. So that would be interesting because it involves porting some EE code down to GitLab CE. And that would be a really exciting feature. Ray, do you have any questions or things that you'd like me to share, perhaps? Yeah, I just wanted to add on the custom file template, I think that's one of the issues that we highlighted for this hackathon. We're encouraging people to submit a merge request and there's an extra prize associated with that. It doesn't look like anyone sort of volunteered yet, so that one's still open. So if anyone wants to work on it, just add a comment there and mention either me or James, and then we can assign that issue to that individual. So that one's obviously open. And so I guess, I mean, this is a, I mean, similar question I asked other presenters like this morning. I mean, obviously it creates a big part of GitLab. But if people have questions about features or suggestions, I mean, what's the best way to do that? I guess the one place to start is look for issues and if there's like a similar already filed, but how is, what's the best way to sort of reach out to you or people on the create team to have a discussion on questions about features or requests they have? Yeah, if you've got an idea, check the issue board because there might be other people who have also had the same idea. So there can often be some notes and feedback already out there on the idea. But if not, just create an issue and ping someone. But I guess, so I'm probably the best person to mention. Also, there's a bunch of engineers on the create team. So if you go to the GitLab team page, you can search for different people in different teams. And so that way you could ping some engineers if you wanted to ask them some input on how to get started on something. But also we want everyone to be able to contribute. And so if you have an idea, you don't need permission to create a merge request, you can just get started on your idea and open a merge request. And if it makes GitLab better, that's what open source is all about. So you don't need approval from someone, you don't need to have a fancy proposal of what feature you're going to build. If you're building something that you think is useful, feel free to open an issue or feel free just to open a merge request and propose something. That's the brilliance of open source. Yeah, I think James, you showed several good examples of community contributions. And I mean, we see those coming in. I mean, I see at least several of them across different product areas. And what I typically do is I try to triage them and put it in front of different product managers and team managers. And I mean, across the board, I think at least within a couple of days, like someone will respond to it. So one of the things I'd like to let community members know is that it's a completely fair game to ping people within GitLab. I mean, we're all part of the community. So I mean, the reason why I'm doing that is so that community members know who to ping if they have questions about that specific MR or product features going forward. Yeah, and as someone who's wanting to contribute the first time, you shouldn't have to know who to ping to get an answer. So GitLab will sort that out, Ray or someone else will notice. Have a new merge request and then we'll rope in the people that need to get involved. Be that to give you a code review, answer questions you have on maybe handling some edge case or even just getting feedback on where to get started. It's totally okay to sort of grab an issue and be like, I want to work on this issue. But can you give me some tips on like, which files and which data models I need to look at to get started? All right. Cool. Okay, I think we have, I just typed a question on the chat if people have any questions they can type in. I think people are muted. I guess, I mean, one other thing I probably want to ask a few James is you probably have like a section on the vision page for 2019, right? Yeah. That's worth sharing. Did I link it? No, I must have deleted that slide. I can share my screen and pull up the vision page. Cool. Yeah. So as I mentioned, create the create categories pretty broad. So create stages of the DevOps life cycle as broad as lots of different categories from source code management, search code review, et cetera. But some of the things we're working on at the moment that might be interesting is we're making a start on group merge requests, trying to link merge requests to each other. So for applications that span multiple repositories, maybe have a service architecture, making that easier. We've been working on making code review more holistic. And that's, there's a whole range of improvements coming over the next year, trying to improve that. So we've made it possible to comment on unchanged lines in changed files. And we want to get to the point where you can comment on any line of any file in a merge request, because code reviews shouldn't just be around the code that has changed. The code that hasn't changed is also very important. We're just about to ship smarter squash and merge a range of improvements to the Web IDE. I mentioned design management is something we'll be making a start on. So expect to see the first iterations in the next few months. But yeah, improvements around forking and streamlining that is something that we really want to do, as well as making commit messages part of the code review. We think that commit messages are really important in making a repository and a software application that has a long lifespan. If you don't understand how the code came to be the way it is, it's very hard to improve it. And then one that's not actually on this list, I don't think that we're very excited about is we're about to start working on confidential merge requests in the next couple of releases as well. So that'll help open source projects that need to fix vulnerabilities that'll streamline that process. Because currently you'd have to have a completely private copy of the project to be able to do that confidentially. And that's something that we find frustrating at GitLab when we ship security updates. It's the same problem for many other open source projects and that's something we're working towards as well. Was there a question in the chat that I saw? Yeah, I think GoKent was saying it was okay. But I think Erin joined a bit late. But Erin, I'm not sure if you have any questions or comments. Okay, I guess no worries. Glad to have you with us. I think I guess just to wrap up the end of the year, live programming is a really sort of interesting and challenging objective. So kind of like Google Docs slash Adam Telly type in the Web ID and Wikis and trying to make real-time collaboration possible. And then the other one, which is really interesting for on-premises installations or self-hosted installations of GitLab is distributed merge requests. We want to make it possible to send merge requests from one GitLab instance to another. So if you have a private GitLab server, your organization, company or university say, and you've got a fork of a popular open source project and you find a bug in it, you may not want to fix it publicly upstream immediately. You may want to make a patch for that bug or issue and continue shipping your application. But eventually you want to upstream that bug fix and it's kind of difficult to do that. You need to take your change and move it from one place to another and we want to have a streamlined process so that you can do your code review process locally with your team. Make sure that you haven't leaked anything confidential maybe that was in your test suite or commit message, for example, and then publish that merge request onto the upstream instance. So I think that'll be a really amazing feature and start breaking down some of the walls between self-hosted Git servers that have maybe built up over the years. People have become more enthusiastic about merge request workflows, which are inherently currently stuck on a single server. So yeah, this is where we're heading in 2019 and this page gets kept up to date through the year and there's a lot more detail. For each one of these categories inside of the create DevOps stage you can go and find a more detailed vision and see what we'll specifically be working on, drill down and maybe even find an issue that you want to work on if we're not going to work on it soon enough. And you can always propose taking things in a completely different direction and that's the brilliance of the open source. Cool. Awesome. Thanks for the details. I like having these vision pages for each product groups. It makes it transparent to community members that what GitLab product teams are working on. No worries. Thanks, Ray. Yeah. So if there are no questions online, I think we can wrap this up but also put this on YouTube hopefully in the next couple of hours and so people can catch a recording if they weren't able to join us. Thanks, James, not only for leading the presentation but also preparing the materials ahead of time. So definitely I'm sure community members will appreciate it. No worries. All right. Well, thanks very much. Have a good day. Have a good time. Bye. Thanks.