►
From YouTube: Areas of Focus Workgroup - 2021-04-22
Description
Areas of Focus Workgroup - 2021-04-22. The final meeting!
A
B
A
A
A
I
think
we'll
find
that
that's
pretty
much
true,
because
most
of
them
are
pretty
simple
or
they
go
to
like
we're.
Having
a
widespread
issue
kind
of
deal
so
get
lab
features
which
is
like
api
code
runners,
lfs
issue,
tracking
project
imports,
snippets
some
other
things
that
weren't
in
the
support
team
mammal
file,
seven
amer
one
apac
for
amia,
I'm
like
positive-
that
maybe
that
just
means
some
apac
people
haven't
put
it
in
there,
because
I've
worked
with
apac
people
on
the
get
lab
api.
A
A
Unsurprisingly,
a
lot
of
our
self-managed
people
are
knowledgeable
in
this
particular
area.
Since
that's
what
a
lot
of
self-managed
emergencies
are
about
eleanor.
When
I
looked
at
this,
it
said
we
have
five
amer
people,
two
apac
in
three
emea
again,
I
know
that's
inaccurate
because
I'm
pretty
sure
jane
correct
me.
If
wrong,
we
have
more
than
two
people
in
apac
working
eleanor
right.
A
C
A
Yeah,
I
definitely
think
part
of
this
is
going
to
be
me
announcing,
and
then
we
asking
managers
to
help
with
telling
everybody
hey
go
update
that
file.
It
is
super
important
we
keep
it
updated,
especially
not
just
on
like
the
knowledge
areas
front
but
like
we
have
a
lot
of
automations
that
use
that
file
like
the
pto
stuff,
that,
like
lyle,
wrote,
yeah
it's
using
that
file
too.
A
So
it's
really
important
that
files
accurate
managing
a
group
which
was
like
jenkins,
jr
repository,
mirroring
service
desk
storage
management,
web
ide
we're
looking
at
americoverage
six
apac
coverage.
One
emea
coverage
one:
I'm
I'm
pretty
sure
that
one's
actually
not
accurate
either
other
in
sauce
account.
I
skipped
them
intentionally
other
there's.
B
A
Way
to
say
how
many
people
we
have
other
just
basically
saying
everyone
in
theory,
but
also
no
one
in
theory,
because
it's
other
sauce
account.
I
also
skipped
because
we're
making
great
strides
like
what
I've
built,
what
ronnie's
built,
what
cynthia
is
doing
to
make
it
so
that
everyone
in
the
team
can
work
those
tickets,
regardless
of
their
access
levels,
secure.
A
We
kind
of
were
looking
at
one
coverage
per
region,
and
this
was
like
composition,
analysis,
dependency,
scanning,
dynamic
analysis,
license
compliance,
static
analysis,
we're
looking
at
one
per
region,
which
sounds
scary
until
you
look
at
the
volume
of
tickets
and
go
that's
actually,
probably
fine
security
incidents.
I
grabbed
the
cmocs,
because
that's
basically
what
these
are.
This
is
where
it
said
we
had
three
amer
people,
zero,
apac
and
six
emea,
and
I
know
for
a
fact-
that's
not
accurate.
A
A
A
So,
looking
at
this
very
rough
estimate,
we
should
be
fine,
I'm
kind
of
like
adding
values
in
for
like
apac.
I
know
you
all
have
cmok,
so
I'm
like
we're
fine,
especially
since
that
needs
like
point
four
of
a
person,
so
like
honestly,
that
that's
fine,
that's
like
a
one-off
when
incidents
happen
and
when
we
need
somebody
to
do
it.
A
A
A
A
A
It's
worth
just
taking
out
entirely,
especially
since,
like
from
what
I've
seen
and
cynthia
can
correct
me
if
I'm
wrong
cmoc
is
going
to
handle
those
and
that's
on
a
pager
duty
rotation
kind
of
deal.
So
it's
like
right,
we're
not
going
to
allocate
ac
mock,
we're
just
going
to
use
the
current
cmoc
system.
A
So
when
we
set
all
this
up
like
it
is
an
area
of
focus
for
us
to
keep
in
mind,
you
know
an
eye
on
to
make
sure
it
doesn't
suddenly
start
generating
tons
of
volume,
but
other
than
that,
it's
like
we
don't
actually
have
to
allocate
anyone
to
it.
It
won't
even
be
a
group-based
view.
It'll
just
be
a
regular
view
that
we
need
to
pretty
consistently
see
just
in
case
something's,
going
wrong.
A
D
A
A
A
A
lot
of
this
is
going
to
be
like
a
two-pronged
approach
of
there's,
the
zendesk
side
of
things
which
support
ops
will
handle
and
honestly
this
that's
not
a
big
change
for
support.
Ops
likely.
What
we'll
end
up
doing
is
having
a
new
field
that
says,
area
of
focus
or
sub
area
focus,
or
something
like
that.
A
That'll
make
it
easy
for
sds
to
pick
it,
but
we're
also
going
to
tell
zendesk
make
a
lot
of
triggers
and
stuff
to
say
this
ticket
go
ahead
and
put
it
in
this
area
of
focus,
because
we
already
know
what
it's
about
stuff,
where
the
customer
is
like.
I
can't
act
I'm
this
is
a
sauce
account
ticket
go
ahead
and
put
it
in
the
sauce
account
focus
because
that's
a
pretty
obvious
one
same
for
like
eleanor
and
stuff
like
that.
A
B
A
Concept
there
will
be,
you
know
when
we
update
our
process
of
whoever's
working
needs.
Organ
triaging
should
put
it
into
the
right
category,
so
they
get
kind
of
focused
on
initially
speaking,
I'm
probably
going
to
have
support
ops
help
triage
those
tickets.
A
lot
a
it'll,
be
good
for
the
team
and
b
it'll
make
sure
that
we're
able
to
double
check
everything
make
sure
it's
working
correctly.
A
The
other
side
of
that
is
going
to
be
the
support
process
workflow
side
of
this,
because
it
is
a
pretty
big
change.
So
that's
going
to
be
the
other
side
of
that.
I
think
that
one's
gonna
be
it's
not
necessarily
that
it's
difficult,
because
basically
it's
just
saying
instead
of
grabbing
from
this
huge
view
that
has
like
a
hundred
plus
something
tickets
in
it,
you're
gonna
grab
from
your
focus
views
it'll
literally.
A
A
The
concept
is
mostly
right,
but
we're
only
going
to
do
these
with
a
couple
categories
to
start
out
with,
and
I
think
we
agreed
with,
like
the
super
obvious
ones
like
sas
account
and
free
user
and
l
r,
but
then
also
probably
one
or
two
of
the
technical,
like,
I
think
we
said.
Authentication
and
ci
cd
were
probably
the
easiest
ones,
since
they
already
have
a
problem,
type
they're,
pretty
easy
to
route.
A
A
D
A
D
A
Yeah
cool
that
either
way
works.
To
be
honest,
I
don't
think
there's
like
a
hard
set
rule
for
get
lab
on
how
to
do
it
other
than
just
focus
on
the
async
part
of
it
but
yeah.
So
that's!
Basically,
I'm
thinking.
That's
kind
of
our
final
steps
from
here
on
out.
We
get
to
we
get
to
go
full
async
and
each
of
us
are
super
knowledgeable
on
exactly
what
it
is.
We're
aiming
to
do
so
it'll
it'll
be
helpful
of
I'm
confused
what
you
want
to
do.
C
I'm
thinking
about
our
current
what
we've
called
areas
of
focus
to
now
that
view
is
super
helpful
and
the
stuff
in
that
that
doesn't
fit
into
the
new
definition
of
areas
of
focus
like
onboarding
operations,
management
and
u.s,
federal
and
now
and
are
obviously
things
where
we
have
specific
needs
and
related
to.
That
is
also
how
that
feeds
into
our
ticket
baselines,
so
the
the
guidelines
on
ticket
baseline.
So
I'm
just
I
don't-
have
the
answers
to
those.
It's
just
something
that's
occurred
to
me.
A
So
I
think,
like
the
the
basic
thing
is
well,
we
were
implementing
some
of
it
to
start.
We
obviously
can't
go
change
the
areas
of
focus
and
support
team
ammo
if
we're
not
starting
all
of
them,
because
then
it'll
we'll
have
a
bunch
of
people
of
like
self-managed
is
this
percent,
but
then
we
have
some
percent
that's
off
and
it's
like
not
going
to
add
up
correctly.
A
I
think
in
the
end,
when
we
get
like
this
fully
rolled
out,
we'll
end
up
doing
a
change
to
have
the
support
team
yeah,
we'll
kind
of
reflect
the
areas
of
focus
to
make
it
a
little
easier
to
glance
to
say:
okay,
who's
authentication
focused,
okay,
cool,
it's
these
people,
according
to
the
team
page,
I
think
that's
what
we're
gonna
get
to.
I
think
it'll
be
a
while
before
we
actually
get
to
that,
though,
because
we
would
need
all
of
them
kind
of
live
to
make
it
not
start
conflicting
with
one
another.
C
Differences
to
understand
in
the
different
paradigms
the
different
architectures
you
know
between
sas
and
self-managed,
we're
not
necessarily
calling
those
our
high
level
areas
of
focus,
but
there
are
still
distinctly
different
things
for
people
to
learn.
I
don't
know
going
forward
when
we
onboard
people
and
teach
them
are
we
going
to
completely
obfuscate
that
I
wouldn't
have
thought
that
was
necessary.
C
A
B
C
But
we
do
still
start
with
giving
them
an
understanding
of
what
the
different
paradigms
entail
and
what
the
implications
are.
Even
with
that,
like,
I
know
the
people
that
I've
been
onboarding
in
that
approach,
the
most
effective
approach
I've
found
and
took
a
lot
of
that
from
from
ronnie's
experience
as
well,
was
get
them
to
really
understand
how
the
sas
paradigm
works
and
then
get
them
to
cross-train
into
self-managed
and
then,
as
a
consequence
of
that,
they
literally
fluctuate
between
whichever
they
need
to
be
focused
on.
D
Okay-
and
I
don't
think,
that's
ever
going
to
go
away-
I
mean
I,
I
rewrote
a
huge
part
of
the
dot
com
training
and
it
was
meant
to
be
a
basics
training
not
only
for
new
team
members,
but
also
for
existing
team
members
that
are
kind
of
moving
into
that
space,
which
I
know
like
weiming
is
sort
of
kind
of
working
on
like
how
do
you?
How
what
is
the
best
way
and
how
do
we
quickly
or
in
time
cross-train?
D
All
of
the
existing
team
members
that
are
currently
only
focused
on
one
and
it
was
and
and
part
of
you
know,
redoing-
that
training
ronnie
got
me
to
write
an
overview
page
and
I
think,
like
it's
pretty
short,
it's
like
a
screen
long
or
something
with
quite
a
bit
of
white
space,
and
I
think
it's
still
important
for
people
to
understand
that
sas
you're
working
in
a
different
context,
because
we
have
our
own
infrastructure,
we're
the
administrators.
We
have
access
to.
D
D
D
D
I
would
kind
of
see
us
as
like
on
board
it's
like
some
of
them.
I
don't
see
going
away
like
obviously
ops
management
and
onboarding,
like
as
kind
of
areas
of
focus.
I
don't
actually
see
that
kind
of
going
away,
because
those
are
a
little
bit
separate
from
kind
of
the
rest
of
the
cues
right,
like
working
in
the
queues
that
kind
of
designates
that
these
are
people
not
actively
working
in
queues
necessarily
like
on
a
regular
basis.
D
Even
though
I
appreciate
that
a
lot
of
the
managers
have
been
working
in
tickets-
a
lot
more
recently,
especially
in
amer
on
crew,
but
I
I
do
think
that
we
could
probably
use
the
rest
of
the
areas
of
focus
but,
like
jason
said,
I
think
we're
gonna
have
to
just
wait
to
like
that
kind
of
that
that
go
live
date,
whatever
we
set
it
to
so.
Actually
that
brings
me
to
the
question
I
had,
which
was.
D
So,
if
you
can
maybe
include
some
estimated
timelines
or
target
dates
for
when
we
would,
like
certain
at
least
larger
pieces
done
and
then
a
target
date
for
the
go
live,
I
think
that's
the
only
thing
missing
from
the
proposal
that
I
would
kind
of
like
to
see
just
so
that
we
have
these
target
dates
to
say.
Okay,
this
is
what
we're
planning
for,
and
this
is
the
work
that
needs
to
be
done
before
then.
A
Oh
yeah
for
sure-
and
I
don't
know
if
you've
ever
looked
at,
like
the
in-depth
ops
implementation
issues,
I
love
due
dates
and
blocked.
By
and
like
I
love
that
feature
of
gitlab,
I
use
it
a
ton,
so
that'll
definitely
be
in
this
proposal
of
here's
our
expected
due
date.
Our
target
goal
dates
and
then
we'll
get
to
like
the
implementation
issues.
There
will
be
all
kinds
of
cross-linked
of
this
blocks
this
and
this
blocks
this.
This
blocks
this
and
all
that
fun
stuff.
I
love
those
features
of
git
lab
they're,
my
favorite
thing.
A
A
A
I
honestly
don't
think
we'll
need
a
ton
of
time
to
test
this
out.
I
think
like
a
week
or
two
max,
because
I
think
that'll
give
us
the
feedback
we
need
from
whoever's
helping
test
it.
Whichever
ses
are
testing,
it
they'll
be
able
to
tell
us
yeah.
This
worked
great,
or
this
was
a
little
clunky
or
I
didn't
like
this
like.