►
From YouTube: Triaging at GitLab - Intro to triage operations, triage report, priority and severity labels
Description
This is a part of an on-going series aiming to train team members on the triage process and the automated tooling we have at GitLab.
A
Great
so
welcome
everyone.
This
is
the
unfiltered
session
on
the
introduction
to
charge
packages.
How
how's
our
trash
operation
being
done,
a
good
lab,
the
bugs
that
come
in
featured
proposals
and
how
we
cut
through
the
noise
and
the
volume
being
a
Enterprise
open
source
product,
I'm
mecha,
I'm
the
director
of
quality
and
on
the
call
and
house
we
have
craig
gomez
in
our
ng
measure
as
well.
So
yeah
with
that
I've
outlined
a
rough
core
curriculum
here
that
we
will
go
over
and
questions
quick
is
gonna.
Ask
you
gotta
fly
and
grill
me.
A
So,
hopefully,
I
do
a
good
job
asking
the
questions,
but
this
is
the
first
of
many
to
come
on
opening
up
the
doors
and
training
people
how
to
use,
try
and
more
efficiently
how
to
charge
more
efficiently.
So
with
that,
I
will
go
through
what
is
trash
operations
good
lad?
We
have
a
page
share
in
the
Quality
department
handbook,
defining
the
current
ROG,
automation
and
operation.
The
context
behind
this
is
that
we
receive
roughly
300
to
400
shoes
every
week
in
give
lab
C
and
E
repos
and
those
are
just
CEM
EE.
A
Accountability
is
at
the
top.
We,
as
a
quality
department,
do
not
do
all
the
tribes
for
everybody.
We
trust
every
teams
and
groups
to
do
this
with
the
p
r--
counterpart
engineering
managers
and
product
managers
and
to
use
their
priority
severity
definitions
and
slot
them
into
a
Mostow.
In
our
timeline.
A
There
are
two
tribes
packages:
I
want
to
go
over
always
a
day.
First
is
the
new
issues
and
a
newly
created
unlabeled
issues.
Currently
the
quality
engineering
team
is
doing
this
everyday.
Like
one
engineer,
I'll
click
on
example.
First
year,
one
engineer
is
in
charge
of
looking
at
this
every
day
and
we
fan
it
out
two
to
two
or
three
issues
per
engineers.
This
is
a
bad
example,
because
I
think
this
is
stale
already.
So
let
me
click
through
this
and
see
if
we
have
a
good
one
to
share
and.
A
A
Okay,
this
is
a
good
one.
It's
the
latest
one,
so
the
format
has
been
improved
quite
a
bit,
so
we
call
it
all
the
engineers
handles
and
then
just
divide
them
by
the
number
of
new
issues
coming
in.
It's
been
working
really
well
so
far.
The
the
initial
trial
is
just
pegging
it
to
develop
stage
group,
roughly
an
engineering
manager
or
imaginary
possible,
and
then
add
a
severity
label
and
the
rest
it's
enough
load
to
the
those
groups.
The
second
level
of
Atrato,
I
would
say,
is
a
complete
charge
at
the
state
level.
A
A
A
So
this
is
it
box
list
by
priority
and
severity,
and
you
can
see
how
many
of
them
fall
into
a
low
severity
and
low
priority
and
then,
at
the
top
left
hand,
corner
is
the
highest
priority
in
high
severity,
and
this
is
what
I
mean
my
collaboration
of
product
managers
and
engineering
managers,
the
first
section
of
future
proposals.
These
are
feature
proposals
that
are
on
schedule
or
sale.
We
request
the
product
manager
to
see
if
it's
applicable,
read
close
it
if
it's
duplicate
or
it's
not
no
longer
adding
value.
A
If
not,
then
please
schedule
it
to
them
to
a
best
estimate,
milestone
or
a
backlog.
Also,
if
you
scroll
down,
there
will
be
two
sections
I
think
this.
This
stage
group
plan
is
doing
very
well
because
there's
no
I
don't
see
any
bugs
for
front-end.
It
means
they're
done
with
the
front
end
box,
essentially,
which
is
great,
but
if
they
are
fun
in
box,
will
be
one
section
for
front-end
bugs
and
we
have
currently
three
back-end
bugs
for
Sean,
which
is
if
I
can
measure
with
that
I'll
take
a
pass
here
correct.
A
Currently
there's
a
ask
for
engineering
marriages
and
and
product
managers
to
add
severity
labels,
but
in
the
coming
iterations
we're
gonna,
let
everybody
at
them,
because
our
severity
definitions
is
clear.
Anybody
at
good
luck
and
roughly
assassin
at
a
severity
label.
However,
when
it
comes
to
priority
and
milestones,
which
is
it,
it
needs
to
be
reflected
in
team
planning
and
grooming.
Currently,
a
good
lab
product
managers
are
in
charge
of
scheduling
things
that
go
into
a
release
with
the
input
of
their
engineering
manager
counterparts.
A
A
Members
can
add
at
all.
No,
this
is
a
great
question
and
we
probably
would
like
another
unfiltered
session
on
community
contributions.
We
do
have
a
triage
package
just
for
community
contributions
and
especially
community
merge
requests,
and
these
are
I
think
we
have
an
example
here.
These
collects
the
most
requests
submitted
by
a
non
Gilliam
employee
or
an
encore
team
member,
and
then
we
found
this
out.
Good
luck,
coaches
and
we
have
a
slack
channel
for
that
for
em
our
coaches
and
we
just
help
help
the
community
push
through.
A
A
Okay,
we
do
another
pass
before
the
next
content
and
then
we
can
dive
in
more
okay.
So
we
went
through
that
already,
let's
go
back
to
the
Year,
Jim
and
I
think
we
talked
about
this
already.
We
talked
about
the
importance
of
charge
packages
and
we
took
a
look
at
the
complete
triage
done
by
the
p.m.
in
the
impair,
so
I
have
an
example
of
this
running
already
that's
generated
this
week,
and
so
right
now
the
heat
maps
there
I
think
it's
managed.
A
A
A
If
it
team
does
really
well,
we
would
see
less
of
the
check
boxes
and
then
it
would
just
be
a
really
thin
than
record
the
best
one
would
be
all
the
sections
are
empty
and
you
just
see
a
heat
map
of
like
okay.
This
is
like
what
I
have
in
a
backlog
roughly
and
has
a
charge
anything.
So
this
is
great
I
think
it
seemed
is
making
great
progress
here
very,
very
happy
about
it
and
then
my
last
one
is
to
revisit
the
priority
and
severe
definitions.
I'm
also
going
to
say,
look
at
page.
A
As
well,
okay,
so
we
went
through
the
current
iteration
that
has
a
heat
map.
We
have
a
v2
coming
out.
This
takes
it
a
step
further
by
capturing
with
the
high
emphasis
on
customer
effecting
issues.
So
the
format
is
here.
The
heat
map
will
still
be
there,
but
now
we
have
we
added
on
our
section
that
has
the
customer
label
so
like
bump
up
the
priority.
This
is
like
the
feature
of
ourselves,
but
we
are
slicing
it
by
the
customer
label
and
we're
doing
the
same
for
frontin
bucks
and
back
in
bucks
as
well.
A
We
also
want
to
improve
the
clarity.
The
instructions
are
now
right
up
top
and
it
it
shouldn't
be
like
you
do
this,
you
that
do
that.
Do
that
section
I
think
the
M&P
impairs.
We
need
to
collaborate
together
on
the
lists
and
then
on.
The
the
bottom
of
the
package
is
to
new
in
the
works.
We
you
start
to
tacked
bucks
that
have
missed
their
target
SLO.
So
p1
is
30
days,
P
to
60
p3
90
days.
We're
collecting
data
right
now,
there's
no
action
items,
but
we
will
list.
A
B
A
A
A
The
definitions
are
in
our
documentation
and
it's
under
issue
workflow
that
mock
down
so
again
for
priority
it's
a
target
as
a
low,
which
only
applies
to
feature
bugs
and
security
vulnerabilities.
This
has
been
signed
up
by
McAfee,
our
senior
director
of
security
as
well
as
ap1,
the
fastest
target
SLO
30
days,
P
to
60
P
390
days
and
P
4
is
the
the
rest
per
se.
This
is
anything
more
than
120
days.
So
probably
the
next
quarter,
that's
putting
on
calendar
terms
for
severity,
has
been
some
improvements
here
as
well.
A
This
used
to
be
two
tables
and
with
input
from
Christopher
and
also
Marin,
we
have
compacted
down
so
it's
easily
readable
and
in
furball
as
one
blocker.
This
is
an
example
of
customer
can
do
anything
like
an
features
block
broken,
there's
some
workaround
outages
and
impacts
50%
or
more
of
users
an
example.
A
22
to
half
of
our
users
and
large
portions
of
people
become
there's
a
slight
dimension
on
performance
degradation
as
well.
We
haven't
been
using
this
as
much.
This
has
been
carried
over
from
our
previous
ap
labels,
but
for
performance
on
galava,
calm,
I.
Think
the
infrastructure
team
is
using
this
to
to
label
their
other
issues.
As
three
I
would
say,
the
majority
are
bot
cbs3,
it's
essentially
it's
a
bug.
It's
not
blocking,
it
has
a
workaround
and
the
workaround
is
is
acceptable.
A
A
Impact
is
less
than
25%
and
limited
impact
on
significant
portions.
These
two
are
very
much
related.
We
recently
affected
users,
because
that
has
a
number
that
can
be
measured.
We
will
probably
revise
the
language
here
of
it.
So
it's
it's
it's
more
clear.
S4
is
the
rest
inconvenience
color
changes,
alignment
on
the
other
UI
and
such
any
questions
gripe
or
anything.
B
A
It's
OS
a
little
otaku
priorities,
so
if
it's
an
s-1
it
would
not
only
get
a
p1
and
the
reason
these
two
was
separated,
because
if
you
may
have
a
large
number
of
bugs
on
the
same
bucket
a
bucket
and
to
chip
away
at
that
black
blob,
you
need
another
dimension
to
schedule.
For
example,
if
you
have
say
a
thousand
s3's,
you
cannot
have
an
SLO
on
those,
because
it
means
that
you
need
to
complete
a
thousand.
A
The
impact
I
would
say
that
the
district
demote
the
most
of
this
quantity,
P
ones
and
then
the
rest
like
I've,
seen
s
for
SATA
p1
as
well
as
like
the
color,
is
really
often
it's.
It's
really
strange
at
the
front
of
the
pay
to
do
that.
Like
all
like,
let's
fix
it
now
so
that
allows
the
the
dimensionality
to
be
sliced
further
into
more
more
achievable
buckets
per
se.
Yeah.
B
A
Yeah
and
that
that's
a
revisit
about
variety
in
severity
labels
I
think
we
are
moving
towards
the
end
of
the
the
content
now
so
with
that
I'm
going
to
close
out
with
the
the
rollout
plan
on
our
label,
changes
and
I
think
it's
important
to
discuss
it
here
as
well.
Currently,
the
charge
packages
is
relying
on
the
previous
team
labels,
but
they're
now
evolved
into
state
jobs,
start
devop
stage
labels
with
that
there's
a
rollout
plan
on
how
we're
going
to
transition
it's
going
to
go
area
by
area.
A
As
the
the
labels
get
change,
we
will
transition
the
Patridge
package
to
also
apply
at
the
devops
sagely.
Well
as
well,
and
then
once
teams
have
gathered
into
groups,
then
we
will
narrow
it
down.
Ideally,
at
the
end,
you
will
see
a
triage
package
for
for
a
given
group,
probably
buddy
I
would
say.
Maybe
sometime
we
q3
when
all
the
teams
are
settled
down
their
respective
groups.
A
So
we're
gonna
close
this
recording
on
the
good
lab,
unfiltered
YouTube
channel
and
I
would
like
to
thank
thank
you
Greg
for
participating
today.
This
is
the
first
of
many
to
come
next
week.
We
will
be
diving
deeper
into
the
trash
package
b2
and
how
how
that's
going
to
play
with
the
stage
stage,
hop
splits
and
things
as
well
so
yeah
with
that.
Please
follow
along
in
the
YouTube
channel
and
Thank
You
Craig.