Awesome! You're about to become a GitLab UX Designer! Below you'll find everything you need to start designing. If something is missing, add it (as goes with everything at GitLab)!
You will feel very slow in the beginning, that is perfectly normal. There is a lot of information being thrown at you all at once. Your goal for the first few weeks here at GitLab is simply to listen, absorb, and ask as many questions as possible.
If you haven't already, please read the main section of the UX Handbook and the UX Designer section. Reading the Design project README and its contribution guide will also help fill in all the details of how we work.
You will be assigned a UX Buddy to help you find your way around. Your buddy will schedule a coffee chat with you during your second week. They will also be assigned to your first few issues alongside you. While you should feel free to ask anyone for help at anytime, your buddy is a dedicated person you can rely on for help and guidance.
When in need of different tools, request those by filing an issue on our organization issue tracker.
As part of your day-to-day, you will be working in the GitLab Design Repository. This is where we host design files and share them with developers for implementation. For details on how to work and contribute to this repo, read the contribution guidelines.
GitLab is built on an open core model. That means there are two versions of GitLab: Community Edition (CE) and Enterprise Edition (EE).
GitLab Community Edition is open source, with an MIT Expat license. GitLab Enterprise Edition is built on top of Community Edition: it uses the same core, but adds additional features and functionality on top of that. This is under a proprietary license.
It is a good idea to familiarize yourself with the differences between CE and EE. As a UX Designer here at GitLab, you will have access to all the features within EE. The tiers within CE and EE are listed here. Review the feature comparison to understand the features available within each tier.
As you begin to get settled in, you will most likely need to create or update an issue.
Workflow for creating an issue:
Visit the issues list from the GitLab.org group.
Search to make sure the issue doesn't already exist.
Navigate to the project you want to add the issue to, click New Issue.
In general, most issues start in the CE project. If it involves an EE only feature, it should go in the EE project. If in doubt, go ahead and place it in CE to start, it can always be moved at a later time.
Choose a template from the Choose a template dropdown and take a look at the typical kinds of issues created below.
Fill in all the relevant sections.
@mention someone in the issue to attract attention to it. Choose an expert here or feel free to ask in the #ux channel on Slack who it should be reviewed by. Do not worry that you are poking someone to review a job when you don't even know them and they might be much more senior than you, if it's not appropriate for them, they will know the right person to pass it along to and do that.
Typical kinds of issues created:
Use the bug template.
Make sure it looks like a bug - otherwise ping one of the developers to confirm.
Reproduce the bug.
@mention the Product Manager (PM) responsible for that area of the product.
Proposed feature request
Use the feature request template.
Focus on describing the problem as well as a solution.
Ask a PM for an opinion, involve frontend and backend engineers as well.