kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity
gitlab-org--gitlab-foss/doc/development/contributing/design.md

3.6 KiB
Raw Blame History

Table of Contents generated with DocToc

Implement design & UI elements

For guidance on UX implementation at GitLab, please refer to our Design System.

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 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.

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.

~"product discovery" issues are like any other issue and should contain a milestone label, ~"Deliverable" or ~"Stretch", when scheduled in the current milestone.

The initial issue should be about the problem we are solving. If a separate product discovery issue 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).

When the ~"product discovery" issue has been completed, the UXer removes the ~UX label, adds the ~"UX ready" label and closes the issue. This indicates the UX work for the issue is complete. The UXer will also copy any designs to related issues for implementation in an upcoming milestone.

Style guides

  1. Ruby. 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
  2. Rails
  3. [Newlines styleguide][newlines-styleguide]
  4. [Testing][testing]
  5. [JavaScript styleguide][js-styleguide]
  6. [SCSS styleguide][scss-styleguide]
  7. Shell commands created by GitLab contributors to enhance security
  8. Database Migrations
  9. Markdown
  10. Documentation styleguide
  11. 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:
  12. Code should be written in [US English][us-english]

This is also the style used by linting tools such as RuboCop, PullReview and Hound CI.

Return to Contributing documentation