Optimize UX workflow on how labels are used for planning, discovery, delivery within the design system
Problem
Currently, the UX workflow is missing a concrete description of how we use labels as far as the design system is concerned. The only reference to labels, when is comes to Pajamas, is during component implementation which only implies adding stage group labels.
Background
After the creation of gitlab-org&973, we've added labels for the component lifecycle stages like ~"pajamas::create", pajamasbuild, ~"pajamas::style", and pajamasintegrate as well as labels for each individual component like component:alert, component:avatar, and more.
In addition, we've extended labels beyond components to include other sections of the design system like foundationanimation. See proposal in https://gitlab.com/gitlab-org/design.gitlab.com/issues/314#note_178154470.
Proposal
-
1. Add component::*
,foundation::*
, etc. labels to issues and merge request across other repositories likegitlab-ce
orgitlab-ee
. -
1. Remove the ~design.gitlab.com label from all issues in the gitlab-org
group. 99% of these issues are directly within thedesign.gitlab.com
repository which should suffice. -
1. Replace the ~"Design documentation" with a new ~"pajamas::documentation" label. Alternatively, use ~"pajamas::create". -
1. Add information related to the Pajamas labels to the UX Handbook labels section. This could mimic the Scoped Workflow Labels
section, with a link out to our component lifecycle documentation.
Background
Repeating here some questions from the relevant slack discussion (internal):- Do you think
component::xyz
scoped labels could or should span across other repositories likegitlab-ce
orgitlab-ee
. For example, see https://gitlab.com/gitlab-org/gitlab-ee/issues/11307, https://gitlab.com/gitlab-org/gitlab-ee/issues/11306, https://gitlab.com/gitlab-org/gitlab-ee/issues/9231, and https://gitlab.com/gitlab-org/gitlab-ce/issues/54605. - Does it make sense to have the
design.gitlab.com
label attached to all these issues? Looks redundant, right? See https://gitlab.com/gitlab-org/design.gitlab.com/issues?label_name%5B%5D=design.gitlab.com. - Pajamas label in most of these issues also looks redundant now that
component::xyz
andpajamas::xyz
labels are in place, right? See https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Pajamas. - Some of the issues in [3] could be have a new
pajamas::documentation
label instead.
Limitations
The Pajamas label is needed in order to scope the relevant issue board, see Pajamas board, which is already missing 10 issues because of the missing Pajamas label. This board can be easily recreated using the pajamas::*
label for each of the four distinct stages of a component lifecycle including all related issues, see for example the Pajamas Test Board.