►
From YouTube: [REC] Enablement retrospective - 14.4
C
D
A
E
A
C
Great
it's
easy
yeah.
This
is
the
first
time,
so
I
give
the
kudos
to
all
the
team
members
for
the
global
search
team.
The
team
worked
actively
on
the
performance
improvements
for
the
elastic
search
search.
Latencies
we
improved
from
average
is
about
200
milliseconds
before
to
under
mostly
under
50
milliseconds
at
the
moment,
also
kudos
to
the
memory
team,
that's
very
bonded
to
the
priority
shift
to
the
radius
very
quickly
and
also
moving
the
project
forward,
I'm
turning
it
over
to
josh.
D
Yeah
all
amazing
contributions
just
wanted
to
add
one
more
on
the
efforts
grant,
mcnelia
and
others
have
made
on
get
we've
added
support
in
the
last
couple
weeks
for
rds
elastic
cash.
You
know
a
number
of
I
mean
amazon
cloud
services
as
well
as
also
support
for
failing
over
from
the
primary
to
secondary
via
get
as
well,
which
is
amazing,
so
this
will
help
our
own
testing
and
efficiency,
as
well
as
any
water
committee
members
who
want
to
deploy
our
weapons
architecture
as
well.
A
G
A
B
Yep
so
had
a
lot
of
nice
momentum
on
sharding
during
this
milestone,
so
the
load
balancing
for
multiple
database
support
was
merged
had
really
good
progress
across
lose
foreign
keys.
I
don't
want
to
blur
the
lines
between
milestones,
so
it's
in
staging
now,
but
I
think
I
have
14.5
and
then
all
the
cross
database
queries
were
analyzed
and
we
created
the
allow
list
which
is
out
so
that's
it
for
starting
on
the
dj.
E
Yeah,
so
for
the
distribution
team,
this
milestone-
this
is
following
up
on.
You
know
our
our
ga
of
the
operator,
we
kind
of
taken
some
time
to
focus
inward
on
we've
had
a
lot
of
great
deep
conversations.
This
release
in
the
team,
around
team
direction,
focus
and
a
lot
of
kind
of
dives
collaboratively
into
our
technical
debt,
and
we've
made
some
great
progress
on
identifying
some
of
our
biggest
technical
debt
categories
and
the
team's
done
a
great
job
of
starting
to
put
together
our
path
forward
for
some
real,
meaningful
impacts
to
that
technical
debt.
F
F
We
also
shipped
our
verification,
backfill
worker
that
was
blocking
release
of
verification
for
some
other
data
types,
and
we
made
some
good
progress
on
rail
six.
I'm
making
geo
tracking
database
use
the
rail
six
mini
dv
support.
We
also
completed
the
migration
of
uploads
replication
to
the
self-service
framework
and
that's
enabling
us
to
quickly
follow
up
in
the
next
couple
milestones
with
support
for
verification
of
uploads,
as
well
as
removal
of
around
1600
net
lines
of
code
last.
B
So
it's
pretty
cool
and
another
team
ended
up
using
it
and
they
were.
If
I
remember
correctly,
they
were
expecting
the
traditional
timeline
of
a
migration
to
take
two
weeks
and
it
ended
up
getting
done
in
a
day
and
they
thought
something
went
wrong
because
it
auto-tuned
itself
so
quickly
and
was
so
efficient,
the
migration
that
they
thought
there
was
some
failure
and
it
turns
out
like
nope.
It
just
got
it
done
in
a
very
efficient
way,
so
they
were
very
happy
and
it's
on
our
backlog
to
actually
make
this
generally
available.
B
A
B
G
A
B
Okay,
so
we
had
some
lingering
issues
with
the
merge
request.
Diff
commits
normalization
so
actually
migrating.
The
data
took
a
long
time,
if
only
we
had
some
batch
background
process
that
would
have
been
generally
available.
That
would
have
sped
this
up
quite
a
bit
not
available
for
this.
When
we
shift
the
mr
and
then
there
was
a
secondary
issue
with
that
had
to
do
with
an
edge
case
with
import.
So
there's
a
version
version
mismatch.
B
If
you
go
back
far
enough
on
an
import
and
export
to
an
import,
it
will
miss
the
data
change
and
then
there
will
be
some
attribution.
That's
been
dropped,
but
there
was
a
fix
for
it.
That
was
already
shipped.
It's
just
extra
work
that
we
did
and
it
again
speaks
loudly
to
the
need
for
qe,
more
qe,
folks
and
enablement,
because
had
we
had
them,
they
probably
would
have
poked
at
that
a
bit
for
us,
but
we
just
don't
so
we
don't.
We
do
now.
E
Yeah,
so
over
in
distribution,
we
had
an
issue
where
we
had
to
revert
our
grafana
upgrade.
So
this
is
actually
the
upgrade
had
gone
in
the
previous
release,
but
only
here
in
1404
we
had
realized
that
we
had
missed
some
license:
validation
on
the
administration
of
grafana,
and
so
after
reviewing
that
we
went
ahead
and
reverted
the
upgrade
to
give
ourselves
a
little
bit
more
time
to
do
that.
Full
evaluation,
as
is
needed
on
a
license,
change.
A
E
Yeah,
so
in
in
this
case,
we
do
run
a
license
check
against
it,
but
in
this
case
we
were,
it
also
was,
depending
on
us
manually,
specif,
providing
the
license
file
in
this
particular
software
case.
So
yeah
we
still
have
to
continue
to
look
into
ways
to
get
away
from
that,
so
that
it's
you
know
we're
scanning
what's
coming
in,
rather
than
you
know
having
to
make
a
human
decision
on
where
the
lights
or
on
what
the
license
is.
E
A
F
This
one's
a
personal,
what
didn't
go
well,
I
accidentally
closed
the
retro
issue
before
the
milestone
ended.
So
we
didn't
get
the
nice
gitlab
bot,
reminder
and
update
of
what
was
finished
in
the
milestone
when
when
it
ended
some,
so
maybe
that
prevented
some
some
retrospective
participation
and
then
I
have
the
next
item
too.
The
yeah
single
command
command
promotion
release
was
was
potentially
delayed
by
an
issue
that
we
uncovered
during
testing.
F
C
A
B
Since
we
all
know
the
sense
of
urgency
and
there's
really
there's
fewer
competing
projects
on
those
teams,
whereas
if
we
found
it
out
just
using
roulette,
there's
going
to
be
some
competing
priorities,
so
we're
keeping
we're
following
that
and
then
subsequently,
we've
asked
for
more
help
through
the
borrow
mechanism
so
and
then
for
number
two.
We
can
improve
the
database
group
as
actual
participation
in
retros.
B
It's
kind
of
a
tongue-in-cheek
comment,
but
this
is
the
second
milestone
in
a
row
where
we've
got
no
feedback
on
the
database
retros
and
it's
not
that
they
don't
have
feedback.
It's
just
the
process,
isn't
really
engaging
for
them
so
alex
you
can
verbalize
your
feedback
below
we
talked
about
this
morning.
G
Yeah
we
had
a,
we
had
a
little
a
sort
of
small
synchronous
retro
at
the
end
of
our
team
meeting
this
morning
and
talked
a
lot
about
pretty
much
exclusively
on
the
retro
process.
So
we're
working
on
a
few
ideas
about
how
we
can
make
the
process
more
meaningful
next
time
and
engage
people
a
little
bit
more
and
make
the
feedback
a
little
bit
more
actionable.
G
A
F
A
F
A
F
Meta
improvement
item
we've
also
had
pretty
low
part
retro
participation
over
the
last
couple
months-
and
I
think
part
of
that
is,
is
maybe
just
that
our
our
team
composition
has
been
pretty
consistent
for
a
while,
and
the
team
is
pretty
comfortable,
I
think,
has
has
gotten
pretty
comfortable
in
in
the
processes
and
and
just
kind
of
the
work
style.
That
said,
I
think
there
there's
certainly
still
still
some
things
always
some
things
to
uncover
and
improve
on.
F
A
G
I
just
want
to
say
I
think
one
other
contributing
factor
that
we
identified
was
timeliness
too,
so
like
making
sure
that
checking
in
at
the
right
times,
but
also
understanding
when
the
milestone
ended
and
like
what
period
of
time
that
we're
reflecting
on,
because
so,
for
example,
today
we
came
up
with
a
couple
of
things
that
we
wanted
to
talk
about,
but
but
it
was
like.
Oh
no
wait.
This
is
the
14-4
retro.
We
can
talk
about
those
things
in
four
weeks
and
it's
like
oh,
but
wait.
G
B
I
think
the
thing
we
talked
about
in
database
group
and
nick
kind
of
mentioned-
it
too
is
is
a
way
to
increase
engagement,
is
make
it
your
own
right.
You
can
override
those
templates
and
we're
going
to
do
that
for
the
database
group,
so
that
it
asks
questions
in
possibly
a
different
way
and
actually
incorporates
the
discardo
functionality
within
git
lab,
so
that
we
have
threaded
discussions.
B
E
I'm
I'm
curious,
so
do
you
think
that-
and
this
has
got
an
open
question
to
both
craig
alex
and
nick,
but
do
you
think
that
these,
like
the
feedback,
is
happening
elsewhere
and
just
not
in
the
retro
issues
like?
Are
you
hearing
it
in
the
team
meetings
in
and
in
one
on
ones,
but
it's
not
making
it
into
the
retro
issue.
B
Yes,
I
think
so
historically
with
the
database
group,
we've
had
a
couple
different
sessions
where
we're
like
all
right.
Let's
talk
about
what
works
and
what
doesn't,
and
we
kind
of
we've
done
some
overhauls
at
one
point
in
time
we
actually
started
doing
synchronous
retros
because
they
all
said
yeah
async
doesn't
feel
good
for
us
and
alex
has
got
something
scheduled
to
review
our
processes
yet
again
and
we
do
iterations
on
minor
changes
here
and
there
all
the
time.
B
E
I
wonder
wonder
if
an
another
thing
is
just
to
have
like
a
link
to
the
async
retro
always
available
in
those
meetings:
agendas
where
those
things
are
already
happening,
because
at
least
for
myself,
sometimes
sometimes
it's
just.
You
know
the
level
of
effort
to
find
to
refine
the
documents
in
the
moment.
C
F
I
think
that's
a
great
point
and-
and
I've
experienced
that
somewhat
too,
like
you
get
some
of
that
feedback
in
the
one-on-one
and
maybe
yeah,
and
maybe
it's
even
if
the
team
member's
not
commenting
directly
in
the
retro
issue,
you
could
say
hey.
That
was
a
really
great
idea.
You
just
brought
up
there.
Can
I
just
write
this
in
the
issue
and
attach
your
name
to
it
or
even
not.
If
you
don't
want
to
have
your
name
associated
with
it,
but
at
least
it's
you
gathered
that
feedback
either
way.
A
E
But
what
a
lot
of
these
issues
have
been
kind
of
blocked
on
in
their
in
their
proposal
phase
is
that
we
are
are
missing
a
lot
of
documentation
of
our
existing
tools
in
terms
of
their
technical
requirements
and
the
knowledge
of
those
what
those
requirements
were
or
what
they
were
over
time,
as
some
of
our
tools
have
been
there
in
our
pipelines.
For
quite
some
time
has
you
know
kind
of
spread
among
many
people
or
sometimes
lost,
and
we
need
to
do
a
better
job
of
documenting
technical
requirements
and
decisions.
E
So
you
know
it's
something
we're
doing
better
now,
but
we
need
to
definitely
go
back
and
you
know
start
doing
it
for
pre-existing
tooling
that
we
have,
in
addition
to
making
sure
we're
doing
a
really
good
job
of
it
for
anything
new
we
we
had,
but
I
think
the
big.
The
big
thing
that
we
need
to
improve
on
is
getting
it
in
there
for
previous
previous
ones.
A
Yeah,
I
have
a
question:
are
this?
You
know
the
document,
the
technical
requirements,
what
these
decisions
where
they
captured
us
somewhere
lagging
issues.
For
mrs,
my
understanding
this
this
this
bullet
is
about
the
documentation,
so
that's
a
handbook
or
our
product
documentation.
But
I
wonder
if
those
things
were
captured
actually
in
issues
and
mrs.
E
A
C
B
Some
people
really
like
discardo,
some,
don't
we're
going
to
experiment
with
it
on
our
upcoming
retros,
we're
going
to
hijack
the
template
and
make
it
our
own
and
include
that
label.
So
it
always
happens
and
start
summarizing
our
thread.
So
maybe
we
can
manually
alter
our
next
retro
and
maybe
we
can
share
the
results.
Then.
A
C
Yeah,
one
improvement
that
we
need
to
make
is
about
capacity
planning
in
the
release.
We
first
report
all
the
memory
members
on
the
redis
related
work,
and
but
in
the
middle
we
found
it
was
not
very
efficient
to
put
the
whole
team
on,
because
we
had.
We
had
some
blocker
issues
that
some
team
members
worked
on
or
was
working
on
it
for
other
team
members
oblong.
C
A
Yeah,
that's
a
good
point
and
josh
and
dylan,
maybe
not
dylan,
but
josh.
Maybe
here
is
something
we
may
retro
with
other
the
infrastructure
group,
because
initially
the
greatest
that
if
we
recall
the
requirements
for
the
setting
up
the
teams,
it
required
a
full
backhand
team.
But
but
after
this
round
of
ex
you
know
the
work,
we
discovered
that
we
throwing
we
threw
in
the
whole
memory
team
in
israelis
work,
but
the
team
feels
like
it's
over
budgeted.
A
D
D
C
I
think
the
the
also
good
part
of
this
for
us
first,
we
we
kind
of
have
an
idea
what
what
the
future
work
could
be
and
what
what
exactly?
How
much
capacity
we
want
to
land
on
is
the
other.
Is
we
have
a
team
in
a
development
department
that
have
certain
knowledge,
a
lot
of
about
varieties?
If
there's
something
come
up,
I
think
we
can
represent
the
development
department
to
speak
for
it
or
to
work
on
it
from
our
side.
D
Yeah,
so
I
think
we
should
agree,
let's
figure
out
what
the
right
best
method
is
a
working
group
or
a
full
team
with
a
category
attached
to
it,
like,
let's
figure
out
the
right
way
to
handle
right
as
going
forward,
is,
and
then
we
can
make
sure
we
right
size,
our
investment
as
well,
based
on
what
we
think
the
need
is.
I
would
love
to
also
learn
more
about
what
we
think
the.
D
How
much
work
there
is
to
get
this
back
to
be
scalable,
so
I
think
in
some
cases
we're
looking
at
some
improvements
and
it
was
not
significant,
so
I'd
love
to
learn
more
about
kind
of
where
we're
at
sort
of
a
state
of
redis.
If
you
will
similar
to
what
the
database
group
is
doing
this
through
the
database.