add specific details related to how the UX team uses labels to tackle issues
This commit is contained in:
parent
40683268b2
commit
544117a55b
1 changed files with 18 additions and 1 deletions
|
@ -304,7 +304,24 @@ any potential community contributor to @-mention per above.
|
|||
|
||||
## Implement design & UI elements
|
||||
|
||||
Please see the [UX Guide for GitLab].
|
||||
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/ux/) of the handbook.
|
||||
|
||||
Once an issue has been worked on and is ready for development, a UXer applies the ~"UX ready" label to that issue.
|
||||
|
||||
The UX team has a special type label called ~"design artifact". This label indicates that the final output
|
||||
for an issue is a UX solution/design. The solution will be developed by frontend and/or backend in a subsequent milestone.
|
||||
Any issue labelled ~"design artifact" should not also be labeled ~"frontend" or ~"backend" since no development is
|
||||
needed until the solution has been decided.
|
||||
|
||||
~"design artifact" issues are like any other issue and should contain a milestone label when scheduled in the current milestone.
|
||||
|
||||
Once the ~"design artifact" issue has been completed, the UXer removes the ~"design artifact" label and applies the ~"UX ready" label. The Product Manager can use the
|
||||
existing issue or decide to create a whole new issue for the purpose of development.
|
||||
|
||||
## Issue tracker
|
||||
|
||||
|
|
Loading…
Reference in a new issue