►
From YouTube: GitLab Dogfooding - Scoped Labels Use Cases
Description
Melissa Ushakov talks through some examples of how GitLab uses scoped labels.
Documentation: https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels
Product Development Flow: https://about.gitlab.com/handbook/product-development-flow/
Severity: https://about.gitlab.com/handbook/engineering/quality/issue-triage/#severity
A
From
the
plant
stage,
and
today,
I
wanted
to
share
a
little
bit
about
how
we
use
scope
labels
at
gitlab
to
help
us
manage
our
backlog,
and
let
me
share
my
screen
so
scope.
Labels
are
a
fairly
unique
concept
to
gitlab
in
that
they
are
mutually
exclusive
labels.
So
it's
a
set
where
one
can't
be
more
than
one
can't
be
applied
at
the
same
time
to
an
issue:
epic
or
Mr,
you
can
think
of
them
almost
like
a
single
sub
drop
down,
but
for
labels.
A
So
here
you
see
an
example
and
I'll
walk
you
through
a
couple
of
use
cases
of
where
we
use
them.
If
you've
interacted
with
the
Republic
issue,
tracker
you've
seen
that
we
use
one
project
for
the
most
part
where
we
have
all
our
issues
and
all
of
our
teams
work
out
of
that
single
project,
as
you
can
imagine,
that
can
get
a
little
bit
complicated
to
understand
whose
issues
is
whose
and
that's
where
scope
labels
come
in
and
help
us.
A
So
what
we've
done
is
that
we've
set
up
one
scope
label
and
you
can
see
they
look
like
a
little
pill
per
team
and
since
only
one
of
them,
one
of
the
items
that
belongs
to
group
can
be
applied
at
once
to
an
issue.
It
makes
it
really
clear
who
an
issue
belongs
to.
If
an
issue
has
group
code
review,
that's
their
team
if
it
has
good
compliance,
that
that
seems
issue,
and
it
also
gives
us
the
ability
to
do
interesting.
Things
like
here,
I've
segmented.
A
This
list
out
to
only
include
the
issues
that
are
have
the
label
group
product
planning.
So
the
PM
for
this
group
can
very
easily
find
the
issues
that
pertain
them
and,
of
course,
add
more
filtering
as
needed
to
find
and
narrow
down
that
list.
You
can
also
use
labels
throughout
the
experience
so,
for
example,
to
narrow
down
a
roadmap,
create
a
board.
It
just
gives
you
a
really
easy
way
to
filter
down
in
the
scenario
like
hours
where
all
our
issues
live
in
the
same
project,
but
this
can
be
also
helpful
in
a
couple.
A
Other
scenarios
that
I'll
show
you
the
next
one
being
the
workflow.
So
a
lot
of
times
open
and
closed
are
not
really
enough
to
describe
where
in
in
the
workflow.
A
specific
item
is,
and
that's
where
scope
labels,
the
note
workflows
come
in
so
here
you
can
see:
we've
defined
a
set
of
different
states
and
created
labels
that
go
along
with
it.
I'll
include
a
link
to
this
in
the
description,
but
in
case
you
need
inspiration,
but
here
you
see
in
our
handbook
our
product
development
flow.
A
So
it's
a
set
of
steps
that
work
must
go
through
in
order
to
be
complete
and
each
of
the
steps
has
a
label
that
goes
along
with
it,
and
we've
set
up
these
labels
at
the
group
level,
both
for
groups
and
workflows,
so
that
all
projects
underneath
inherit
them
and
it
makes
it
really
easy
to
manage
so
by
having
workflow
scope
labels.
You
can
do
a
couple
of
interesting
things.
A
So,
just
like
I
showed
you,
you
could
filter
throughout
the
experience
for
things
that
are
in
specific
States,
but
you
can
also
do
something
like
this,
where
you
can
create
columns
on
a
board
to
signify
the
different
states.
This
specific
board
is
a
board
for
delivery.
So
it's
an
abbreviated
version
where
we're
only
looking
at
things
that
are
in
planning
breakdown,
close
to
being
ready
for
the
team,
and
you
can
see
them
going
through
the
life
cycle
as
if
you're
working
collaboratively.
A
A
A
So
severity
is
another
scope
label
that
we
use
throughout
the
experience
of
our
issue,
Tracker
Where
for
security
and
bugs
you
can
apply
a
severity
label,
so
you
can
Define
your
own
policy
about
what's
step,
one,
two,
three:
four,
that's
what
we've
done.
Each
of
them
has
a
different
SLA
in
a
different
way
that
it
should
be
managed.