►
From YouTube: Areas of Focus Workgroup - 2020-12-17
Description
Areas of Focus Workgroup - 2020-12-17
A
So
we
kind
of
figured
let's
build
off
of
that,
so
we
kind
of
had
a
draft
thing
of
at
the
towards
the
bottom
of
the
dock
kind
of
looking
at
the
problem
types
and
trying
to
fit
them
in
see
which
ones
kind
of
apply
here
summarizing
some
of
the
discussion
we
agreed
all
the
sauce
account
stuff
should
just
be
its
own
area.
It's
the
easiest
iteration
on
that
one,
just
because
they're
not
as
simple
to
kind
of
group.
A
So
I
think,
like
the
main
thing
we
should
kind
of
try
to
focus
on,
for
this
is:
let's
try
to
get
that
finalized,
those
basically
our
starting
areas,
and
then
the
question
I'm
kind
of
posing
is
once
we
have
our
finalized
areas.
Where
do
we
go
from
there?
Do
we
think
news,
zendesk
drop
down
and
just
start
kind
of
trying
to
categorize
every
ticket,
maybe
make
views
using
these
categories?
C
So
you
can
understand
what
your
staffing
needs
to
look
like,
how
much
time
needs
to
be
spent,
and
that
requires
understanding
what
that
historic
volume
is
so
once
we
have,
it
is
an
opportunity
to
go
back,
and
I
don't
know
what
the
right
number
of
months
are,
but
might
be
an
opportunity
there
to
get
that
distribution
to
see
if
we
actually
have
the
right
set.
If
you
will.
A
The
problem
would
be
any
problem
types
that
didn't
exist
in
the
past,
but
I
think
we
could
use
some
of
the
historical
like
closed
tickets,
where
we
can't
modify
them
to
get
that
data,
and
then
we
could
use
the
current
ones
that
are
open
once
we
make
you
know
the
set
of
the
form
or
whatever
to
kind
of
start
doing
the
same
thing
with
current
ones.
So
we
can
basically
say
this
is
the
kind
of
volume
we're
looking
at
for
the
various
categories.
A
B
B
B
E
C
Absolutely-
and
I
think
that
if
you
think
about
it
also
in
terms
of
distribution
of
tickets
and
then
take
that
to
the
next
step
of
distribution
of
time,
that's
necessary
to
work
solve
resolve
those
types
of
tickets
right
because
we
may
end
up
with
say
eight
categories,
ten
percent
of
them
each
in
each
in
each
of
the
eight
categories.
From
that
right
that
perspective,
but
then
you've
got
the
2080
rule.
Sorry,
80,
20
rule
whatever
it's.
You
know.
C
C
Yeah
and
the
the
flip
of
that
coin
is
the
amount
of
knowledge,
training,
etc.
It
takes
to
understand
those
tickets
right
so
and
that's
the
thing
right,
if
you
group
three
three
categories
together
that
you
know
this
group
is
going
to
work
these
three
categories,
it
just
needs
to
balance
out
whether
I
need
this
skill
set.
It's
not
the
three
lowest
categories.
It's
I
just
need
this.
These
comparable
skill
sets.
It
helps
me
solve
the
fast
ones.
Helps
me
solve
the
long
ones,
but
they're
different
than
the
one
long
one
over
here
in
geo.
A
D
C
Yeah,
I
think
I
I
like
the
idea,
lyle
and
I
think
the
one
thing
to
consider
is
which
side
drives,
which
side
right
so
to
we
rely
on
docs,
but
we
also
influence,
I
think,
docs,
based
on
what
customers,
experience
and
lack
of
talks
is
that
that
makes
sense,
and
if
I'm
capturing
your
idea,
the
right
way.
It
is.
B
C
Expectation
to
some
extent
is
that
customers
will
use
the
docs
find
their
answers
and
then,
when
they
can't
find
it
they
come
to
us
and
then
we
need
to
associate
those
back
to
doc
changes,
that's
very
simplistic,
simplified
view
of
the
world.
I
appreciate
and
also
don't
know
if
that
captured.
You
know.
B
The
thing
that
sort
of
like
I'm
trying
to
maybe
control
for
a
little
bit
is,
I
don't
have
a
lot
of
confidence
that
each
ticket
each
problem
type
associated
to
a
ticket
is
an
accurate
representation
of
what
the
problem
type
in
the
ticket
actually
is,
and
so,
even
as
just
sort
of
like
a
checksum
bit
do.
If
the
problem
type
is
h,
a
and
then
we're
linking
to
2fa,
we
could
at
least
say
something
isn't
matching
here.
C
A
So
customer
might
have
said
this
is
about
ci
cd
and
then
we
end
up
having
to
dive
into
problems
with
the
runner
that
has
nothing
to
do
with
their
ci
cd,
but
we
never
updated
the
problem
type.
We
might
be
miscategorizing.
So
I
do
think
the
docs
angle
is
an
interesting
way
to
go
because
the
docs
we're
kind
of
providing
are
going
to
say.
A
That's,
that's
what
we're
really
talking
about
in
the
ticket,
regardless
of
what
the
ticket
kind
of
started
with
the
only
problem
I
could
see
is
tickets,
where
multiple
problems
come
into
one
ticket
and
as
much
as
we
say
to
separate
those
that
doesn't
always
happen.
So
I
guess
we
could
like
multi
that
ticket
and
say
well.
This
is
about
2fa,
but
it's
also
about
h.a,
which,
by
the
way
is
doable
in
zendesk.
A
drop
down
field
can
have
multiple
fields,
we've
just
never
done
it
before.
A
A
So
I
do
think
it'd
be
important
that
whatever
categories
we
use
also
need
to
be
fluid
of.
Well,
it's
not
always
going
to
be
absolutely
one,
and
I
can
tell
you
like,
when
kind
of
in
the
mix
of.
Is
it
this
or
this
I'd
almost
rather
say
put
it
as
other,
because
it's
neither
it's
not
one
specific.
It's
both
yeah.
C
I
think
so
that
that
would
be
a
good
implementation
aspect
of
it
to
to
make
sure
that
we
can
accommodate
for
the
conditionals,
but
as
a
first
kind
of
approach
at
it.
Let's
understand
what
the
top
categories
are.
If
we
get
to
a
point
where
setting
those
top
categories,
we
set
them
up
with
the
opportunity
to
drill
down
into
conditionals
that
may
overlap.
E
What
I
was
thinking
is,
we
can
get,
maybe
the
proline
type
and
then
based
on
the
dogs.
We
can
see,
get
the
top
problem
types,
but
at
the
same
time,
if
there
is
some
dock
that
we
can
define
as
an
outlier,
then
we
can
easily
see
the
problem.
Time
was
not
correctly
assigned,
so
we
can
just
put
those
out
of
the
count,
maybe
and
by
the
way
I
had
a
script
that
can
do.
This
can
take
the
dots
and
can
group
them
based
on
the
problem
type
already.
E
A
A
I
think
using
both
of
those
will
get
us
a
good
picture
of,
but
yeah
everybody
says
it's
this
problem,
but
they
always
link
to
all
these
issues,
so
we
can
probably
drill
down
a
little
there
and
separate
them
out.
So
I
think
that's
a
good
way
to
go.
So
I
think
what
we
would
want
to
do
is
figure
out
the
problem.
Types
get
our
get.
Our
final
problem
type
grouping
get
those
to
ronnie,
so
he
can
use
his
script
to
use
those
plus
the
doc
links
to
help
find
all
the
categories
that
we're
looking
at.
A
So
the
deliverable
for
this
would
be
that
we
get
our
final
draft
of
those
problem
types
get
those
cerrany
and
then,
by
our
next
meeting
I
think
ronnie
will
be
able
to
have
like
the
data
he's
talking
about.
So
we
can
see
what
that
looks
like,
but
I'm
saying
that
tentatively,
knowing
next
week
is
christmas
and
the
following
week's
new
year.
So
we
might
have
to
like
reschedule
that
meeting
to
you
know
another
week
or
something
because
of
that.
A
E
A
D
Yeah,
it's
just
I'm
conscious
that
there
is
particularly
top
of
vg,
are
working
on
building
up
the
skills
matrix
for
support
engineering,
and
I'm
just
very
aware
that
right
now
we're
kind
of
working
in
isolation
from
each
other.
In
this
work
group
and
the
work
that
they're
doing
and
actually
as
lyle
says,
you
know,
I
hope
they'll
be
closely
interlinked,
but
right
now
that
would
only
be
a
happy
accident.
C
I'm
actually
thinking
it
might
be
a
useful
exercise
to
for
a
bit
longer,
keep
them
separate
and
allow
them
to.
You
know,
come
together
and
compare
notes
right.
So
what
are
the
skills,
major
skills
capabilities
that
they
see
that
are
like
congruent
to
solving
problems,
and
how
are
we
seeing
tickets
overlap
with
docs
and
in
the
categories
right
and
can
that
skills
map
to
what
we
would
potentially
distribute
tickets
to
right
and
again,
coming
back
to
the
skills
based
routing?
C
C
C
If
it's,
the
latter,
then
yeah,
I
think
we
need
to
figure
out
how
to
get
them
closer
together.
If
it's
just
trying
to
identify,
where
do
people
see
their
interests
and
their
you
know
current
skills
and
that
aspect
of
it,
then
I
think
we
can
eventually
map
them
and
say:
okay,
oh
how
far
off.
Are
we
right
from
building
teams
that
can
be
skill,
spaced
routed?
For
example?
I
just
keep
using
that
example,
because
it's
a
simple
sort
of
thing
that
doesn't
necessarily
be
skilled,
based
right.
C
A
That
makes
an
interesting
kind
of
thought.
Experiment
like
I
do
think
it'd
be
interesting
to
see
if
the
work
they're
doing
and
what
we're
doing
in
theory,
like
lao
said
they
should
be
closely
interlinked,
but
it
would
be
interesting
to
see
if
they're
not,
why
are
they
not
closely
interlinked?
Why
is
what
they
see
is
the
way
to
solve
a
ticket
different
than
the
categories
we're
seeing
tickets
come
in
at
us.
D
So
I
think
a
lot
of
their
categorization
not
exclusively,
but
a
large
chunk
of
it
is
also
from
our
training
modules.
So
there's
a
lot
of
thought
going
into
what
our
training
pathways
and
training
modules
are
in
the
consideration
of
the
skills
matrix
or
a
component
thereof.
So
it's
yeah
again.
I
all
these
things
to
me
should
be
well
interlinked,
training,
problem,
type
skills,
matrix
yeah.
A
And
I
know
like
one
thing
me
and
tom
atkins
have
talked
about
the
past-
is
every
time
someone
tries
to
do
this.
We
try
to
link
it
to
our
modules
following
the
flaw
of
oh
well,
these
are
our
categories.
No,
those
are
our
categories.
Those
are
modules
made
as
of
right
now
and
they're
modules
that
have
been
sporadically
made,
they're,
not
all-encompassing.
A
So
if
like,
if,
like
you're
saying
they're
using
the
modules
as
their
bases,
I
think
they're
going
to
miss
several
areas
because
of
that
because
it
like
the
last
time
I
tried
to
do
an
onboarding
revamp.
I
tried
to
do
the
same
thing
and
lyle
came
behind
me
and
went
hey.
So
here's
everything
about
gitlab.com
that
literally
you've
missed.
Because
of
that.
So
I
think
that
it'll
be
interesting
to
see
what
they
come
up
with
and
what
we
come
up
with
and
see
how
closely
interlinked
they.
D
A
Gotcha
gotcha,
okay
dude,
I
heard
somebody
the
other
day
say
thanks,
you
all
and
it
like
it
broke
my
brain.
I
was
just
like
what
hold
on
what
they're
like
what
and
I'm
like
what
I
like
how
why
and
like
this
wasn't
somebody
from
another
region.
It
was
like
my
neighbor
said
it,
and
I
was
like
what
no
you
you
were
born
here.
What
are
you
doing?
A
B
A
That's
all
good
all
right.
So,
looking
at
the
kind
of
draft
that
we
have
towards
the
bottom
of
the
dock,
it
seems
like
there's
still
a
good
bit
missing.
I
know
one
new
thing
we
added
was
the
support
for
get
lab
runners
that
came
from
that
lovely
emergency.
What
was
that
last
week,
while
this
week
time
has
blended
together
last
week,
yeah
that
came
from
a
dot-com
emergency
last
week
that
had
nothing
to
do
with
dot
com.
It
was
about
their
runners,
but
it
was
enough
of
a
problem.
As
I
started.
A
Just
because
it
is
a
different
component
of
gitlab
and
very
rarely
does
troubleshooting
on
the
runners
have
almost
anything
to
do
with
dot
with
git
lab
itself,
but
I'm
noticing
that
there's
still
some
problem
types.
We
haven't
kind
of
categorized
and
it
looks
like
it's
because
a
lot
of
them
start
entering
only
one
realm
of
it,
like
installation
help
is
almost
exclusively
self-managed
upgrades
migrations,
backups,
self-managed
file.
B
A
Yeah
kind
of
so
I
like
that,
like
the
configuration
help
where
it's
like
the
get
lab,
rb
and
pages
and
admin
panel,
I
feel,
like
that's
also
kind
of
part
of
like
installation,
help
getting
started
like.
I
feel
like
it's
just
a
continuation
of
it
but
curious
if
y'all
feel
the
same
way
like
do
you
feel
like
that's
its
own
category,
or
do
you
feel
like
that
needs
to
be
kind
of
generalized
into
something.
B
A
A
B
It's
like
global
configuration
help
because
there's
other
configuration
help
you
might
want,
like
I'm
thinking
of
a
github.com
administrator
who's,
trying
to
configure
something
in
a
project
or
in
a
group
where
it's
we're
not
looking
at
a
global
configuration.
We're
looking
at
like
a
group
level
configuration,
whereas
this
is
like
very
much
tied
to.
A
Could
we
use
the
term
system
system
configuration
help
instance,
or
instance,
configuration
help,
because
I
feel
like
that
separate?
It's
still
going
to
be
separated
from
you
know
the
from
sauce
from
com,
but
I
feel
like
in
corporate.
Like
I
don't
know,
I
kind
of
also
agree
with
ronnie's
thought
that
upgrades
back
ups
migrations
all
kind
of
fall
under
the
same
thing
as
configuration
help
it's
maintenance
managing.
E
A
B
B
A
D
A
A
A
A
B
A
E
B
E
E
C
C
Right,
because
we've
come
to
the
solution,
we've
tried
to
categorize
it
whether
or
not
that
categorization
is
correct
or
not
so
now
we're
trying
to
meet
those
together
and
not,
in
my
view,
not
in
a
how
do
you?
How
do
you
group
documentation
so
that
the
customer
can
find
the
right
thing?
It's?
How
do
you
get
the
customer
to
the
right
group
of
people
that
have
the
right
skill
set
for
the
type
of
thing
they're
encountering
at
the
time
right?
So
there's
this
we
categorize
at
the
end.
C
We
want
to
show
the
customer
the
right
things
at
the
beginning
and
then,
by
the
time
they
can't
find
their
answer.
We
want
to
get
them
to
the
right
person
right
and
what
we're
trying
to
figure
out.
What
is
that
right?
Grouping
of
people?
So
do
we
look
at
how
customers
are
going
to
look
at
it?
Do
we
look
at
how
we've
solved
problems
in
the
past
and
have
those
groups
of
people?
I
think
that's
the
right
way
right,
it's
looking
at!
Historically.
How
do
we
solve
problems?
C
How
do
those
group
up,
and
then
you
know
these
top
level-
things
that
we
talk
about,
might
be
good
as
we
categorize
and
group
doc,
searches
or
you
know
online
helps,
or
you
know
that
type
of
thing,
but
okay,
my
phone's
going
off
the
grid.
Let
me
just
silence
this
okay,
so
yeah.
That's
that's
how
I
you
know
we
we
we
kind
of
get
in
this
recursive
discussion,
cyclical
discussion
and
consider
that
which
way
are
we
coming
at
this?
A
Yeah,
like
I
do
I
I
kind
of
agree
of
like
when
the
customer
comes
to
us.
They're
not
gonna,
be
like
it's
an
instant
management
problem.
They're
gonna
come
to
us
with
it's
about
configuration.
It's
about
my
monitoring.
It's
about.
I
need
to
do
an
upgrade
like
they're,
not
going
to
come
and
say
it's
instance.
Management
expect
us
to
know
oh
yeah,
this
is
about
this
or
this
or
this
I
do
think
we
do
need
to
kind
of
like
going.
A
C
Yeah,
I
think
you
look
back
to
that
bigger
category
group
once
you
identify
you
know
what
are
those
groupings
and
then
we
can
say:
okay.
Well
now,
we've
got
these
bigger
groups
that
we
can
go
and
you
know
focus
different
attention
to
or
whether
it's
you
know
this
group
needs
more
documentation.
This
group
needs
more.
This
grouping
needs
more
user.
A
I
think
that
makes
sense,
so
in
that
vein,
I
think
we
can
maybe
simplify
this
instance
management.
I
would
agree,
has
licensing
issues
group
project
management,
I
would
say,
subscription
issues
because
that's
where
we're
going
to
encounter
the
subscriptions
are
applied
on
group,
name,
spaces
or
personal
namespaces.
A
A
A
A
B
B
B
A
E
A
And
tom
did
talk
about
the
whole
time
to
train
for
these
resolutions,
and
these
are
the
areas
where
it's
like.
This
is
the
most
intensive
to
train
somebody
to
solve
a
ticket,
even
if
it
is
I'm
trying
to
install
geo
to
help
out
with
that,
you
probably
need
to
have
installed
geo,
which
is
not
a
short
process.
C
Newness
I
was
trying
to
think
of
a
different
word,
but
newness
of
the
technology
and
innovation
and
implementation
within
gitlab
or
and
over
time.
It
won't
be
as
time
or
as
time
consumptive
for
knowledge
or
working
through
yeah,
I'm
trying
to
differentiate
between
things
we
introduce
that
take
a
lot
of
time,
training
and
knowledge
and
stuff,
and
then
once
everybody
seems
to
have
gotten
it's
like
now,
we've
simplified
all
of
how
we
do
installs
and
how
it
runs
and
everything
else.
So
we
just
kind
of
move.
A
So
with
kubernetes
I
could
say
it's
a
matter
of
once
we
all
get
to
where
we're
comfortable
with
it.
It's
easy
and
it'll
be
quick
with
aj
and
geo.
Even
if
you
are
an
expert
on
it,
just
asking
for
logs
is
is
difficult
because
which
logs
which
files
which
nodes
it
gets
complicated,
so
even
if
like
they
provide
all
logs,
that's
still
probably
like
20
different
files,
you're
going
to
have
to
review
it's
a
lot
comparatively
to
almost
all
these
other
issues.
A
C
New
technologies
introduced
rather
than
having
a
new
technologies
category
right,
so
you're,
going
to
introduce
new
technologies,
and
instance,
management
you're,
going
to
introduce
new
technologies
like
group,
project
management,
that
type
of
stuff
right,
yeah,
and
then
there's
these
other
things
about
just
managing
a
high
availability
environment
right,
a
scalable
environment.
To,
however,
you
want
to
phrase
it.
Okay,.
A
B
Can
I
offer
a
point
of
resistance?
Yes,
absolutely
think
that
we've
gotten
caught
in
this
trap
before
I
think
the
problem
types
are
separate
but
related
to
distribution
and
architecture,
but
distribution
and
architecture
like
there
are
uniquenesses
yes,
but
they're,
not
problem
types
by
themselves
like
if
I
am
having
trouble
getting
set
up.
B
I
having
an
installation
problem.
The
architecture
and
the
distribution
that
I'm
using
are
important,
because
using
installing
on
kubernetes
is
different
than
getting
set
up
on.
Github.Com
is
different
than
setting
up
geo,
but
the
problem
type
is
still
the
problem
type,
so
it
to
me
it,
but
it
does
kind
of
confuse
routing
a
little
bit,
because
what
it
does
is.
I
think
that
we
do
need
to
have
experts
in
those
areas,
but
then
what
you
you
don't
necessarily
need
to
be
an
expert
in
every
every
single
distribution
to
help
with
many
set
of
problems.
A
A
I
do
think
in
that
vein.
We
should
not
make
a
category
for
goha
because
they
should
fall
into
other
ones.
In
theory,
our
categorization,
just
because
it's
an
h.a
ticket
does
not
mean
you
need
to
know
everything
about
aj.
You
just
need
to
know
about
that
problem.
If
it's
sidekick,
they
just
need
to
know
about
sidekick.
Sidekick
on
aj
is
sidekick
on
omnibuses
sidekick
on
kubernetes.
B
A
Exchange
pretty
much
every
form
are
all
the
self-managed
and
the
partner
forms
currently
all
have
that
on
them
and
because
they
ask
your
installation
and
your
version,
the
sandbox,
they
even
ask
for
the
runner
version.
Now,
if
you
say
it's
a
runner
problem,
so
I
do
think
it's
a
sub
category,
but
it
means
we
don't.
It
doesn't
need
to
be
its
own
category.
A
A
B
B
B
A
A
A
A
B
A
This
can
go
under
that.
No,
that
licensing
description,
I've
typed
that
word
like
a
hundred
times
over
the
past
week
and
I
just
couldn't
type
it
importing
and
exporting
projects
and
groups
well
that
one
pretty
easily
goes
under
group
management
all
right,
so
we
got
authentication
and
authorization.
Where
would
that
one
go?
That's
like
saml
2fa,
ldap.
B
B
A
A
A
C
A
C
A
A
D
D
D
How
feasible
would
it
be
for
us
to
go
through
some
tickets
and
compare
how
the
customers
have
self-reported
them?
What
keywords
they've
used
in
their
description
and
then
what
we've
finally
landed
on
for
our
problem
types
over?
You
know
a
recent
period
just
to
kind
of
understand
how
the
customer's
brains
are
working.
A
B
A
I
will,
by
end
of
week,
make
a
spreadsheet
with
five
sauce
and
five
self-managed
or
whatever
10
random
tickets.
I'm
going
to
tell
you
what
they
are
I'll
pull,
10
random
tickets
and
the
spreadsheet
will
have
the
ticket
id
and
then
a
drop
down
for
what
you
think
the
category
is,
and
then
I
will
disseminate
that
to
you
all
with
instructions
to
make
a
copy
of
the
spreadsheet
and
then
go
through
and
categorize
each
one.