►
From YouTube: Monitor:APM Weekly Meeting - 2020-01-08
Description
Weekly meeting for the Monitor:APM team. Discussed 12.7 issues, new process for reviews, and using epics.
A
A
A
The
next
one
is
around
the
12.6
retrospective
I
have
to
apologize.
We
usually
try
to
have
those
open
for
the
entire
milestone.
We
did
not
do
that
for
her
12.6.
We
forgot
where
I
forgot
so
I
apologize
for
that.
But
if
you
have
anything
for
12.6,
which
I
know
was
a
little
while
ago,
please
add
that
to
our
issue
today
and
then
I'll
correlate
that
and
get
it
onto
the
team
retrospective,
which
is
the
gitlab
kind
of
company-wide
or
engineering
wide
one
happens
tomorrow,
so
I'll
kind
of
bubble.
Everything
up
to
that.
A
All
right
next
one,
that's
why
we
kind
of
point
this
out
that
I
noticed
we
have
quite
a
few
issues
in
12.4,
I
kind
of
got
out
of
control
a
little
bit
cut
a
little
high.
Usually
we
try
to
have
twenty
to
thirty
for
this.
This
milestone
we
originally
had
planned.
We
wanted
to
have
less
than
20,
because
we
knew
a
lot
of
people
were
gonna,
be
on
vacation
and
things
so,
but
we
ended
up
with
about
I.
A
Think
the
current
numbers
around
over
50
54
I
think
there
were
20
so
I'm
like
we
wanted
for
12.7,
but
a
bunch
moved
from
12
points,
six
into
twelve
seven,
and
then
we
added
a
number
after
the
milestone
it
started.
So
that's
how
we
got
to
this
number
to
kind
of
handle
that
for
now
a
couple
things
I
just
want
to
make
sure
everyone,
if
you
could
take
time
and
make
sure
everything
has
the
correct,
workflow
label
on
it,
then
that
will
help
us
kind
of
start
booming
things
out
of
twelve
seven.
A
A
C
A
That's
a
that's.
Another
good
point
is
having
each
other
reviewing
these
em.
Ours
will
help
us
share
knowledge
and
have
everyone
on
the
team
or
within
the
stage.
I
guess
get
more
familiar
with
the
different
things
people
are
working
on,
and
hopefully
that
will
make
everyone.
You
know
more
familiar
with
our
entire
kind
of
scope
of
the
product
which
is
important,
and
then
that
should
help
everybody
out
and
we're
gonna.
The
goal
would
be
to
have
people
kind
of
a
cross
monitor,
so
a
p.m.
and
health
be
able
to
review
it.
A
D
Sorry
yeah
this
release.
We
have
I
had
this
issue
that
Benson
a
couple
of
other
issues.
I
mean
from
what
I
noticed
is
that
all
those
were
moved
to
twelve
point
and
and
so
for
mine,
so
I
kinda
need
those
dependencies
to
work
of
mine
and
I'm,
not
sure
you
want
to
squeeze
those
issues
so
I
can
you
know
work
on
mine
or
sure
I
just
go
ahead
and
move
it
to
twelve
point.
Eight.
If
you
know
both
back
in
a
feminine
artful
yeah
for
this
release,
yeah.
A
A
D
A
B
B
Said
is
there
a
way
we
can
ask
danger
to?
Let
us
do
the
reviews,
for
that
case
in
point,
was
I
did
a
review
on
Postgres
expert
the
other
day
and
I
totally
agree
that
we
should
be
the
ones
doing
the
reviews
on
those
on
that,
such
as
a
modern
thing,
but
I
did
notice
that
there
have
been
a
lot
of
a
lot
of
changes
that
I
didn't
know
anything.
B
A
Yeah,
we
can
do
it
with
some
kind
of
coders
file.
That
would
probably
be
the
best
yeah.
Maybe
we
should
add
an
issue
under
monitor
somewhere
just
to
make
sure
we
don't
forget
about
that
and
track
it,
and
that
could
be
yeah
like
you
said
that
could
be
the
kind
of
the
follow-up
iteration
to
the
mr
that
I
have
linked
here.
C
Hi
everyone
so
since
I
joined
I
get
a
lot
of
three
months
ago,
I've
been
kind
of
covering
for
both
APM
and
health,
and
now
that
we
had
a
third
designer
joined,
the
monitor
team
looks
like
we'll
be
able
to
have
a
dedicated
designer
for
for
each
group,
so
I'll
be
working
with
you,
guys
I'll
be
the
dedicated
APM
designer
the
transition
will
happen
over
the
next
milestone
or
so
because
I'm
already
working
on
some
health
issues.
So
we
figured
that
we'll
try
and
make
it
as
smooth
as
possible.
C
So
likely
the
transition
will
happen
in
twelve
point,
eight
and
twelve
point
nine,
so
Emilia
will
still
be
working
with
you
guys,
but
we
will
kind
of
phase
out
over
time
and
the
new
designer
Matt
will
probably
be
working
on
one
of
the
new
one
of
the
new
groups.
Monitor
I,
don't
know
what
it
will
be,
but
yeah,
that's
that's
the
situation,
so
yeah
I'm
excited
to
work
with
you
guys.
A
Excellent,
thank
you.
Yeah
I'll
be
great
well
right
before
you
started,
we
set
up
a
group
in
get
lab
to
tag
like
all
the
designers
I
suppose
we
could
go
back
to
using
that
again
sort
of
make
sure
kids
were
headed
to
the
right
person.
I
can't
remember
what
it
was,
but
I
can
find
it,
but
yeah
we're
excited
that.
It's
great
good
to
hear
yeah
well!
A
E
E
It's
a
kind
of
one
of
things
that
that
Clemente
suggests
is
that
we
try
to
push
epics
more
because
not
only
because
they
are,
they
are
the
natural
choice,
but
also
because,
whatever
feedback
we
have
or
limitations
that
we
face
when
using
epics
should
hopefully
feed
back
to
the
product
and
to
the
create
stage
so
that
we
can
also
improve
the
epics
the
way
epics
work.
It's
a
bit
of
dogfooding
philosophy
here
and
at
the
end
says
Keeney's.
E
D
I
will
try
to
deliver
those
issues
until
we
consider
a
man.
Is
you
close?
So
that's
what
brought
epics
here-
and
this
is
to
answer
David's
question
you
so
desire.
We
can
ask
one
of
the
discussion
teams
to
help
us
with
this
presentation
or
I,
can
try
and
explain
using
some
of
the
previous
epochs
that
we
did
in
the
past
if
I
can
find
them
how
we
used
to
work
with
those
Acula.
D
A
A
Can
talk
like
dog
food
it
and
identify
how
we
want
epics
to
work,
and
maybe
that's
something
that
customers
want
as
well.
I
know
in
other
tools,
I've
used
epics
that
work
very
differently.
Then
they
work
at
gitlab
or
not
very
differently,
but
somewhat
so
there's,
probably
some
things
we
can
take
from
our
everyone's
past
experiences
and
other
tools
they've
used
as
well,
for
what
they
expect
epics
to
do.
A
I
think
the
nice
thing
about
epics
is
that
it's
easy
to
kind
of
consolidate
or
group
a
bunch
of
issues
together
into
one
place,
it's
easy
to
from
an
issue
to
figure
out
all
the
related
issues,
because
you
can
just
go
to
the
epic
and
find
it.
Those
are
the
nice
things.
The
hard
thing
that
we've
had
in
the
past,
which
is
kind
of
why
we've
been
using
these
kind
of
meta
issues,
is
that
you
can't
assign
people
to
epics.
A
A
A
A
We
can
certainly
I'm
definitely
open
to
changing
our
process.
We
can
update
the
handbook
around
if,
if
we
think
epics
are
better
placed
to
kind
of
have
discussion,
we
can
certainly
change
that.
My
my
thought
was
that
we,
my
original
thought,
was
we'd
have
these
kind
of
discussion
issues.
Those
would
be
like
the
first
like
way
to
generate
ideas
and
discuss
things
once
they
were
flushed
out
a
little
bit.
Then
we'd
create
an
epic
from
that
at
and
create
all
the
implementation
issues.
A
A
A
The
next
fiscal
year,
which
is
fiscal
year
21,
which
starts
from
once
from
February
this
February,
so
in
a
few
weeks
through
the
next
year,
I
think
our
our
current
hiring
plan
I
have
something
else.
I'm,
just
gonna
find
it
here.
So
I
can
make
sure
I'm
saying
the
right
thing,
so
I
think
our
goal
would
be
to
add
at
least
one,
maybe
two
new
health
or
two
new
monitor
related
teams.
A
So
the
teams
that
we
were
talking
about
and
we're
gonna
work,
so
I
should
back
up
and
say
first
of
all
that
Sam
started
this
week.
He's
a
new
director
of
ops,
so
I
be
like
my
manager,
so
he's
gonna
be
heavily
involved
in
this
process
and
will
kind
of
have
to
help
work
with
him
to
refine
kind
of
what
was
planned
before
he
got
here.
But
the
current
plan
would
be
still
have
a
APM
team
but
kind
of
split
out
logging
into
its
own
team,
so
that
would
be
kind
of
a
p.m.
A
what
kind
of
split
into
two
teams
kind
of
a
APM
which
would
be
like
tracing
arrow
tracking
and
then
create
a
logging
team.
Then
health
would
be
turned
into
more
of
like
a
triage
and
resolved
team,
which
would
be
incident
management,
alert
response,
SLO
management,
which
is
similar
to
what
they're
doing
today
and
then
there's.
We
could
also
there's
talk
of
having
a
separate
metrics
team
which
would
handle
cluster
monitoring,
infrastructure,
monitoring
and
just
metrics
in
general,
so
kind
of
focusing
in
on.
A
There'd
be
I
think
so
we
needed
at
least
one
more
front,
an
engineering
manager
to
kind
of
fill
Adrian's
position.
We
want
to
probably
hire
at
least
one
more
back-end
engineering
manager
and
then
once
those
are
in
place,
we
can
kind
of
start
talking
about
kind
of
splitting
the
team's
out
and
then
hire
more
front-end
engineers
or
back
into
engineers,
so
yeah
we'll
have
to
as
we
start
getting
into
the
next
month
in
the
year.
A
A
Hopefully
soon
I
would
think
it
has
to
be
because
we're
gonna
start
hiring
people
starting
in
February
our
hope
as
they
start
opening
wrecks
in
February.
So
so
we
have
to
finalize
the
plan
before
that,
but
there's
still
some
budget
questions
that
are
happening.
So
that's
all
going
on
right
now.
Does
anyone
have
that's
kind
of
all
I
know?
But
if
I
hope
people
have
questions,
let
me
know
I
can
try
to
answer
them
or
I
can
find
the
answers
for
everyone.
E
A
One
year
I
think
it's
gonna
be
a
lot
faster
than
that
I'm
guessing
it'll,
be
in
the
next
couple
months
that
we'll
start
hiring
more
engineers.
I
think
we're
gonna
have
to
talk
to
it's
kind
of
hard,
because
Sam
is
this
his
third
day
something
so
but
he's
gonna
have
to
be
involved.
I
think
we'll
do
something
similar
to
what
happened
when
help
and
a
p.m.
A
split-
and
some
of
you
know
this
better
than
I
do
but
because
you
were
here
before,
I
was,
as
this
was
happening,
but
we'll
start
probably
hiring
a
manager
and
some
engineers
on
the
existing
teams.
Until
we
have
enough
people
to
start
a
new
team,
we
don't
want
to
have
a
team
that
we
don't
want
to
split
up
our
teams
right
now
to
have
a
bunch
of
really
small
teams
that
aren't
effective
but
will
be
but
I
think
it'll
be
happening.
A
I
think
the
goal
is
that
start
hiring
people,
you
know
opening
recs
and
starting
to
like
figure
out
how
the
new
teams
are
gonna.
Look
starting
in
you
know
a
few
weeks
to
a
couple
like
few
weeks
to
a
month
or
two
so
I
think
it'll
happen
before
six
months
for
sure,
we're
not
sure
exactly
one
but
I
think
it's
in
the
next
month
of
June,
and
then
this
also
goes
like
Nadia
was
talking
about
we,
you
know,
there's
design,
implement
work
that
needs
to
happen
so
now,
there's
more
designers.
So
that's
awesome.
A
A
There's
a
somewhat
confusing
spreadsheet
that
I
posted
in
there
that
people
can
look
at
there's
a
I'm,
not
sure
how
public
this
is.
So
maybe
I
won't
share
it
in
a
video,
but
the
one
that
we
want
to
look
at
is
kind
of
the
first
tab
in
there
that
says:
FY
21
for
proposal
final,
which
is
a
very
somewhat
confusing
name,
because
it
is
it
final
or
is
it
a
proposal?
I'm
not
sure,
but
you
can
kind
of
see.
A
There's
like
one
section
that
has
the
end-of-year
plan
for
fiscal
year
20.
So
that's
where
we
should
be
or
so
right
now
and
then
the
next
section
is
how
many
people
we
want
to
have
at
the
end
or
our
current
team,
plus
adding
or
hiring
is
that
kind
of
that
section
section
for
proposed
hiring.
So
you
kind
of
look
in
there
and
see
where
we're
looking
to
hire
and
you
can
scroll
down
to
monitor.
A
I
still,
don't
quite
know
why,
but
it's
highlighted
differently
than
every
other
team.
So
it's
easy
to
find
for
now,
but
yeah.
If
you
it's
a
little
bit
in
flux,
still
and
I
haven't
been
super
involved.
Other
than
trying
to
ask
some
questions
and
try
to
figure
out
what
the
timeline
is,
but
we'll
we'll
try
to
get
more
information.
So
if
you
have
questions
about
any
of
this
feel
free
to
reach
out
to
me
and
I
can
try
to
track
them
down.
A
It
does
a
little
bit
so
I
think
this.
It
comes
from
so
dole
has
a
little
bit.
I've
talked
to
him
a
little
bit.
They
have
it.
He
has
a
little
different
definition
of
APM.
Then
what
we
had
been
using
to
him
APM
as
a
is
it's
not
so
what
we
well
we've
been
working
under
the
assumption
is
APM,
consists
of
metrics
logging
and
tracing
industry-wide.
A
Apm
means
is
it's
a
little
bit
different
than
that,
so
it's
more
around
like
it's.
It
has
a
little
more
focused
on
monitoring.
It
doesn't
necessarily
consist
of
metrics.
It's
so
metrics
are
like
a
little
bit
different,
so
it's,
but
it's
more
around,
because
it's
really
around
performance
management.
So
it's
monitoring
performance,
monitoring,
availability,
that's
kind
of
I
think
where
we're
going
with
like
the
term
APM.
So
that's
why
there's
separate
so
metrics
would
be
kind
of
its
own
standalone
thing.
A
A
Our
product
team
sees
our
monitoring
tools
and
how
they
kind
of
work
together
so
and
how
just
kind
of
logically
how
they
get
organized
again
from
an
engineering
standpoint.
If
that
doesn't
make
sense,
we
can
certainly
kind
of
tweak
that
and
work
with
them
to
come
up
with
teams
that
make
more
sense.
If
what
they've
thought
about
doesn't
fully
align
with
how
engineering
is
thinking
about
it.
B
Just
gonna
make
it
make
a
comment
that
is
also
regardless
of
how
we
define
a
BM.
It's
really
dependent
depended
a
lot
of
customers.
So
if
we,
if
we
define
it
one
way,
we've
got
to
change
our
definition.
Did
you
know
the
industry
is
defining
its
APM
so
that
you
know
our
messaging
is
consistent
with
in
the
world.
You
know,
but,
and
but
I
was
also
going
to
make.
B
A
Yeah
and
I've
used
sumo
logic
and
data
dog
where
they're
my
go
to
is
previously
so
yeah.
That's
a
good
point,
maybe
I'll.
We
can
create
an
issue
or
something
but
I
think
that
would
be
definitely
useful
to
either
have
demos
or
fine
and
link
demos
that
people
can
watch
of
these
different
products.
We
have
an
idea
of
what
features.
They
have
some
things
that
we
can
if
there
are
some
best
practices,
type
things
that
we
can
learn
from.
A
That's
great
I
know:
I,
don't
know,
I
pretty
sure
that
gov
he
he's
aware
of
all
of
these
and
is
very
familiar
with
some
of
them,
so
he's
basing
some
of
his
product
decisions
on
these
different
tools,
which
is
great
so
but
it'd,
be
good
for
the
wider
team
to
to
see
and
Mike
as
a
first
pass
or
a
first
iteration
it
could
just
be.
We
could
find
demos
of
them
I'm
sure
most
of
these
companies
have
either
marketing
material
or
her
community
presentations
that
they've
done
that
we
can
show,
and
some
people,
just
maybe.