►
From YouTube: 2020 06 25 Database Iteration Retro
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
Right
did
everybody
have
a
chance
I
feel
like
that,
a
chance
to
contribute
to
the
iteration
retro
issue
that
we
created
saw
some
feedback
from
everybody.
There's
no
I,
guess
at
the
Jindo
or
schedule
for
this,
so
we
can
kind
of
freestyle
it.
If
there's
does
anybody
haven't
part
of
their
issue
that
they
want
to
talk
about
and
discuss?
We
don't
need
to
read
through
all
the
feedback.
Anybody
want
to
jump
in
and
share
their
thoughts
and
I'll
take
notes
as
we
go
through
it.
C
C
A
Just
talking
about
the
iteration
issue
and
don't
have
like
I
said
again
that
what
we
need
to
talk
about,
we
don't
need
to
read
through
every
one,
since
we
people
have
had
time
to
read
it
asynchronously.
It's
anybody
have
any
thoughts
or
common
themes
that
they
saw
new
thing
they
want
to
discuss
about
their
M,
ours
or
somebody
else's
on
Mars
I.
C
Think
that
I
would
start
I
think
that
a
lot
of
times
this
issues
not
breaking
game
or
starts
by
follow-up
comments
and
realizing
after
you
started
up
working
on
an
issue
that
that
you
have
to
add
something
more,
and
you
know
sometimes
this
one
or
think
can
be
twice
as
large
as
the
rest
of
them
are,
and
so
so
yeah
splitting
image
in
a
mark
beforehand.
So.
D
A
C
Think
that
that's
the
point
where
a
marsh
must
be
speed
and
that's
a
much
more
difficult
point,
and
sometimes
it
also
depends
on
wanting
to
release
in
the
same
release.
I
think
so.
You
know
anything
that
you
say
that
if
I
split
the
EMR,
maybe
I
wouldn't
make
it
both
the
marshal
the
same
release
but
I.
Think
that
you
should.
We
should
split
the
mars.
We
should
I
keep
the
nv0
always
through
I,
don't
know
if
everyone
on
the
reason
I.
B
Agree,
I'm
I
think
I
have
this
quite
often
that
getting
this
you're
getting
feedback
like
pretty
much
pretty
late
in
the
face
here,
so
you're
tidied
everything
up
and
last
one
coming
in
point
something
out
of
them.
You
realize
well,
this
takes
quite
long
where
it's
a
significant
change
to
be
a
bar,
so
asking
at
that
stage
asking
yourself
whether
or
not
this
is
actually
needed
for
the
mr
attend
or,
if
you
maybe
just
merge
it
without
that
and
great
another.
Mr
I
think
that's
a
great
thing
to
do.
B
I
sometimes
end
up
with
having
to
juggle
multiple,
mrs
because
of
Adam,
they
are
dependent
on
each
other
so
that,
but
so
far
that
has
been
working
out.
The
the
Mr
dependency
features
quite
nice,
where
you
can
actually
mark
NMR
as
a
dependency
phenomena
and
then
what
I
typically
do
is
you
start
with
one
branch
and
then
you
you
split
another,
mr
out,
then
that's
so
dependent
and
I
configure
the
mr
such
that
it's
pointing
to
that
feature
branch
instead
of
master.
B
A
B
So
basically
want
to
be
able
to
review
those
two,
mr
separately,
even
though
they
are
dependent
on
each
other
and
then
when
you
let
both
point
to
master
than
the
the
second
one
s
has
both
changed.
That's
basically,
you
don't
want
that.
You
know,
so
you
can
point
to
the
feature
branch
and
set
until
that
is
merged
and
mark
it
as
a
dependency,
so
it
doesn't
get
accidentally
merged.
D
Yeah
I
think
the
one
thing
that
kind
of
stood
out
to
me
to
and
I
was
looking
is.
This
is
something
I
talked
about
with
Andres
the
other
day,
but
a
few,
the
MMR's
I
have
you
know
in
order
to
get
to
the
point
where
I
want
to
start
implementing
the
feature,
there's
some
other.
Maybe
change
I
need
to
make
in
preparation
for
implementing
that
feature,
and
really
that
is
great
to
have
in
a
separate.
D
D
A
Off
to
edit
the
video
now
I'm
not
sure
what
happened
on
that
last
pace,
so
yeah
listen
ears,
don't
to
get
too
absorbed
in
the
change
without
thinking
about
the
iteration
acts,
best
aspect
of
it
and
then
non-trivial
improvement
suggested
during
the
review
process
should
be
addressed
and
a
follow
up
issue
if
possible
and
I
think
both
andres
and
Yanis
mentioned
that
in
the
conversation
too.
Those
are
great
comments
in
the
red
drill.
B
D
Well,
in
this
example,
it
was
it
was.
It
was
related
to
the
tests.
It
was
basically
moving
like
the
helpers
that
I
had
written
into
like
and
share
and
help
her
file,
which
then
I
had
to
go
back
and
change
of
other
tests
that
weren't
really
related
to
that
change.
So
that's
pretty
clear-cut
that
that
probably
doesn't
that
clean
up
doesn't
mean
to
happen
in
that
particular.
Mr
to
me,
anyways
I.
Think
in
general
those
kind
of
feedback
often
comes
like
you
know,
maybe
moving
things
restructuring
things
a
little
bit.
D
B
B
A
D
B
C
C
Work
on
that
and
you
have
to
introduce
it
and
bringing
the
same
reviewers
target
pasts
of
all
the
reprocessing
merits
and
then
come
back
to
this
one
and
I
don't
know
if
this
is
a
little
larger,
and
that
means
that
this
amount
of
stop
then,
because
it's
not
like
it's,
not
a
follow-up.
It's
a
frequent.
B
B
C
A
Think
another
way
I
would
answer.
Andreas
question
is
just
create
the
separate
issue
or
mr
you
know
the
work-in-progress,
mr
and
say
I'll,
follow
up
on
that
over
here
and
take
the
conversation
to
the
other
one
rather
than
you
know.
If
you
just
say,
yeah
I'll
follow
up
on
it
later.
They
probably
believe
or
trust
that
it's
gonna
happen,
maybe
so
maybe
creating
that
follow-up
issue
or
mr
would
help
just
move
that
conversation
to
the
other
one
mm-hmm.
B
And,
at
the
same
time,
I
think
you
should
be
targeting
mistakes
that
allows
you
to
merge
the
mr
without
having
to
worry
about
the
quality
without
having
to
really
go
through
the
follow
ups
immediately
right,
good
I
mean
that's
that's
kind
of
the
goal
as
well,
that
you
split
something
out
and
you
can
follow
up
immediately,
but
you
can
also
later
so.
You
shouldn't
you
shouldn't
split
something
out
that
sort
of
says.
B
A
There
was
a
question
that
came
up
in
other
iteration
retros
that
I've
seen
like
sometimes
M.
Ours
are
bundled
because
it's
just
easier
right.
There's
each
individual
item
is
so
small
that
it
would
be
a
significant
amount
of
extra
work
to
break
them
up
into
smaller
and
Mars.
Has
anybody
encountered
that
with
the
n
Mars
that
they're
working
on
and
that's
why
they
ended
up
bundling
a
couple
of
small
changes
together.
C
D
D
Yeah,
thank
you
for
I
yeah.
It's
it's
tough,
because
you
know
that
change.
I,
guess
you
know.
The
idea
of
iteration
is
that
we
want
to
do
small
changes,
but
it's
hard
to
know.
You
know
like
sometimes
when
I
see
em
ours
that
are
small,
but
they
don't
necessarily
really
deliver
anything
which
to
me
I,
guess
that
doesn't
really
seem
I.
Guess
the
MOR
small
it's
easy
to
review,
but
that's
not
necessarily
like
iterative,
because
it's
not
implementing
really
anything.
D
That's
useful
I
feel
like
iteration,
is
still
delivering
small
incremental
changes
that
are
useful,
that
you
can
see
like
it.
A
change
come
out
of
that.
So
that's
the
part
I
feel
like
that
about
iteration.
That's
tough,
because
it's
pretty
easy
to
just
arbitrarily
like
break
down
a
more
into
smaller
m,
RS
and
say
I'm,
going
to
deliver
this
code
in
pieces,
but
you're
not
delivering
functionality
and
I.
Think
even
like
refactoring,
even
saying
like.
Oh,
that
can
be
a
separate
change
and
that's
something
like
that.
I
know
that
I
could
do
that.
D
Probably
to
make
my
m
are
smaller
and
you
know
have
more.
You
miss
those
but
there's
even
an
argument.
A
lot
of
people
would
say,
like
you,
shouldn't,
really
reflect
our
code
unless
you're
already
and
changing
the
code
like
refactoring,
should
not
be
a
separate.
Mr,
it
should
be
part
of
the
change
that
you're
making
so
I
feel
like
that.
The
idea
of
iteration
is
a
little
at
odds
with
with
some
of
those
other
concepts,
so
yeah.
No,
no!
D
It's
it's
tough
for
me
to
know
like
like
reviewing
these
I
can
say:
oh
I
can
see
where
I
could
have
broken
these
down
more
but
I'm,
not
necessarily
sure
that
it
would
have
made
like.
Maybe
from
our
perspective
of
what
we
call
iteration,
it
would
have
made
more
sense,
but
I'm
not
sure
it
would
have
made
more
sense
from,
like
my
perspective
of
writing
code
to
do
that.
B
B
You
could
still
have
your
picture
change
in
one,
mr
and
then
immediately
follow
up
with
with
the
refactoring
in
a
separate
one
and
sometimes
I
find
that
clearer
because
they
as
an
example
I,
don't
I,
don't
know
you.
Basically
you
have
a
feature
change
that
adds
that
repeats
something
you
already
have
and
it
repeats
that
twice
or
three
times
and
so
and
then
well
you
which
you
need.
You
want
to
dry
it
up
later
right.
B
So,
instead
of
repeating
yourself,
you
extract
that
and
you
remove
the
repetition,
that's
the
refactoring.
But
then,
if
you
put
everything
into
one
change,
it
looks
like
you
were
changing
the
code
that
was
already
there
were,
and
you're
and
you're
adding
the
the
second
third.
Like
all
of
that,
you
know
you
follow
what
I'm
constantly
trying
to
explain,
but
instead,
if
you
were,
if
you
were
adding
like
if
you
were
just
adding
the
repetitions
like
I'm
doing
this
second
time
a
third
time,
then
you
discuss
the
future
change.
B
A
B
And
on
the
other
point,
I
think
from
delivering
functionality,
I
think
a
prime
example
for
splitting
and
Mars
without
really
delivering
functionality
is
sometimes
we
do
that
quite
often
extracting
the
database
migration
into
into
its
own
NMR.
So
you
have
a
feature.
You
have
second
code.
You
have
won
a
mark
for
that
and
then,
before
you
start
working
on
that,
you
basically
have
an
amar
with
the
database.
Migration
and
I
feel
that
sometimes
a
bit
unfortunate
because
while
you
work
on
the
backend
code,
you
might
discover
things
that
sort
of
inform
your
database
schema.
B
D
I've
done
that
I've
done
that
in
my
own
changes
it's
because
I
have
seen
other
people
do
that
and
I
think
like.
Oh,
this
is
an
easy
way
to
kind
of
break
up
the
hem
on,
but
does
it
actually
make
sense
to
do
that?
Not
necessarily?
No
that's
the
thing.
I
think,
as
you
see,
patterns
of
how
kind
of
things
are
broken
down
and
you're
like
oh
this
yeah,
okay,
I
can
do
this,
but
then
you're
just
sort
of
cargo
coding.
What
everyone
else
is
doing,
you're
not
really
thinking.
D
You
know
that
sort
stuff,
I,
think,
because
it
is
difficult
topic
to
figure
out
how
to
break
things
down
in
a
way
that
makes
sense,
and
sometimes
change
is
like
just
naturally
sort
of
become
big,
because
if
there
isn't
a
clear
boundary
to
break
it
down,
but
then
that's
seems
like
sort
of
frowned
upon
so
then
you're
sort
of
stuck
up
like
well.
How
can
I
create
an
arbitrary
boundary
around
something
I'm,
so
I
can
have
a
more
immersive
kind
of
thing.
Oh.
C
D
C
To
revert
if
we
revert
the
data
migration,
we
don't
want
the
the
trigger
the
constraint
was
paid
for
to
be
there.
I
think
we
would
revert
and
reintroduce
everything,
because
the
problem
may
be
in
the
data
migration
or
a
problem
may
eat
in
anywhere.
We
made
the
n
decide.
No
I'll
do
the
background,
so
I
cannot
see
most
of
the
day.
Migrations
I
think
that
you
cannot
speed
them.
I.
B
Caught
that
sometimes
we
were
doing
that
because
of
the
review
process,
because
you
know
there
is
a
database
review
and
you
want
to
have
the
migration
for
that.
Then
there's
a
separate
back,
end
review
and
so
I
I
hurt
sometimes
motivation
for
splitting
the
database
migrations
actually
that
process
for
you.
You
sent
the
database
migration
first
and
you
get
that
done,
and
then
you
don't
have
to
worry
about
that
anymore,
anything
to
the
back
of
the
backpack
and
stuff,
but
the
more
I
think
about
that.
C
This
is
not
always
working
because
not
on
migrations
are
post
migrations.
Maybe
you
have
to
have
the
code
there,
so
it's
not
like.
Maybe
if
you'd
reduce
the
migration,
so
it's
not
always
just
that
the
new
attribute.
Sometimes
you
have
to
have
the
code
in
the
migration
where
I'm
alright,
because
having
the
migration
without
the
code.
Why
do
you
not-
or
maybe
it
may
even
break
things?
You
need
the
code
there
to
be
sure
that
it
will
be
deployed
in
the
same
release.
B
I
was
just
actually
working
on
an
example
for
that
product
analytics
where
we
said
well.
The
original,
mr
grew
too
big
and
now
I
got
split
in
two
well.
This
is
the
data
base
side,
and
this
is
the
the
backend
side
and
then
yeah.
Then
you
end
up
having
to
refer
to
the
other
mr
saying
like
well,
this
is
the
courier
we're
going
to
make
and
that's
why
we
need
to
mix
here,
maybe
maybe
that's
something
we
should
discourage
at
some
times.
/.
C
D
C
C
A
B
C
A
D
My
thing
that
kind
of
ties
into
this
conversation
too,
because
that's
like
the
same
as
saying
like
well,
we
have
one,
mr
for
the
database,
one
ml
for
the
back
in
one,
mr
for
the
front-end,
like
a
change
should
be
like
a
vertical
slice
of
the
app
to
me.
Not
I.
Can
you
write
them
back
and
when
you
don't
know
what
the
front-end?
How
can
you
write
the
database
from
you?
C
Also
that
the
database
review
contains
the
queries,
so
you
don't
not
have
so,
for
example,
for
finder
Amar's,
where
you
have
the
fighting.
You
could
say
that
that
we
introduced
something
and
then
have
to
find
the
road,
but
you
need
them
there,
because
the
change
may
be
in
the
index,
but
the
things
may
also
be
in
the
query
or
may
be
in
the
approach.
Maybe
if
we
decide
that
you
cannot
do
it
like
that,
let's
say
we
had
introduced.
C
C
B
A
D
A
Know
what
Sid
said
in
there
was
exposing
the
API
start
means
that
were
locked
into
that
design.
Api
should
be
stable
and
api's
are
hard
to
change.
So
yeah
I
do
remember
that
conversation,
I,
think
I'm,
not
sure
I
agree
with
that
right,
api's
can
change.
If,
if
you
document
them
like
saying
like
this
is
a
not
a
major
release,
we
are
working
on
this.
It's
a-workin
probable
it
to
customers
or
you
can
feed
you're
flying
it.
A
So
the
customers
can
consume
that,
while
you're
iterating
on
it,
you
know,
however,
you
need
to
protect
it
so
I'm,
not
necessarily
in
agreement
with
what
was
that
during
iteration
office
hours
and
I
think
you
know,
Sid
has
said
in
the
past.
Strong
beliefs
held
loosely.
So
if
you
know
couldn't
potentially
push
back
on
that
in
the
iteration
and
office
hours,
I
didn't
agree
with
their
comments
about
I,
can't
remember
who
made
the
comment,
but
something
about
they
did
too
much
planning
in
advance.
A
It
was
one
team
that
said
our
first
iteration
was
this
plan
and
they
had
kind
of
a
plan
of
the
next
several
iterations.
They
were
working
on
and
I.
Think
it's
okay
to
kind
of
do
that,
milestone,
planning
and
how
you
think
things
are
going
because
you
can
start
considering
dependencies
and
what
you
know
just
talking
out
loud
can
generate
more
work.
Like
oh
I,
didn't
think
about
that.
Even
this
conversation
it
was
generated
idea,
so
I
kind
of
disagreed
with
what
Mara
and
Sid
said
about
not
spending
so
much
time.
A
D
But
you
don't
understand
enough
of
the
details
of
like
what
it's
trying
to
do.
Then
you
sort
of
get
locked
into
this
design
start
writing
the
code
underneath,
and
you
realize
all
these
things
you
didn't
think
about,
and
now
your
API
is
working.
You
have
to
make
it
immediately
do
like
a
v2,
because
you
did
it
work
early
yeah.
C
C
C
If
we
introduce,
for
example,
something
that
two
million
users
will
use,
then
it's
a
problem
so,
if
you're
tied
to
that,
but
if
the
idea
is
that
what
are
the
core
API
mechanic?
What's
the
interface.
So
what
does
this
feature
is
going
to
provide
yeah
ABI
first
word.
Interface
first
gives
the
business
requirement
for
this
service
product
feature
call
it.
However,
you
want.
B
A
B
A
B
A
C
A
Yeah
simple
rule
right:
other
teams
mentioned
you
know
if
it's
if
it's
a
super,
simple
couple
of
changes
and
it's
gonna
be
significantly
more
work
to
break
it
out,
it's
okay,
to
shift
that
small
M
R
that
may
have
been
breakable,
but
it's
too
much
work
to
do
multiple
M
R,
so
that
was
something
other
teams
agreed.
That
was
okay.
A
A
C
B
B
Have
one
more
thing:
I
added
a
plugin
to
my
status
forum,
I
just
thought
that
basically
displays
the
number
of
Mars
over
the
last
30
days.
You
know
the
metric
that
we
track
and
it's
an
interesting
week
you
can
sort
of.
There
are
a
couple
of
concerns
around
trekking
that
metric
I
suppose,
but
seeing
that
it's
kind
of
interesting
and
it's
sort
of
a
gamification
of
like
well,
you
need
to
ship
another
Amar's
who
next
gets
on
something
that's
kind
of
interesting,
I'm,
not
sure
if
I
take,
if
I
keep
that.