►
From YouTube: Support - Metrics Analysis Workgroup - 2020-09-22
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Yeah
happy
tuesday,
folks,
lyle
kozloff
senior
support
engineering
manager
in
vancouver
british
columbia.
This
is
the
metrics
analysis
working
group
work
group.
One
of
these
days,
I'm
gonna.
Look
it
up.
The
first
item
on
our
agenda
is
the
status
on
persistent
link
items.
Elia.
Do
you
want
to
take
us
through
those.
B
Right
so,
as
we
mentioned
before,
eleanor
is
doing
really
nicely
97
frt
this
week,
100
nlt
and
90
well,
nlt
is
also
climbing
up
so
beautiful
work.
Thank
you,
everybody
there.
I'm
sure
these
figures
for
the
month
of
september
are
gonna.
Look
much
nicer
and
asset
was
always
fairly
high
for
self-managed.
B
B
A
Thanks
for
that,
next
section
is
our
hypotheses
I'll
I
have
the
first
one
I
number
one
was
ticket
volume
is
too
high
for
the
team
to
consistently
achieve
frt
billy
and
I
went
through
this
yesterday
and
we
have
now
closed
it
out.
So
I'll.
Take
you
through
that.
Let
me
just
share
my
screen,
so
we
asked
the
team.
Some
anecdotal
questions
got
some
data,
but.
C
A
Ended
up
was
like
purely
theoretical:
let's
just
take
a
look
at
the
total
number
of
tickets,
total
number
of
tickets
per
engineer
and
our
head
count
that
grows,
and
assuming
that
I
mean
there
is
an
assumption
there,
like
we've,
always
met
for
the
past
12
months.
We've
met
our
goals
for
self-managed
eleanor
needed
some
work.
Dot
com
needed
some
work,
but
you
can
see
our
tickets
for
engineer
is
actually
lower
today
than
it
was
a
year
ago
and
even
during
some
of
the
heavier
times.
A
So
I
think
we've
been
hiring
at
the
right
rate
like
it's
pretty
october
last
year
was
pretty
bad,
which
makes
me
scared
for
this
october,
but
yeah
fairly
flat.
A
A
We
want
to
look
at
the
idea
that
gitlab.com
tickets
have
gotten
harder
anecdotally.
That
seems
to
be
the
case,
especially
now
that
we've
split
out
the
account
related
problems
and
the
non-account
related
problems
and
also
pared
down
2fa
and
a
lot
of
the
other
free
tickets.
A
A
So
if
you
look
12
months
ago,
the
number
of
internal
issues
we
have
is
very
different
than
what
we
have
today,
but
there's
also
like
mrs
to
docs
and
mr
product
things
like
that
that
we're
not
taking
into
account
in
the
overall
workload.
So
we
want
to
take
a
look
there
and
see
sort
of
how
those
contributions
are
balanced
and
we're
also
interested
in,
and
I
think
this
actually
ties
into
an
existing
hypothesis
already,
but
the
regional
position
and
number
of
engineers
working
on.com
tickets,
not
matching
the
pattern
of
like
sla
tickets
being
opened.
A
So
essentially,
people
are
in
the
wrong
region,
which
I
think
is
we're
already
taking
a
look
at
somewhere
else.
Any
questions
comments,
thoughts
on
that
one.
B
Just
to
add
that
it
seems
that
dot
com
says
is
doing
better
than
dot
com
general.
So
that's
kind
of
another
observation
worth
looking
into
in
regards
to
the
difficulty
of
the
tickets.
B
You
mean
account
related
account
related
is
doing
better
in
f14
and
ot
persistently,
and
the
dot
com
general
one
is
dropping
persistently.
C
Well,
I
was
just
thinking
for
eleanor.
That's
also
something
that
we
had
to
think
about
to
sort
of
figure
out.
Are
there
things
that
we
can
well
tom,
and
I
were
just
tom
atkins-
and
I
were
just
chatting
about-
maybe
other
things
that
we
can
stalk
people
with
that
aren't
as
difficult
and
then
moving
them
as
they
get
comfortable
moving
to
more
difficult
tickets.
C
But
then
it
does
become
the
question
of
how
do
you
measure
what's
difficult
and,
what's
not
so
I'd
just
be
interested
to
to
know
what
what
we
think
about?
I
think
tom
and
I
were
just
we
just
sort
of
looked
at
how
long
it
takes
on
average
to
investigate
and
close
out
a
ticket.
That's
specific
to
a
certain
topic
and
sort
of
went
with
that
as
a
preliminary
thought.
B
We
had
a
long
discussion
about
it
yesterday,
one
of
the
challenges
in
working
based
on
time
to
resolve
full-time
resolution.
Any
ticket
timers,
is
that
we
have
many
different
automations
that
kind
of
interact
together
with
the
ticket
length.
So
we
can
eliminate
some
of
them
from
our
calculations,
but
then
you
come
to
the
question
whether
any
specific
number
actually
represents
difficulty.
B
So
the
idea
that
we
came
up
with
we'll
see
how
that
goes
is
to
present,
perhaps
a
field
which
is,
of
course
subjective
which
would
be
filled
in
during
the
ticket
or
at
the
end
of
the
ticket,
which
would
be
a
subjective
feeling
of
how
the
ticket
felt
like
for
you
kind
of
a
level
of
subjective
difficulty.
B
We
would
have
to
monitor
it
over
time,
create
a
baseline,
see
how
it
affects
different
things.
But
from
that
in
regards
to
your
question,
we
can
maybe
deduce
after
a
certain
amount
of
time.
This
problem
type
typically
gets
this
amount
of
difficulty.
So
most
people
mark-
I
don't
know
upgrades-
is
hard,
then
maybe
for
newcomers.
We
might
not
give
them
a
problem
type,
which
subjectively
receives
a
lot
of
high
marks.
A
The
other
thing
that
that
might
unlock
is,
we
could
see
like
if
an
individual
is
consistently
rating
tickets,
hard
like
more
than
say
the
average.
Then
it's
just
a
sign
where
it's
like.
Okay,
this
person
actually
needs
a
bit
more
training
and
we
can.
We
can
do
that
or
in
aggregate
if
the
team
is
rating,
many
many
many
tickets
hard,
then
yeah,
like
literally
I
said,
with
the
with
the
problem
type.
A
We
can
break
that
down
a
little
bit
and
be
like
okay,
everybody
is
having
a
problem
with
nuget
tickets,
which
are
really
hot
on.com
right
now.
Let's
do
some
enablement
on
nougat
and
we
can
talk
to
pms.
We
can
talk
to
we
can
we
can.
We
can
get
people
to
like
help
solve
that
problem
or
even
assign
a
couple
of
specific
engineers
where
it's
like
you
be
the
expert,
be
the
escalation
point
and
then
help
the
team
get
better.
A
C
Well,
no,
I
love,
I
love
the
idea
that
it's
that
it's
subjective
and
that
it's
ticket
focused
like
you're
on
a
ticket
and
you're
thinking.
Oh,
this
is
taking
so
long
like
I
had
a
pairing
today
and
we
literally
spent
the
entire
pairing
on
one
ticket
which
to
me
is
just
like
that's
weird
like:
why
are
we
spending
an
hour
on
a
ticket
and
so
that
I,
I
would
say
that's
hard
because
it
took
all
our
time?
Yes,
we
got
to
the
answer,
but
like
that's,
we
want
less
of
that.
C
We
want
to
make
that
easier.
So
I
love
that.
I
think
what,
when
we
thought
through
stuff,
it
was
basically
just
me
saying
on
average.
It
probably
takes
me
about
half
an
hour
to.
If
I,
if
I
look
at
that
issue
type,
if
I
know
that
ticket
is
about
refunds,
that's
going
to
be
super
straightforward,
10
minutes,
I'm
just
passing
that
to
berlin,
so
I
was
in
the
position
to
be
able
to
sort
of
say
estimated.
C
This
is
this,
and
so
we
got
to
sort
of
just
the
timing
and
I
believe
that
at
that
point
in
time
the
ones
that
took
the
longest
were
the
most
tricky
ones,
because
you
want
to
cover
all
your
bases,
but
I
wouldn't
like
say
that
that's
going
to
be
true
all
the
time,
because
the
ticket
types
change
and
they,
if
bugs,
are
introduced
they
take
longer
or
if
features
are
shipped,
then
that
could
help.
So
it
is
a
bit
more
fluctuating
and
I
think,
having
something
like
that.
C
B
B
Cool.
I'm
happy
that
you
approve
it.
I
think
yeah
we'll
be
able
to
do
something
about
it
in
the
future.
It
will
take
time
to
collect
data.
Of
course
we
want
to
create
a
baseline,
but
it's
the
best
that
we
can
come
up
with
now.
A
So
moving
on
to
number
well
two
is
already
closed,
so
we're
moving
on
to
three
hypothesis
is
focus
on
pt
over
summer
and
friends
and
family
dates
that
cause
lags
and
performance.
I
really
do
have
an
update
on
that.
C
A
Supported
or
anything
else
that
we
need
to
take
a
look
at.
I
know
for
me,
there's
an
action
item
that
dilly
and
I
talked
yesterday.
The
spreadsheet
needs
just
some
work
because
it's
very
old
and
there's
many
more
managers
at
individuals
that
aren't
actually
exposed
in
the
spreadsheet
as
belonging
to
or
like
yeah.
So
I
will
fix
that,
but
in
terms
of
actual
data
to
gather
things
to
look
at
are
we
satisfied.
B
C
In
the
mirror,
we
did
have
a
discussion
between
the
eleanor
folks
about
how
pto
affects
the
queue.
I
think
what
we
just
saw
is
that
for
us
there
just
wasn't
a
focus
on
being
aware
of
who's
taking
off
when,
unless
you
look
at
the
calendar,
which
we
should
just
do,
we
should
just
be
more
mindful
of
oh.
This
person
is
going
to
be
off,
so
we
just
need
to
keep
that
in
mind,
so
it
was
less
something
that
we
wanted
to
solve
with
the
process
and
just
something
that
we
wanted
to
say.
C
B
A
D
Yeah,
I've
gotten
this
to
a
point
where
I'm
pretty
confident
of
the
hypothesis,
but
that's
actually
two
different
results.
There
might
be
a
different
different
one
for
lnr
as
well
I'll
just
share
my
screen
here.
D
Yeah,
so
thanks
to
ilya,
who
I
kind
of
collaborated
with
last
friday,
I
believe
yeah,
the
data
is
validated.
It
tells
us
what
we
actually
think
it
does.
So
that's
good,
so
the
hypothesis
being
our
staffing,
isn't
spread
appropriately
versus
the
number
of
tickets
that
are
raised
or
will
bridge
per
hour.
I
believe
in
the
case
of
self-managed.
D
That
is
true
to
a
certain
extent,
in
the
sense
that
yes,
so
if
you
kind
of
look
at
the
average
of
a
percentage
of
bridge
tickets
throughout
the
last
12
weeks,
you
can
kind
of
see
it's
kind
of
flat.
This
is
pretty
low,
it's
like
five
percent
or
below,
except
for
utc
9,
10,
11
and
12
midnight.
So
these
hours
are
pretty
poor
in.
In
a
sense
I
mean
they
should
look
at
all
soas,
including
frt
and
nrt.
D
So,
if
you
take
this
result
together
with
the
fact
that
our
self-managed
kpis
are
doing
pretty
okay,
I
would
say
that
yes,
there's
there
are
enough
hands,
they
are
just
not
spread
or
they
are.
They
are
just
not
activated
or
not
available
at
the
hours,
which
are
the
roughers.
D
I
guess
in
terms
of
q,
if
you
look
at
says
it's
a
bit
different,
so
you
can
see
there's
a
peak
at
1pm
utc,
even
the
lowest
point
is
actually
five
percent,
so
the
rest
of
it
is
actually
doing
pretty
poorly,
like
15
here
37
at
3am,
which
corresponds
to
apec,
and
I
think
this
is
aimer.
Basically
it's.
You
know,
you
know
yeah
18
28,
so
together
with
the
overall
kpis,
not
here,
which
is
the
overall
frt
percent
and
nrt
percent.
D
I
think
it's
fairly
clear
that
in
this
case
it's
not
a
matter
of
distribution,
there's
just
something
else
that
is
going
on,
and
I
think
we
are
really
working
on
that
with
the
other
hypotheses,
so
yeah,
I'm
very
confident
about.
D
These
graphs
right
now,
the
next
step
for
me,
would
be
to
work
with
ilia
and
see.
If
we
can
include
this
in
a,
I
don't
know,
forecast
or
planning
dashboard
somewhere
yeah,
because
there's
a
few
dashboards
done,
I
think
yeah
instead
of
creating
a
new
one,
let's
see
where
it
fits
any
any
questions
about
this.
A
A
And
then
the
hot
spot
in
self-managed
like
it
was
a
slow
burn,
but
there
was
a
bit
of
a
spike
at
the
emea
apac
handover.
Do
you
mean
decess?
Sorry,
I
mean
yeah,
sorry
on
sas
a
mirror,
a
miami.
D
Yeah,
it's
like
a
slow
burn
and
then
it's
a
bit
rough
in
the
impact
mornings
this
this
area
of
the
apec
mornings.
This
is
the
I
think
this
is
the
time
where
the
folks
in
india
time
on
well
around
india,
it's
not
all
of
them
are
in
india
and
then
yeah.
This
is
this
is
a
emea
spike?
This
is
at
1
pm
utc.
D
So
I
think
this
graph.
As
far
as
is
concerned,
it's
pretty
useful
in
terms
of
figuring
out,
resulting
I
guess
which
parts
of
the
day
needs
further
attention,
whether
that's
in
terms
of
hiring
or
in
terms
of
redistributing
existing
resources,
whereas
yeah
the
self-managed
graph
be
more
useful
to
identify.
D
A
Yeah,
that's
I
mean
that's
two
things
kind
of
spring
in
my
mind,
which
of
course,
hypothesis
generate
hypothesis
generate
hypothesis,
but
I
think
at
least
west
coast
amer
is
generally
has
higher
location
factors,
so
we
haven't
been
concentrating
on
hiring
there.
So
we
have.
We
do
have
a
few
engineers
but
yeah.
If
we
give
it
that
we
can't
necessarily
hire
there,
then
yeah.
Maybe
there
is
something
we
can
do
to
organize
work
better.
This
is
great.
This
is
really
yeah.
I
would
like
to
yeah
look
at
this
every
week.
D
Cool
we
actually
faced
the
same
problem
apac,
which
is
eastern
apac,
which
would
be
the
the
leading
part
of
the
day.
Yeah
the
location
factors
are
higher
as
well,
so
there's
a
there's,
a
there's,
a
bias
not
to
hire
there,
which
I
think
is
resulting
in
what
we
are
seeing
in
the
earlier
part
of
apec
so
yeah.
That
is
the
same
issue
with
western
email.
I
think.
B
Or
work
later,
but
I
just
want
to
point
out
that
1
pm
utc
is
9.
00
a.m,
eastern!
So
it's
exactly
before
they
log
in
and
for
us
it's
like
3
p.m,
4
p.m,
depending
on
the
region
of
the
individual.
So
it's
kind
of
the
end
of
the
day.
So
obviously
we
can
focus
on
hiring
more
in
western
europe
and
east
europe,
but
I
mean
yeah.
It's
yeah.
D
I
I
came
across
while
looking
into
these
charts,
which
is
it
again,
I
can't
say
for
sure,
because
I
just
quickly
skimmed
through
it,
but
I
think
it
appears
that
effect.
People
are
morning,
people
for
some
reason
and
then
emir
and
evil
people
are
not
mourning
people.
I
I
have
no
idea
why
that
is
but
yeah
think
that
as
an
adult,
instead
of
as
a
fact
right.
D
I
I
wouldn't
go
so
far
as
that
data
to
back
it
up.
I
just
happen
to
look
at
it
very
briefly:
I'm
not
sure
if
the
data
really
supports
it,
so
I
need
to
validate
that
that
thought.
B
I
do
want
to
point
out
another
small
factor
involved
so
that
time
of
the
day
is
our
highest
ticket
volume,
even
a
bit
before
that
one
hour
before
that,
so
between
I'm
talking
in
gmt.
But
it's
around
the
time
one,
two
three
gmt,
that's
our
most
busy
power
of
the
day
as
well
of
incoming
tickets,
at
least,
but
assuming
that
some
of
them
would
be
starters
breaching
24
hours
after
or
so
yeah.
A
Any
additional
comments
on
that
all
right
moving
along
and
I
I
do
have
a
hard
stop
at
the
top
of
the
hours,
because
support
group
conversation
feel
free
to
join
but
we'll
try
and
go
through
the
next
ones
quite
quickly.
Number
five,
adding
lnr
has
drawn
resources
away
from
the
rest
of
the
queues
that
haven't
been
replenished.
Don't
you
guys
think
where
what's
our
status
on
this
one,
it
felt
like
we
had
some
resolution,
but
it
hadn't
been
quite
closed
out
yet.
C
Yeah,
so
I
just
closed
it
out
and
the
resolution
there
is
that
it
is
somewhat
a
thing
or
somewhat
proven,
but
the
next
step
was
opening
an
issue
to
document
the
approach
to
the
matrix.
So
I've
done
that
and
just
marked
it
as
whip.
So
I
just
need
to
work
on
that
one.
But
I've
closed
out
the
main
hypothesis,
one.
A
Thank
you
number
six.
I
have
no
update
on
that.
Is
me
right.
Yes,
number
seven
is
already
closed
and
that
brings
us
to
the
end
next
week.
I
think
we
still
have
a
few
more
to
close
out
specifically
number
six
and
women.
Sorry,
we
actually
on
yours.
A
D
A
Now
we
haven't
gotten
to
our
closing
or
our
exit
criteria,
so
I
do
let's
prioritize
that
for
next
we
come
and
put
it
top
of
the
agenda.
I
think
we
should
also
be
a
faster
meeting
next
week
because
we
have
fewer
hypotheses.
A
We
should
also
talk
about
next
week,
which
additional
ones
we
want
to
add
on
now
that
we've
generated
more,
but
let's
quickly
go
through
our
exit
criteria,
and
I
actually
have
a
website
up
this
week,
so
define
conditions
under
which
this
work
room
will
be
reformed.
We
have
not
done
that
yet
create
a
dashboard
that
exposes
metrics
and
targets
that
trigger
actions.
I'm
part
of
the
support
team.
We
have
we're
doing
good
on
the
dashboard
and
we're
adding
more.
We
are
not
sure
about
which
actions
to
trigger.