►
From YouTube: Enablement Retrospective 14 6
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
B
Oh,
by
the
way,
all
right
have
we
everyone
forward
this
invitation
to
to
the
team
members:
okay,
yeah.
C
There
are
31
guests,
we
have
10
who
accepted
a
few
babies.
C
D
C
B
D
C
E
Sure
thing
yeah,
14-6,
obviously
was
a
lot
of.
It
happened
over
the
holidays,
and
so
you
know
the
holiday
season
bought
many
challenges
both
from
a
resource
and
in
this
the
technical
complexity.
I
think
the
we
bid
off
kubernetes
122,
upgrade
during
this
release
and
that
you
know
went
from
smaller
than
a
bread
box
to
to
pretty
big.
Actually
mitch
is
here
and
can
and
can
comment,
but
you
know
in
general,
we
we
were
a
little
slower
than
we
expected,
but
we
did
make
significant
progress
right.
E
It
wasn't
like
we
just
pushed
these
technical
problems
off
and
waited
until
folks
were
around.
We
were
able
to
continue
to
make
progress,
get
ourselves
in
a
position
for
for
14
7
to
complete
it.
C
Cool
thanks
for
that
cz
is
up
next
he's
not
here,
so
I
will
verbalize
for
him
on
the
next
two
bullets.
So
cz
says
thanks
to
the
team
members
who
provided
on-call
coverage
during
the
holiday
time
at
the
end
of
the
year,
there
was
lots
of
participation
there.
So
thanks,
everybody
and
cece
also
called
out
kudos
to
zach
cuddy
for
helping
with
the
global
search
ui
code,
refactor
fambion
you
are
covering
for
nick.
A
Yeah
one
thing
that
stood
out
last
release
is
that
kriti,
who
is
now
on
parental
leave,
did
a
great
job
shepherding
along
quite
a
few
data
types
for
geo
in
the
self-service
framework.
A
So
she
really
achieved
her
goal
of
having
all
four
data
types
verified,
and
it
was
a
big
success
moment
and
I
think,
with
all
of
the
stresses
during
the
holidays-
and
you
know
all
the
other
things
that
worked
out
really
well.
D
Yeah,
I
think
the
team,
the
database
team
did
a
great
job
wrapping
up
our
phase
four
blockers
for
the
sharding
group,
so
you're
welcome
craig.
Did
we
wrap
them
up?
I
think
we
did
them
all.
C
Yes,
yes,
and
on
that
note,
so
I
have
the
next
two
items.
So
it
was
noted
by
the
sharding
group
that
we've
received
great
response
from
all
the
engineers
with
respect
to
domain
knowledge
when
we
ping
them
for
loose
foreign
keys,
and
I
think
in
general,
especially
lately,
we've
gotten
great
response
when
we
reached
out
for
the
phase
four
blockers.
So
thanks
for
everybody
involved
and
pat
had
specific
praise
for
tong
and
the
work
that
he
did
with
the
sharding
group.
Fcl
for
incident.
C
Okay.
So
if
there
is
no
other
praise
that
folks
want
to
add,
then
they
can
add
asynchronously
to
the
issue.
I
move
on
to
actions
and
follow
up
so
cz
had
one
and
I
will
cover
for
him,
so
include
issues
under
the
gitlab.com
namespace
and
the
retro
template,
and
there
is
a
link
to
that
and
it
turns
out.
All
we
need
to
do
is
change
one
setting
in
the
yaml
file
to
include
issues
in
all
the
groups.
So
thanks
cz,
for
following
up
on
that
and
then
more
of
me
talking.
C
It
looks
like
I
have
I'm
going
to
cover
for
cz
under
the
what
went
well
so
from
the
memory
group.
Make
good
progress
on
projects
both
new
redis
instance
for
session
keys
and
the
new
sidekick
metric
servers
are
in
production
and
then
from
global
global
search.
We've
created
the
production
incident
management
documentation
in
our
building
up
and
abuse
prevention
framework
on
covering
for
nick.
A
Yeah
we
had
a
really
good
14.6
release
overall
and
we
shipped
the
first
iteration
of
secondary
proxy.
That
was
the
headline
feature
for
for
the
release.
We
verified
four
more
data
types
and
we
also
made
progress
configuring,
the
tracking
database
in
database
yammer,
which
is
also
relevant
to
some
of
the
sharding
work,
and
that
was,
I
think,
overall,
really
really
great
release
of
some
work
that
had
been
in
the
in
the
making
for
a
while
came
to
conclusion,
which
is
always
exciting,
and
some
other
work
was
iterated
on
within
one
milestone
and
didn't
really.
A
C
Okay
thanks
and
then
I
have
the
next
one
from
the
sharding
group,
so
we
had
a
great
discussion
on
the
timing
of
deleting
foreign
keys
for
phase
four.
This
is
an
entirely
new
endeavor,
so
I'm
getting
them
out
there
in
the
production
has
been
great.
So
we've
increasing
increased
the
number
of
loose
foreign
key
definitions
and
started
tracking
their
deletions,
and
we
have
even
more
good
news
for
the
next
retro,
but
I
will
leave
it
for
the
next
one
so
on
to
what
didn't
go
well,
stephen
or
mitch.
Whoever
wants
to
verbalize.
C
E
F
122
has
actually
been
out
for
a
few
months
now.
So
it
got
to
the
point
where
people
were
kind
of
curious
where
the
updates
were
coming,
and
so
what
I
think
we've
learned
from
it
is
that
we
can
start
looking
forward
better
into
upcoming
releases
and
what
deprecated
apis
are
going
to
come.
And
then
we
can
look
back
to
this
122
epic
and
see
all
the
components
that
were
required
to
upgrade
and
how
we
handled
that
in
the
past.
F
So
I
think
next
time
there's
going
to
be
a
big
removal
of
deprecated
apis,
we'll
be
a
lot
better
prepared
for
it
and
the
other
perk
of
it
is
it
forced
us
to
clean
up
some
technical
debt
items
that
we've
had
laying
around
upgrading
some
components
like
cert
manager
and
nginx,
which
has
been
really
great.
So
I
think,
even
though
it
turned
into
a
big
big
lift,
I
think
it'll
help
us
learn
a
lot
in
the
future
and
do
it
a
lot
better.
Next
time.
E
Thanks
mitch,
also
thanks
to
you
and
the
team
for
digging
in
on
that
pushing
us
forward
overdue,
I
guess
back
to
to
craig
for
cz
unless
there's
other
questions
on
kubernetes.
C
Okay,
so
what
didn't
go
well
so
from
the
memory
group
team
felt
that
the
sidekick
metric
server
extraction
took
too
long,
possibly
do
the
first
long
review
cycle
around
the
holidays
and
then
second
lack
of
documentation
and
then
also
from
cz
for
the
global
search.
We
found
that
we
were
not
compatible
with
the
latest
open
release
search,
so
we
need
to
investigate
and
come
up
with
a
plan
on
how
we're
going
to
deal
with
the
support
for
elasticsearch
and
open
search
and
issues
are
linked
there.
C
For
me
from
the
sharding
group,
I
didn't
link
to
the
retro
because
it
wasn't
called
out
in
there,
but
we
discovered
that
we
needed
to
bring
the
loose
foreign
key
implementation
forward
in
the
timeline.
I
think.
Originally,
it
was
part
of
our
phase
four
plan,
our
phase
six
and
we
need
to
bring
it
forward
to
phase
four
as
a
result
of
some
testing
results
that
we
discovered,
which
had
a
cascading
impact,
our
overall
timeline.
So
it
wasn't
great,
but
we
have
scrambled
and
adjusted
and
are
making
the
best
of
it
so
alex
database.
D
Yeah,
I
didn't
link
to
ardoc
because
we
didn't
talk
about
this
this
time
either,
but
I
think
partly
related
to
the
holidays,
but
we
had
very
low
participation
in
our
retrospective
again
this
this
month
and
so
we're
gonna
talk
about
that.
D
E
Gotcha
yeah,
I
think,
leveraging
off
what
what
mitch
was
saying
about,
having
a
better
idea
of
what
what
changes
are
happening.
I
think
that's
kind
of
the
theme
of
what
we've
learned
here
is
that
you
know
it
was
a
long
window
where
we
didn't
have
to
to
be
aware
of
these
changes
and
then
all
of
a
sudden
it
felt
like
you
know
we
got
thrown
into
the
fire
a
little
bit
to
get
caught
up,
and
so
the
idea
of,
like
you,
know
more
more
upstream.
E
I
added
this
comment
just
this
more
upstream
visibility
and
participation,
I
think
just
we're
so
heads
down
on
our
our
piece
of
work
that
sometimes
we
lose.
You
know
sight
of
the
the
whole
ecosystem
that
we're
built
on
top
of
it's
also
something
as
we
get
into
the
hiring
adding
that
is,
maybe
you
know
not
a
hard
criteria,
but
folks
that
have
worked
in
upstream
on
some
of
these
projects
that
we
use
would
be.
You
know
a
nice
check
box
to
at
least
add
if
folks
do
have
that
level
of
participation.
E
I
think
we've
got
the
skill
set.
We
just
don't
have
the
cycles.
You
know
the
team
is,
is
implementing
our
specifics
into
these
kubernetes
clusters
and
not
thinking
about
the
underlying
architecture.
E
E
E
I've
been
here
for
just
like
you
know
coming
up
on
my
third
year
and
we've
had
you
know
similar
metrics
in
place,
and
so
we've
been
able
to
kind
of,
stabilize
and
understand
our
patterns,
and
I
think
we
just
need
to
put
you
know.
Cognizant,
I
think,
is
a
good
word.
It's
kind
of
like
we
know
that
it's
there
yeah,
but
we're
not
we're.
Not
you
know,
including
it
into
our
equation,
for
for
scheduling
as
much
as
we
probably
should.
C
Yeah,
I
mean
anecdotally
from
what
I've
seen
in
the
teams.
It
seems
like.
We
should
probably
aim
for
like
50
capacity
for
december,
like
even
though
we
may
have
higher
goals
to
hit
like
we
think.
Oh
yeah,
we
can
do
all
this
work.
Stuff
always
comes
up,
people
always
extend,
I
think,
feel
burned
out
or
just
like
you
said
just
over
commit,
so
maybe
we
should
just
put
a
50
capacity,
hard
limit
on
december's.
E
Yeah,
I
think,
maybe
giving
the
product
folks
a
heads
up
that
hey
december,
because
that's
you
know:
distribution
in
particular,
we've
kind
of
got
this
dual
mode
of
product
deliverables
and
then
things
that
sort
of
come
at
us.
So
when
other
teams
are
scrambling
once
they
scram,
that's,
probably
not
what
I
should
say
when
other
teams
are
active,
it
increases
our
overall
level
of
activity
in
the
form
of
ours
that
come
to
the
team.
E
Okay,
well,
I
think
yeah
back
to
back
to
you
craig
sorry,
yep.
C
So
again,
covering
for
cz
for
the
memory
group,
so
matthias
pointed
out,
it's
unclear
what
we
would
need
to
be
what
would
need
to
be
tested
when
rolling
out
grpc
upgrade
involving
gitlab
and
gitly
integration.
So
I'm
assuming
there
is
a
follow-up
action
there.
I
will
make
sure
there
is
fabian
on
to
you
for
nick
ngo.
A
A
D
Yeah,
so
our
we've
we've,
the
database
team
is
constantly
in
this
struggle,
kind
of
which
is
between
being
more
of
a
a
feature,
focused
team
and
our
and
sre
right,
and
we're
we're
focused
more
towards
development
than
sre
right.
And
so
this
milestone.
D
We
spent
a
good
amount
of
time
discussing
kind
of
what
permissions
levels
team
members
should
have,
and
mainly
just
like
trying
to
understand
how
much
access
we
needed
in
order
to
look
into
problems,
but
not
so
much
that
we're
in
a
position
where
we're
doing
things
that
are
out
far
outside
our
scope.
B
That
that's
yeah.
I
agree
with
that
assessment
and
in
addition
to
that,
there's.
A
B
Perspective
of
you
know
the
from
security
perspective
minimal
access
to
the
system.
So
we
need
to
keep
that
in
mind.
Let's
stick
to
that
because
we
are
growing
and
the
company
is
maturing,
so
the
security
policies
we
must
stick
to
is
no
longer
like
early
startup.
Everybody
can
do
adversity,
so
we
need
to
make
sure
we.
We
are
compliant
with
the
security
guidelines
because
we
will
be
audited.
D
That's
a
that's
a
really
good
point
too,
and
we
didn't
talk
that
much
about
that,
but
it's
I.
I
think
that
we
settled.
I
think
that
we're
we're
largely
settling
on
a
position
where
we
have
fewer
fewer
permissions
rather
than
more.
That
said,
probably
more
than
a
typical
development
team,
but
still
not
quite
the
level
of
access
you
get
as
an
sre.
C
But
thanks
for
following
up
on
that
alex
all
right,
it
looks
like
we
have
some
time,
so
I
asked
some
questions
so
if
memory
serves
which
half
time
it
doesn't
serve
me
well,
but
this
is
the
third
enablement
section
retrospective
and
I
believe
the
original
goal
was
to
run
it
for
three
times
and
then
get
feedback
on
participation
to
see
if
we
should
continue
this
or
revert
back
to
the
development
department,
retro
or
maybe
some
other
outcome
altogether.
C
E
E
I'm
not
sure
I
would
go
and
look
at
them
all,
but
having
just
that
snippet
of
context
in
the
dock,
where,
like
hey,
here's
the
friction
point
and
here's
where
just
it
allows
it
to
be
kind
of
discoverable
and
so
typically
I'll
go
through
the
you
know,
as
the
dock
is
populated
and
look
at
other
teams,
you
know
actual
issues
and
to
kind
of
get
a
vibe
or
a
feel
for
you
know
what
they're
up
against
and
how
they
resolved
it
or
whatever.
And
so
that's
like
this
part's.
E
Okay,
you
know,
I
don't
mind
using
the
time
for
this,
but
I
do
like
having
those
issues,
and
I
think
you
know
the
team.
E
You
know
we've
seen
low
participation
and
I
I
I
think
the
team
probably
also
is
we're
super
asynchronous
by
nature,
and
so
I
think
that
kind
of
carries
over
into
our
retros
as
well,
and
the
idea
of
a
call
to
to
just
read
through
bullets,
I
think
is
maybe
doesn't
have
the
draw.
E
A
Thing
to
note
is
that
this
is
my
first
participation
and
I'm
doing
it
to
cover
for
nick,
so
I
have
to
say
that
so
far,
I've
not
had
it
high
up
on
my
my
own
agenda,
that's
maybe
my
own,
failing
just
for
from
the
one
observation
that
I
had.
I
think
these
sort
of
rollups
can
be
most
useful
if
we
find
patterns
across
the
organization
where
people
say
like
hey,
you
know
december
was
hard
for
for
those
reasons.
Then
we
can
act
on
a
sort
of
enablement
and
say
like
hey.
A
A
I
think
other
than
this
meetings
have
a
really
high
cost,
also
for
me
and
if
I
can
read
the
geo
and
database
retro
issues
in
my
own
time,
let's
say
in
the
morning
and
sort
of
get
a
feeling
for
what's
going
on
that's
easier
for
me
to
do
than
another
meeting
in
the
afternoon,
so
I
think
the
async
work
makes
that
sometimes
a
bit
hard
potentially.
B
So
trying
to
understand
so
maybe
a
suggested
format
of
this
meeting
I
mean
about
this
thing
meeting
is
basically
we
jump
on
to
identifying
some
patterns
and
discuss
what
we
can
do
in
the
future.
B
Instead
of
reviewing
what
went
well,
what
you
know,
what
didn't
go
well,
but
we
like
one
week
before
this
meeting,
everybody
think
about
what
pattern
of
the
issues
they
run
into
and
then
discuss
the
proposed
action
items
for
next.
Basically,
we
just
jumped
right
onto
this.
This
topic.
A
I
think
that
would
be
great,
I
think
also
I
don't
know,
but
if,
if
I
knew
as
an
individual
contributor,
if
I
raise
an
item
in
in
a
retro
that
everybody
who
manages
folks
in
enablement
will
think
about
it
and
will
try
to
like
act
on
it,
I
think
that
gives
also
incentive
to
raise
these
issues
yeah.
I
don't
know
I
I
like
that.
Suggestion
too.
B
Cool
since
we
are
all
here
I'll,
bring
this
up
back
at
circle
back
because
some
people
are
missing
here,
I'll
circle.
Back
I
see
if
everybody
agrees
that
we
can
take
that
approach
next
virtual
to
see
how
that
works
and
the
pilot
for
like
two
or
three
instances.
C
C
So
I
I
totally
agree.
I
second
everything
everybody
said
not
so
that
being
said,
sometimes
it's
a
forcing
function
for
me
to
quickly
get
up
to
speed
when
it's
being
read
out
because,
as
fanbian
said,
there's
a
high
meeting
load
for
me
personally
and
coming
into
these
meetings
and
having
to
read
the
bullets,
does
force
me
to
get
involved
and
participate,
but
that's
a
a
failure
on
my
part
for
not
being
prepared
in
advance.
C
So
I
think
switching
the
format
will
probably
get
folks
to
read
it
in
advance
and
participate
a
little
more
and
we,
as
managers
of
people
can
and
can
communicate
this
out,
like
hey
we're
changing
the
format
again,
participation
is
expected
and
your
comments
in
a
retro
could
trigger
a
deeper
conversation
in
the
department
retro.
So.
C
Thank
you,
that's
great
chun,
are
you
gonna
drive
the
format,
change.
B
C
Thank
you
all
right.
So
next
question
do
folks,
prefer
the
larger
department
retrospective
and
I'm
the
only
one
that
responded
here
but
I'll
take
responses
from
the
audience
after
I
verbalized
so
most
of
time.
For
me,
no,
there
have
been
occasions
in
the
past
where
I
learned
something
new,
but
those
can
be
gleaned
from
other
channels
if
I
follow
the
keeping
my
self-informed
handbook
entry.
So
all
right
people
are
typing
frantically.
Stephen,
you
gotta
know
yeah.
E
Same
async
rule
applies
here
as
well,
like
I
like
that,
it's
in
a
dock,
and
I
can,
when
I
have
cycles,
I
can
kind
of
browse
through
and
find
interesting,
interesting
tidbits,
but
in
terms
of
like
just
hanging
out
re,
you
know,
and
I
think
the
more
this
is
coming
back
to
me.
Didn't
they
recently
change
the
the
development
retro
to
just
sort
of
pre-summarize
key
points,
and
then
you
know
break
a
discussion
down
into
yeah.
You
know
the.
C
Group,
some
of
them
so
my
impression
of
that
new
format
was,
it
was
less
related
to
like
what
we
talked
about.
Our
new
format
would
be
like
patterns
or
topics
derived
from
the
content
of
the
retro,
and
it
was
more
of
hey,
suggest
some
topics
that
we
can
talk
about
and
we'll
vote
on
the
top
two
and
then
we'll
talk
about
those.
So
so
yes,
format
change,
but
it's
not
quite
what
we
are
planning
to
do
for
the
next
one.
E
B
So
so
looks
like
we
would
not
prefer
the
development
level
of
big
retro.
We
want
to
stick
to
the
our
sub
department
level,
smaller
smaller
group.
E
D
I
so
personally,
I
I
think
retrospectives
are
better
smaller.
In
my
experience
I
haven't
ever
been
to
a
development
department
retro
so
like
this
is
totally
I.
Maybe
this
is
totally
off
the
off
the
bounce
for
me,
but
I
think
the
the
larger
you
get
for
a
retrospective
audience,
the
the
less
actionable
it
becomes
in
a
lot
of
ways.
D
B
Okay,
the
intention
the
goal
to
broke
break
up
the
you
know.
The
big
retro
to
the
sub
department
is
one
make
the
issues
more
tangible,
more
relevant
to
the
smaller
group,
make
it
more
efficient,
more
efficient
and
also
encourage
participation.
So
we
achieved
part
of
the
goals.
The
topics
are
more
tangible
and
more
relevant
to
us.
The
drawback
here
is:
we
lose
the
global
view,
but
we
can
think
back
to
other
groups
so
that
async
communication
can
probably
solve
that
problem
and
moving
forward.
B
I
think
the
consensus
here
is
to
stick
sub
department
level.
So
let's
encourage
our
people
to
to
join
this,
and
I
I'm
not
sure
if
I
already
change
the
schedule
like
alternateness
to
morning
time
morning,
pacific
time
and
the
late
afternoon,
pacific
time,
I
will
do
that
if
that
hasn't
hasn't
happened.
So
we
can
encourage
more
people
to
to
join
the
retros.
C
All
right,
so
I
think
the
question
of
do
you
prefer
an
alternative
has
already
been
answered
through
the
discussions
that
we've
had.
So
I
will
skip
that
and
if
anybody
is
watching
this
and
they
want
to
provide
async
feedback,
they
can
I've
linked
it.
The
retro
below
some
observations,
so
participation
in
these
last
three
is
low.
This
is
a
pretty
representative
set.
Typically,
it's
just
the
managers,
and
I
looked
at
the
views
for
the
last
recordings.
They
were
around
42
and
15.,
so
people
are
watching
it.
C
E
C
So
I'm
looking
forward
to
the
different
format,
I
think
it'll
be
more
engaging
and
if
it's
not,
then
we
can
try
something
different.
So
that's
it
for
the
agenda.
Unless
anybody
has
any
other
topics,
then
I
think
we
can
call
it.