 All right, so welcome to our second tutorial session. We have a couple of great speakers today, Tori and George, who's got a lot of experience working on UX and design system at GitLab. I think we had a UX overview about a year ago before, like during the first hackathon, but there's been a lot of updates since then. So I thought it'd be good to bring these two folks over to encourage people to contribute to UX and UI at GitLab. So Tori and George, I'll turn things over to you. Feel free to share your screen. I'll let you go from here. Cool, yeah. I will share my screen. Awesome. So yeah, thanks everyone for their participation in the hackathon. Maybe George and I can just introduce ourselves really quickly. I'm Tori. I'm one of the product designers here at GitLab. And I'm also a maintainer of the GitLab design system. George, you want to introduce yourself a bit? Yeah, sure. I'm George. I'm a UX engineer and a core team member at GitLab, part of the wider community at GitLab too. And excited to talk about you, about the design system. Yeah, and also George is one of our top, or is our top contributor to our design system. So a great resource if you have questions about contributing. So I'm going to run through a bit about what Pajamas is, how the repositories that make up Pajamas are structured, and a little bit about our current initiatives and priorities. And then also some documentation that will help get started. And then George will walk us through how he contributes to the projects, as well as some of his contribution tips. So the goal of our design system is to be a single source of truth for the robust components within our library. It includes usage and implementation guidelines, as well as the overall design philosophy with guiding principles and resources that help us make decisions when we're designing for our UI and the features of GitLab. And by the way, we opened a GitLab issue to name our design system almost a year ago now. And Pajamas was the clear winner, because it's kind of a nod to our remote culture and how we're working from home. Sometimes some of us work in our pajamas. So that's where the name came from. So let's take a look at what makes up our design system behind the scenes. We have four repositories or projects, and they all relate to the system. So I've listed them here. The first is the Pajamas design system, the GitLab design repository. We have GitLab SVGs and GitLab UI, and I'll walk through what each of these are and also how they relate to each other. So first is the pajama itself. It's the repository that includes our UX and design philosophy. We have foundational principles that help us tell a story of how we build our products. And it also includes documentation for a variety of areas across GitLab, including both brand and product. There's also, of course, the component documentation, which includes the usage and technical guidelines. And we also have accessibility resources, which includes things like our voluntary product accessibility template and a statement of compliance. And then lastly, there are slinks to resources that help get you started with contributing as well. So next is our GitLab design repository. This project includes all the sketch files that we use for creating different specs for building features. It includes our team library, which consists of two files, our pattern library and our instance sheet. The first one, the pattern library, includes individual symbols that make up all of our global components within sketch. And then the second one, the instance sheet, takes all of those symbols and builds larger page views that can be used to create different, or to work on different issues or create new features, things like that. So from our team library, we're able to export specs for specific features, and those are then shared for specific components, and those are then shared with our front-end team when building out the reusable components that are included in our design system. Next is our SVG repo. So about a year or so ago, we started replacing all of our font awesome icons with our own custom icon set. And we're also going through an overhaul right now of improving our icons as well. So this repo houses all of those icons, as well as our custom illustrations that are used in places like our error pages and empty states, for example. The SVGs are published through NPM and consumed by CE and EE repos, which are product repositories. And this project is not yet consumed by GitLab UI, which is where the components are held, but that's one of our top priorities so that we can remove font awesome from being used within our components. So that brings me to GitLab UI, which contains all of the components that are built using Vue.js. And there's Sandbox using Storybook so we can view them live and edit component properties. And the repository is also imported into Pyjamas, which allows us to embed those Vue components directly within our markdown documentation. So we have an issue board. I linked it here at the bottom of the slide that has some issues that we've prioritized that focus on infrastructure tasks that we need to work on. And those are open for anyone to pick up and contribute to. So just to give a little bit overview and visually explain how all of these repositories are connected, George put together this awesome diagram. So you can see on the left side the design repository that includes the pattern library and instant sheet and also the spec previews that we use to build out the components on the front end. We also have the GitLab SVG project that houses all of our icons and illustrations. Those are imported into our product code bases and soon will be imported into GitLab UI, which will make them available to our components. We have GitLab UI, which includes components that are sandboxed within Storybook and those are imported into the design system. And then we have the design system itself, Pyjamas or design.githelab.com and that includes usage and technical guidelines for components as well as our design philosophy resources. And if anyone has any questions, feel free to stop me at any time. I'd be happy to answer them. So in order to start building out the reusable components, we identified 36 foundational ones. So things like buttons or forms, all of those kind of foundational things that allow you to build up and create a UI. And we broke those down into four stages that you can see here, create, build, style and implement. Or the create stage includes documenting usage guidelines for the identified components and then adding it to our sketch team library and exporting the specs so that the front-end team can utilize those. The build stage includes creating the view.js component within our GitLab UI project and then style means making the component match the visual specs and the usage documentation. So from there, we can implement the component into the product and that's the last stage. In Q2 and Q3 of this year, we're focused on the first three stages, so creating, building and styling of the components and then afterwards, we'll focus on implementing the components into the actual product. We have two issue boards that I've linked here. One is for the component planning that we have over the next few milestones and the other one focuses on each of the individual stages and those issues that aren't already assigned are also open for community contributions as well. So in order to build and style the components, we needed to come up with a front-end framework and infrastructure that the team could follow in order to create code that was consistent. So we ended up with a utility first approach and in the slides we linked an article that helps outline this approach a little more so I would definitely recommend checking out that link if you're interested in learning more about kind of the approach we took and why we took it. We have a number of components that have been built and not styled so you may see within design.glab.com a component that is on there but there's a little banner that says it does not yet conform to the correct styling we've defined in our design system. So there's issues for that to kind of correct the styling and then there's also a variety of components that were styled in our product repository so CE, GLAB CE and those need to be migrated over to GLAB UI and there's a link in this slide that has an epic that contains all of those issues and those are open to community contributions as well. All right and if you're interested in working on a component then looking at Merge Merge Request is a great place to start to kind of see guidelines for how we've done it in the past. There's a couple examples linked here in the slide. We also have a working group which is a group of people who are dedicated towards the issues focused on implementing the infrastructure needed to build and style the components and this group has two issue boards. The first is the one that I mentioned a little earlier about different ongoing infrastructure tasks that need to be complete and the other one is some CSS cleanup issues that focus on fixing style and errors so those are great places to start as well. The infrastructure tasks are a little bit more intensive and the style and errors may be a little bit easier to pick up and also I linked the GLAB UI working group so you can click that link to find anyone who is part of that group and anyone can help if you have any questions about any of these issues. All right, now I'm gonna pass it over to George to talk a little bit about his experience. Thank you, Teri, for all the insights. So this may seem like quite a lot of information but you can take some time later to inspect the links. So I thought I could share a short story on how I started contributing to GLAB and more specifically to the design system. It was about a year and a half ago when I started contributing to the development part of the GLAB project and more specifically picking up front-end engineering issues related mostly to styling and deblating. When Vue.js started shaping reusable components I shifted my focus to Vue related issues and some front-end performance issues. And for the past six months or so I have switched mostly focused to the design system where the component design implementation takes place. I usually jump into, as Teri said, we split the component development into four distinct stages. I usually jump into component stage where I see potentially a big impact across the development of the product, keeping an eye on the development across most stages in GLAB. A stage in GLAB is like a team where development team focuses on a specific area across the product. So trying to propose new component variants that are non-existent in design or implementation according to implementation needs and bringing back to the design system the implemented components that were initially added from the front-end engineering team back to the design system. And thinking product designers when needed for validating designs and front-end engineers to review contributions and more. So in the next slide I'm going to, here's a list of contributing tips I can give you right away. The first one is quite obvious is just take a look at the issues within these three repositories. They contain a lot of useful information. You can participate in discussions or jump into a magic quest and submit your own changes. Documentation improvements are always welcome. Every time I run back to the design docs I always spot some inconsistency or documentation improvements that can be, can help. The third one is also quite obvious. Reading other people's code is very much insightful. You can learn so much in design thinking and how the UX team thinks and approaches the problem about component implementation and learn more about the front-end team and how they approach implementing front-end architectures and components specifically. Tooling decisions of course how we actually leverage a GitLab CI to automate releases, snapshots testing, visual bits and more, many more. Of course, pinging the right people can always help. This may not seem obvious at first but this can help both sides. It can help the team actually balance the effort between the team members and actually can help you a lot as you have the opportunities you collaborate online with a lot of people. Everyone is different. All of them are brilliant. Pink the team. You can see the GitLab UI group where Tauri mentioned earlier. People are actually more focused on the design system and work on components. And the last slide is about what to get start. What to start? I link to the get started section in the design docs. You can take a look and see how you can submit an issue or a merge request in frontend and UX too. And as we mentioned earlier, we use labels to track the four distinct stages of the component stages. So you can actually filter per label. You can actually use the Pajamas create scope label to filter issues related to design specifications of a component, the Pajamas build label to pick up an issue related to component implementation. Pajamas style label is also for styling and functionality that is missing from the component. And the last but not least is the Pajamas implement label which actually tracks issues related to implementing the component in the product itself which requires design, the co-implementation and publishing the component and consuming this through NPM to the product. So thanks for listening. Hope you like that. And think us directly in an issue or a merge request and we'll give you a touch. Ray? Oh, cool. Thanks, sorry. And George, not only for an overview of the GitLab design system but how people can start contributing. And I mean, the other thing I wanted to add, I mean, people are probably tired of me saying this but I've seen you do this, George, number of times if anybody sees a bug or even a question, I think people are just welcome to open issues like yourselves. If you can't find an issue that's already open, I mean, feel free to open something and that's usually a good way to start a discussion. And I mean, thank you, Tori and George for listening your contact information there. I'm sure they don't know where to go. They can start with the two of you and go from there. Yeah, absolutely. And also there's opportunities for contributions from designers and front-end engineers. So if you're interested in contributing design or code or both, that's all great. So, and if you have questions about where to start, feel free to reach out to either of us and we can help point you in the right direction. Yeah, I mean, I thought the refresher was definitely needed because I mean, not everybody's necessarily interested in contributing Ruby code or comfortable doing that. And this and other areas like testing are good areas where people can make other types of contributions. Yeah, absolutely. Cool. Give it a few more seconds to see if you have any questions but obviously once this session is done, the recording will be posted on the main hackathon page and it'll also be on the playlist that we have for hackathon sessions. So if you're watching the recording and if you have questions, I mean, feel free to ping me or Tori or George and we'll be happy to, we'll try to get back to you as soon as we can. All right, well, thanks everybody and hope you have the rest of the rest of your day. All right, cheers. Bye bye.