►
From YouTube: 2022-02-03 Enablement monthly retrospectives
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).
D
Yeah
yeah.
We
are
aware
of
christmas
on
a
beach
with
sand
and
and
barbecues,
which
is
really
weird,
but.
B
Okay,
we
are
one
minute
pass
to
the
the
hour,
so
let's
get
started.
Welcome.
Everyone
today
is
2022
february
3rd.
This
is
the
enablement
sub
department,
the
retrospective
for
the
release
of
14
7..
Okay.
So,
let's
get
started
from
the
praises
for
our
team
members
steven.
You
want
to
get
started.
E
Yeah
sure
thing
a
little
bit
of
context
on
this
one
I'd
say
it's
a
little
sparse
in
the
comments,
but
you
know
over
the
holidays.
We
were,
I
won't
say,
hit
hard,
but
we
were
impacted
by
folks
being
out
and
it
got
us
in
a
situation
where
we
just
had
more
deliverables
planned
than
we
would.
We
were
going
to
be
able
to
complete
and
it's
it's
taken
us
a
little
bit
of
time
to
get
back
on
track,
but
we're
in
a
more
sustainable
number
of
deliverables
working
with
both
product
and
the
team.
E
A
Yep,
okay,
so,
during
this
milestone,
camille
created
a
script
to
automate
the
creation
of
merge,
requests
for
the
removal
of
foreign
keys
and
creation
of
loose
foreign
keys,
and
this
greatly
accelerated
our
timeline
and,
while
also
reducing
the
ability
to
introduce
human
error.
I
think
by
our
measurement.
It
got
us
ahead
by
a
couple
weeks
for
by
camille
creating
the
script.
So
thank
you,
camille
that
was
huge
and
on
to
cz.
F
Thank
you
craig.
So
for
me,
I'd
like
to
thank
nick
for
organizing
awesome,
actually
two
awesome
sessions
for
the
prioritization
activities
using
a
mural,
which
is
a
very
creative
and
effective
way
to
organize
such
a
activities
and
also
for
the
memory
team.
There
are
kudos
among
the
team
members
and
for
the
projects
like
creating
dedicated
radius
instance
for
session
keys,
and
also
for
consolidating
profiling
tools
and
also
nikola
wanted
to
thanks,
alexi
eagle,
sean
and
the
whole
scalability
team
for
the
help
around
the
radius
instance.
Work.
F
Okay
and
mathias
has
kudos
to
camel
for
help
optimizing
the
new
golan
implementation
of
matrix
exporter,
which
is
still
in
experiment
stage.
It's
not
productive
yet,
but
camille
helped
do
a
lot
of
optimizations
and
also
but
yes,
they're
close
to
alexia
and
roy
for
the
profiling.
Tooling
work.
D
Oh
I've
been
enjoying
the
shared
sharding
group
and
database
group
team
building
activities.
It
was
fun
that
was
a
great
idea
to
get
to
know
each
other.
So
thanks
to
alex
for
sending
it
out.
G
Cool,
I
have
a
couple
for
geo
yeah.
Thank
you,
yeah,
thanks
ian
and
douglas
for
helping
unblock
a
large
self-managed
customers,
migration
to
their
new
10k
environment
and
then
just
in
general
for
the
team.
G
They
did
a
great
job,
breaking
down
work
and
keeping
cycle
times
efficient
this
last
month
and
as
a
nice
benefit
of
that,
we
achieved
our
second
highest
team.
Mr
rate,
over
the
the
last
two
years.
C
Nice,
I
guess
I'm
just
saying
thanks
to
matt
casa
for
joining
us
from
the
configure
team,
matt
is
joining
us
for
the
upcoming
milestone
and
we're
excited
about
that.
Our
other,
like
my
our
other
exciting
phrase,
was
for
juan
who
became
a
database
maintainer,
which
means
that
that
team,
I
think,
has
two
database
maintainers,
the
configure
team,
which
is
pretty
neat,
given
how
little
database
work
that
team
typically.
Does
we
love
database
maintainers
that.
B
That's
cool
so
thanks
everyone
for
the
contribution
and
for
this
this
is
a
great
release.
Actually
items
follow-up,
so
we
only
had
a
few
action
items
from
for
me:
change
the
template
of
this
this
retro,
so
that
was
done.
New
format
is
here
everybody.
Thank
you,
everybody
for
working
on
this
new
format
and
also
alternate
the
meeting
time
between
the
emea,
friendly
and
apec
friendly
time
zones.
So
that
was
done
too.
So
today
is
the
first
iteration
is
apec
time.
B
G
I
don't
think
so.
I
kind
of
added
it
on
his
behalf.
Oh
I
can.
I
can
verbalize
it,
but
it
came
up.
It's
not
a
totally
new
discussion
topic,
but
it
did
come
up
in
this
last
retrospective,
because
ian
had
added
support
for
a
couple
of
data
types
that
were
missing
from
our
backup
restore
rate
tests,
and-
and
so
the
comment
was
that
we
we
have
a
bit
of
boilerplate
code,
which
needs
to
be
added
for
each
data
type.
G
When
we
back
it
up,
it
might
be
worth
investigating
a
self-service
framework
like
framework
which
we,
which
we
have
for
for
geo,
replicables
or
or
perhaps
somehow
tying
into
the
current
geo
framework
and
and
allowing
that
to
support
backups
so
just
to
go
through
these.
G
These
points
problem
to
solve
is
that
there's
we're
kind
of
doing
the
same
thing
over
and
over
for
for
most
of
these
data
types,
at
least
the
the
the
file
blob
based
ones
that
we
had
added
in
the
this
last
release.
G
G
B
That's
a
good
suggestion.
Anyone
want
to
share
your
thoughts
or
ideas
around
this
subject,
suggestion
or
anything
to
discuss.
The
self-service
framework
is
pretty
cool
from
the
geo
team,
so
that
was
really
a
productivity
tool
for
everyone.
I
mean
for
the
development
optimization.
B
So
I'm
typing
action
items
looks
like
we
need
just
a
first
action
item
is
a
buddha
epic
for
the
euler
call
boilerplate
called.
G
Or
I'd
say,
maybe
an
epic
for
for
some
sort
of
self-service
framework
for
for
backups.
C
Someone
who
previously
was
a
user
of
the
self-service
framework
and
also
has
done
things
with
the
backup
side
of
the
keylab
application.
This
would
be
amazing,
especially
as
new
things
are
added
that
need
to
be
backed
up
like
it.
It's
really
difficult
to
add
things
into
backup
right
now,.
B
Cool
yeah-
probably
this
is
very
specific
to
jio,
and
other
teams
may
not
have
a
good
contact.
So
what
this
could
be.
B
Okay,
if
that's
that's
all
about
it,
then
move
to
alexa
your
your
your
suggestion.
C
Yeah,
so
this
actually
is
not
my
suggestion,
which
I
corrected
to
make
sure
that
I'm
giving
credit
to
andreas
who
brought
this
up,
which
is
we,
we've
been
struggling
recently
with
the
level
of
database,
not
just
maintainers
but
also
reviewers,
and
trying
to
figure
out
how
we
can
scale
the
database
review
and
maintain
our
process
with
the
organization.
C
At
this
point,
so
I
guess
the
problem
we're
trying
to
solve
is
that
there
aren't
enough
database,
reviewers
or
maintainers
and
so
we're
the
the
first
proposal
is
to
do
something
that
craig
did
a
while
ago,
thanks
craig,
which
is
look
for
groups
that
generate
a
larger
number
of
back-end
reviews
or
users
in
particular
developers
in
particular,
who
develop
more
backend
reviews
and
then
try
to.
C
Talk
them
into
becoming
reviewers
or
maintainers,
but
I
think
the
the
the
idea
is.
We
want
to
try
and
actually
get
more
of
them
right.
So
I
I
think
for
an
action
plan.
B
Yeah,
I
I
copy
the
one
issue
there
for
basic
brainstorming,
so
welcome
to
you
know:
dump
your
suggestions
there,
but
also
I
have
one
one
side
here
to
see.
B
If
that
everybody's
opinion
here,
I
wonder
if
it
makes
sense
to
set
a
goal
of
the
db
maintainer
ratio
for
like
per
stage
or
or
a
section,
because
per
group
probably
is
unrealistic
because
of
groups
are
usually
smaller,
but
the
stage
and
the
section
might
be
appropriate
the
size
of
the
you
know
a
group
of
affected
engineers,
but
looking
for
you
know,
opinions
whether
that
makes
sense.
F
Not
sure
about
I'm
not
trying
to
fight,
but
I
have
another
idea,
maybe.
F
C
C
So
that's
a
really
good
idea,
and
that's
definitely
something
we
were
talking
about
trainings
is-
is
key
for
helping
people
come
up
to
speed
on
on
how
we
want
that
done.
H
Yeah
well,
I
was
thinking
that
this
seems
like
general
generalizable
across
the
other
reviews
as
well
for
back
interviews.
H
I
certainly
remember
that
in
the
past
there
were
some
teams
that
had
much
less
ambitious
targets
for
getting
maintainers
on
their
teams
and
what
it
would
be
interesting
to
see
is
the
kind
of
overall
you
know
comparison
of
how
many
teams
are
getting,
how
many
reviews
each
teams
are
getting
and
how
many
reviews
each
team
are
giving
or
being
requested
and
database
could
just
be
a
subset
of
that
so
yeah
engineers
per
maintainer
that
that's
one
metric,
but
is
that
a
team
based
metric
that
you
link
me
to
okay.
H
Yeah,
so
what
I
it
would
be
interesting
to
see
if
you
said,
okay
by
stage
or
by
group
what
how
many
times
are
you
requesting
database
reviews
or
back-end
reviews
and
how
many
times
are
people
requesting
database
reviews
or
back-end
reviews
of
you
and
that
could
possibly
shed
some
light
on
which
teams
could
have
targets
set
for
the
next
okrs
to
expand
on
that.
H
Because
I
think
one
concern
you
might
have,
if
you
tried
to
encourage
database
reviewers
across
all
of
development,
is
some
teams
might
say?
Well,
we
have
less
database
needs,
so
it
doesn't
make
sense
for
us
to
invest
in
putting
database
reviewers
on
our
team.
But
if
we
had
data
to
say
well
you're
requesting
database
reviews
of
us
just
as
much
as
anybody
else,
so
there
should
at
least
be
somebody
in
your
team
working
towards
that
goal.
A
It's
not
working
sorry,
I
did
have
a
table
that
showed
which
groups
are
requesting
reviews
and
it
was
in
that
thread
somewhere.
So
let
me
find
it
there's,
definitely
a
top
x
right
top
teams
that
are
asking
for
a
number
of
reviews.
It's
in
the
retro.
I
think
somewhere.
I've
done
a
bunch
of
research
on
this
to
some
of
the
points
I've
heard
it
would
be
boiling
the
ocean
to
ask
every
team
to
provide
a
reviewer
or
a
maintainer
or
both
right.
A
So
we
did
do
some
targeted
research
like
okay,
these
top
five
teams.
These
are
the
top
five
teams
asking
for
the
most
database
reviews.
Let's
go
ask
them
if
they
don't
already
have
a
minimum
of
a
reviewer
and
optimally
a
reviewer
and
a
maintainer,
or
at
least
a
path
towards
that,
so
that
we
can
start
sharing
and
up
leveling
all
of
engineering,
because
even
with
the
hiring
goals
that
database
has
for
the
year,
it's
still
a
matter
of
teaching
rather
than
doing
right.
We
don't
want
to
get
in
the
mindset
of.
A
I
have
a
database
review.
Let's
just
throw
it
over
the
wall.
We
don't
need
to
learn
anything
database
will
take
care
of
it,
we'll
get
it
back
and
assume
that
it
works.
We
need
to
uplevel
the
entire
engineering
org
and
we're
just
trying
to
find
ways
to
approach
that
and
using
data
to
justify
our
our
suggestions.
So
let
me
find
that
table
where
we
figured
out
which
teams
are
asking
for
the
most
database
reviews.
B
H
Yeah,
I
think
it
could
help
justify
that
even
further,
if
we
had
per
stage
numbers
on
how
much
each
stage
is
requesting
database
reviews,
because
you
might
otherwise
still
get
the
feedback
that
some
stages
are
unique
and
don't
need
database
stuff
as
much.
If
we
have
data
to
suggest
they
do
need
it,
then
they
that's.
That
team
doesn't
have
an
excuse
to
not
be
investing
some
of
their
time
into
working.
A
A
Exactly
yeah
for
sure,
so
the
the
idea
is
to
target
these
teams
with
the
highest
number
of
requests
to
see
like
do.
They
have
at
least
a
reviewer,
and
if
not
pick
someone
for
tribute
right
and
then
we
can
pair
with
them
to
make
sure
they
are
comfortable
and
they
get
up
speed
and
they
can
be
more
efficient
internally
and
then
start.
A
You
know
encouraging
them
to
go
down
the
maintainer
path,
but
these
some
of
these
states
are
fairly
ephemeral
like
I
expect
sharding
to
go
to
near
zero
in
a
couple
months
right
and
maybe
they
don't
need
as
much
review
support
but
yeah
data
driven
approach,
not
trying
to
get
every
single
group
to
provide
a
reviewer
or
even
a
maintainer,
because
that's
there's
the
timing
problem
and
they
use
it
or
lose
a
problem.
So
and
we've
tried
the
general
broadcast
before
of
hey.
A
C
A
specific
in
that
vein,
a
specific
call
out,
thanks
to
the
configure
the
operations
configure
team
for
their
two
database,
maintainers
that
they
have,
even
though
they
don't
appear
on
this
list
of
groups
that
have
lots
of
database
reviews.
So
thanks
for
them.
F
B
So
yeah
this
table
is
good.
I
I
will
make
a
pivot
table
from
this
to
get
a
better
view,
but
I
think
we
can
start
from
this
table
and
we'll
get
some
idea
around.
Whether
stages
makes
sense
to
set
a
goal
for
maintainers
and
based
on
this
producer
producer
consumer
model.
G
Yeah,
I
had
a
question.
I
think
craig
kind
of
answered
it,
but
I
just
wanted
to
understand
like
if
they're
you
know
what
is
the
general
recruitment
strategy
for
database
reviewers
and
maintainers,
and
it
sounds
like
there
are.
Maybe
some
regular
calls,
but
that
was
kind
of
my
my
thought
is
yeah.
Is
there
like
a
general
visibility
issue
that
that
working
on
might
help
or
yeah?
Are
we
at
this
place
of
yeah
needing
to
to
target
specific
teams?
D
G
Where
we
are,
but
I
was
just
curious,
if
there's
any
anything
else,
that
we're
kind
of
doing
regularly
to
make
to
make
those
calls
visible.
A
There's
been
two
previous
okrs,
the
first
one
was
kind
of
a
a
scream
for
help
for
anybody,
because
we
had
andreas
as
the
only
maintainer
at
the
time,
and
I
I
don't.
I
think
we
had
zero
reviewers
and
then
there
was
a
second
round
where
the
reviewers
got
bound
back
down
to
zero
because
we
couldn't
move
them
all
the
maintainers,
so
another
request
for
help
and
since
then
I've
it's
been
more
of
a
pointed.
Like
hey,
I
see
your
team's
asking
for
a
lot
of
database
reviews.
A
Can
you
provide
a
reviewer
to
help
streamline
the
process?
So
again,
this
is
just
kind
of
a
maturation
of
previous
processes
and
noting
that
as
the
entire
engineering
org
grows,
so
do
the
needs
of
the
database
right
and
database
review
database
efficiency.
So
it's
knowledge
that
we
need
to
share
across
all
of
engineering
and
not
have
it
just
be
like
okay,
I
wrote
a
query
database
to
make
it
fast
for
us
and
then
we'll
ship
it,
and
can
you
do
it
now,
because
we
have
a
milestone
goal
that
we're
trying
to
meet.
So
again.
B
B
B
So
I
think
we
have
a
good
data
here.
Does
that
make
sense
that
we
propose
something
you
know
yeah
alex?
Do
you
want
to
take
an
action
item
from
here?
Like
summarize,
the
data
we
have
then
make
a
proposal
for
at
least
probably
per
section
or
even
better
per
stage-
just
set
a
goal.
B
So
I'm
happy
to
collaborate
with
you
partner
with
you
to
drive
something
development,
wise.
C
F
C
With
this
data
and
suggest,
and
and
ask
them
for
suggestions
of
people
or.
B
Section
of
stage
yeah
does
that
make
sense?
That's
just
that.
You
know
we
consolidate
the
data
of
the
bb
maintainers
first
stage
and
the
section
and
then
compare
that
to
the
the
imr
dvmr
review.
Requests
to
those
stages
or
sections
then
initiate
a
proposal
to
work,
a
development
level
to
set
a
goal
kind
of
a
racial
goal
for
for
either
state
or
perception.
B
Okay,
we're
two
minutes
over
a
good
discussion,
so
actually.
E
B
Okay,
so
do
we
agree
this?
This
suggested
action
item
is
good
to
wrap
up
this
discussion.
B
Okay,
move
on
to
yeah
stephen.
E
It
was
actually
before
the
holidays
and
I
neglected
to
to
mention
it,
but
we
spent
a
good,
a
good
few
minutes
talking
about
the
importance
of
maintainers
and
all
the
good
things
that
happened
when
we
had
more
maintainers,
and
so
I
did
want
to
to
give
mitch
a
call
out,
particularly
in
the
operator
project,
there's
a
there's
a
lot
of
moving
parts,
a
lot
of
context
that
has
to
be
gained
and
he's
the
first
operator
beyond
sorry,
first
maintainer
of
the
operator
project
beyond
json.
So
that's
a
a
pretty
pretty
strong
accomplishment.
H
B
Thank
you.
Thank
you,
god,
thanks
everybody.
That's
that's
a
significant
step
forward
for
the
team
and
for
yourself
too.
D
B
Okay
is
that
all
for
for
the
retro
today.