2018-08-09 10:09:07 +00:00
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE - RUN doctoc TO UPDATE -->
**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*
- [Implement design & UI elements ](#implement-design--ui-elements )
- [Style guides ](#style-guides )
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
## Implement design & UI elements
For guidance on UX implementation at GitLab, please refer to our [Design System ](https://design.gitlab.com/ ).
The UX team uses labels to manage their workflow.
The ~"UX" label on an issue is a signal to the UX team that it will need UX attention.
To better understand the priority by which UX tackles issues, see the [UX section ](https://about.gitlab.com/handbook/engineering/ux ) of the handbook.
Once an issue has been worked on and is ready for development, a UXer removes the ~"UX" label and applies the ~"UX ready" label to that issue.
2018-08-10 12:49:42 +00:00
There is a special type label called ~"product discovery". It represents a discovery issue intended for UX, PM, FE, and BE to discuss the problem and potential solutions. The final output for this issue could be a doc of requirements, a design artifact, or even a prototype. The solution will be developed in a subsequent milestone.
2018-08-09 10:09:07 +00:00
2018-08-10 12:49:42 +00:00
~"product discovery" issues are like any other issue and should contain a milestone label, ~"Deliverable" or ~"Stretch", when scheduled in the current milestone.
2018-08-09 10:09:07 +00:00
2018-08-10 12:49:42 +00:00
The initial issue should be about the problem we are solving. If a separate [product discovery issue ](#product-discovery-issues ) is needed for additional research and design work, it will be created by a PM or UX person. Assign the ~UX, ~"product discovery" and ~"Deliverable" labels, add a milestone and use a title that makes it clear that the scheduled issue is product discovery
(e.g. `Product discovery for XYZ` ).
2018-08-09 10:09:07 +00:00
2018-08-10 12:49:42 +00:00
When the ~"product discovery" issue has been completed, the UXer removes the ~UX
2018-08-09 10:09:07 +00:00
label, adds the ~"UX ready" label and closes the issue. This indicates the
2018-08-10 12:49:42 +00:00
UX work for the issue is complete. The UXer will also copy any designs to related
2018-08-09 10:09:07 +00:00
issues for implementation in an upcoming milestone.
## Style guides
1. [Ruby ](https://github.com/bbatsov/ruby-style-guide ).
Important sections include [Source Code Layout][rss-source] and
[Naming][rss-naming]. Use:
- multi-line method chaining style **Option A** : dot `.` on the second line
- string literal quoting style **Option A** : single quoted by default
1. [Rails ](https://github.com/bbatsov/rails-style-guide )
1. [Newlines styleguide][newlines-styleguide]
1. [Testing][testing]
1. [JavaScript styleguide][js-styleguide]
1. [SCSS styleguide][scss-styleguide]
1. [Shell commands ](../shell_commands.md ) created by GitLab
contributors to enhance security
1. [Database Migrations ](../migration_style_guide.md )
1. [Markdown ](http://www.cirosantilli.com/markdown-styleguide )
1. [Documentation styleguide ](https://docs.gitlab.com/ee/development/documentation/styleguide.html )
1. Interface text should be written subjectively instead of objectively. It
should be the GitLab core team addressing a person. It should be written in
present time and never use past tense (has been/was). For example instead
of _prohibited this user from being saved due to the following errors:_ the
text should be _sorry, we could not create your account because:_
1. Code should be written in [US English][us-english]
This is also the style used by linting tools such as
[RuboCop ](https://github.com/bbatsov/rubocop ),
[PullReview ](https://www.pullreview.com/ ) and [Hound CI ](https://houndci.com ).
---
[Return to Contributing documentation ](index.md )