►
From YouTube: 2021 06 14 APAC Sharding Group Sync
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
A
C
A
A
A
B
Okay
for
efficiency-
let's
just
do
it
right!
Who's
late
is
late,
we'll
we'll
take
notes.
So
I
have
a
lot
of
items.
So
I
do
a
lot
of
talking.
I
apologize.
A
B
So
my
yeah,
so
I
I
don't
know
what
this
ci
instance
variable
thing
actually
does.
Quite
frankly,.
D
D
D
This
table
is
going
to
store
variables
that
you
can
define
on
the
instance
level
and
in
this
way,
all
the
variables
declared
on
the
instance
level
are
going
to
be
injected
into
all
the
jobs
on
this
instance.
D
So
it's
like
a
predefined
variable
that
you
can
actually
define
on
your
instance,
and
it
gets
inject
into
your
build
into
your
job.
E
I
think
like
it's
not
even
like
migrating,
it's
like
creating
elsewhere
or
like
doing
that,
like
very
easy,
because,
like
I
like,
I
think
this
is
to
some
extent
like
actually
very
good
idea,
because
there's
like
so
many
or
other
stuff
that
we
have
to
fix
except
data
migration
and
the
next
step
was,
we
have
to
figure
out
migration.
So
I
don't
think.
D
D
E
Composition
like,
for
example,
like
we
are
reading
this
table
anyway,
today,
like
every
time
that
you
fetch
variables,
we
are
reading
the
table
anyway.
So
even
maybe
you
don't
have
the
data
there,
but
we
are
already
reading
this
label.
D
But
having
data
returned
after
reading
this
table,
we
might
need
to
do
something
with
this
data,
and
I
still
feel
like
having
at
least
one
variable
would
provide
more
feedback
than
not
not
having
any.
E
C
B
A
C
I
I
think
we
we
like,
I
get
the
concern
about
not
really
testing
this
or
caring
about
the
outcome,
but
we
one.
We
know
that
it's
gonna,
even
self-manage
customers
are
likely
to
have
a
very
small
number
of
these
variables
like
we
wouldn't
expect
any
supplement
customer
to
have
a
hundred
thousand
of
these.
That
just
wouldn't
be
happening,
so
any
migration
we
write
will
likely
run
safely
for
them
and
given
how
incredibly
simple
this
feature
is
like.
I
have
a
high
degree
of
confidence
that
we
can
verify
that
it's
going
to
work
correctly
and
yeah.
C
B
B
B
Cool
okay
next
item:
thank
you.
I
sat
down
on
friday
and
I
created
a
sort
of
high
level
epic
structure
and
also
a
planning
issue
for
14.1.
My
thinking
was.
We
should
treat
this
as
we
should
treat
any
other
thing
that
we
release
right
and
at
least
specify
what
we're
going
to
do.
In
the
next
month.
B
I've
created
essentially
like
a
bunch
of
epics
and
moved
a
few,
but
the
three
main
things
that
I
feel
we
need
to
focus
on
are
support
for
many
databases.
The
like
ci
table
decomposition,
even
though
I
don't
quite
know
what
that
means,
and
the
migration
tooling
that
I
think
was
referenced
earlier
on.
There's
also
observability
pieces
and
uric
highlighted
that
he
also
has
a
sort
of
very
large
cleanup
epic,
so
where,
where
I
am
right
now
is
so
first.
B
I
would
like
to
understand
if
people
are
generally
okay
with
this
structure
and
if
it
makes
sense
right,
because
it
just
needs
to
be
in
a
format
that
you
know
we
can
work
with
and
then
secondly,
I've
not
actually
added
any
specific
issues
that
we
want
to
start
with,
because
I
don't
know
what
those
issues
are
right.
So
I
would
like
to
be
in
a
position
where
we
can
say:
okay,
you
know
these
are
the
like
five
things.
We
want
to
do.
First
for
supporting
databases,
there's,
maybe
a
sub
discussion
about
load
balancing.
B
B
I've
also-
and
this
is
purely
tentative
right,
like
absolutely
subject
to
change-
it's
like
I've
sort
of
suggested
folks
who
may
focus
on
specific
sort
of
higher
level
epics
like
areas
to
work
with,
because
I
want
to
make
sure
that
we
parallelize
as
much
as
possible
with
an
emphasis
on
as
much
as
possible
right,
and
I
think
it
makes
sense
to
have
at
least
two
people
focus
on
these
areas.
So
if
somebody
goes
on
vacation,
something
is
still
happening
and
we
don't
have
bottlenecks
in
terms
of
knowledge.
A
I
have
the
next
one,
so
I
feel
like
just
strictly
for
14.1.
We
should
do
just
three
things.
For
me,
the
epic
is
pretty
hard.
A
For
me,
for
me,
the
ethics
is
a
bit
hard
to
reason
about,
because
you're
not
planning
to
do
all
100
of
each
epic
for
14.1,
so
I
feel
like
we
should
do
whatever
issues
that
get
us
get
us
to
do
these
three
things,
which
is
we
can
create
a
new
db.
We
can
migrate
the
db
and
and
we
can
use
new
new
db,
so
yeah
whatever
whatever
gets
us
to
that.
I
think.
B
B
Okay,
let
me
can
I
share
my
screen
quickly,
because
then
can
you
see
my
stream
okay?
So
this
is
the
first
one
using
tom's
criteria,
which
ones
of
those
very
many
which
also
need
more
context.
Right,
they're,
just
being
created
would
be
relevant
for
that
specific
goal.
A
A
E
B
B
A
C
B
C
C
One
thing
I
thought
that
we
might
need
to
do
is
that
we
may
need
service
discovery
to
get
this
to
production
for
ci
instance.
Variables
table.
C
Well,
I
don't
know
I
mean
this
may
be
something
we
want
to
talk
about
with
infrastructure,
but
maybe
they're
not
going
to
want
us
to
hard
code
or
find
implement
a
new
way
to
connect
to
the
database
that
isn't
handled
by
the
tooling
they
have
in
place
and
at
present
they're
talking
for
configuration,
configuring,
the
host
and
the
databases
through
service
discovery.
So.
E
That's
that's
a
tricky
question,
but
I
think,
like
my
perception
of
that
is
like
we're.
Just
gonna
probably
have
like
a
completely
separate
fleet
of
the
databases
configured,
but
it's
not
gonna
happen
like
in
this
milestone,
truly
like
it's
too
big
undertaking.
C
Yeah,
well
I
I
guess
if
our
next
objective
is
to
run
ci
instance
variables
on
gitlab.com,
I
think
we
just
want
to
implement
as
many
ship
as
many
things
as
we
can
to
get
to
that
point.
I
we
we
have
a
we
have
like
we
can.
We
can
define
things
that
we
will
need
before
that
that
we
can
ship,
but
then
there's
going
to
be
a
bundle
of
things
that
need
to
be
shipped
together
in
order
to
actually
deliver
on
it,
and
I
I
think
we
will.
C
E
But
maybe
what
is
like
feasible
for
us
is
like.
Maybe
it's
like,
we
will
be
able
to
approach,
let's
say,
staging
in
much
easier
form,
maybe
using
the
current
database,
but
on
a
logical
databases
in
the
current
database
on
staging.
C
E
E
So
the
production
I
think
needs
to
be
handled
like
on
the
github.com
needs
to
be
handled
like
step
by
step
by
provisioning
things
on
the
infrastructure
side.
So
the
team
can
actually
creep
where
the
proper
infrastructure
that
for
that,
because
I
don't
think
that
we
can
use
the
current
database
for
adding
new
logical
database.
C
If
we
start
to
say,
staging
actually
connects
to
two
different
logical
databases
and
there's
two
ci
instance:
variable
tables
in
a
migration
like
I'm
a
little
bit
concerned
about
what
a
rollout
process
will
look
like
if
we
don't
actually
plan
to
go
to
production
with
what
we
ship,
but
maybe
that's
something.
That's
can.
C
Well,
at
some
point,
we
merge
codes
such
that
we
have
two
structure:
dot,
sql
files
that
describe
a
new
schema
for
ci
instance
variables.
Once
that
code
is
merged,
it
will
make
its
way
to
production,
and
I
don't
know
how
to
wrap
that
in
a
feature
flag,
neatly
or
other
things.
So
I
feel
like
if
we
just
aim
to
get
both
of
them,
get
it
to
production
with
as
a
first
step,
we
wouldn't
have
to
solve
this
extra
problem
of
like
feature
flag.
Wrapping
schema
changes
which
we
did.
E
It's
actually,
there
is
like
the
issue
opened
by
tonk
how
to
handle
manage
schemas
and
race.
Point
6.1.
Actually
has
this
very
handy
feature
that
allows
you
to
for
different
database
connections,
define
different
schemas
effectively,
and
we
can
actually
start
with
the
separate
migration
folder
for
this
logical
database.
E
So
you
don't
really
have
the
problem
that
you're
gonna
run
ci
instance
for
everyone
in
the
neurological
database
on
github.com,
because
you
will
not
run
that
until
you
actually
have
the
database
yml.
Okay,
that
makes
sense,
and
the
second
thing
is
like
in
the
let's
say,
our
presumption
application
record.
You
define
connects
to
and
you
can
configure
many
connections
and
price.
Basically,
gonna
fall
back
to
the
default
one.
I
think
this
is
this:
the
one
the
name
legacy,
connection
handler
connection
harmonic,
or
something
like
that.
E
If
this
connection
name
is
not
configured
in
the
database
yml,
so
this
is
how
we
can
actually
model
also
with
a
feature
flag,
because
you
can
make
this
decision
about
best
connection
to
use
dynamically
based
on
the
features
like
what
connection
like
what
database
to
use.
E
B
Thank
you
for
that
explanation.
So,
with
that
in
mind,
is
it
fair
that
I
can
close
the
low
balancing
now
we
can
say
like
we
don't
need
to
address
that
in
14.1
the
items
in
the
generalized
load,
balancing
one?
E
B
Like
collapse,
like
there's
nothing
in
here
in
these
issues
that
we
need
to
schedule
for
14.1.
E
B
B
A
E
I'm
kind
of
thinking
this
is
kind
of
like
a
stretch
goal,
but
we're
not
gonna
run
unless
we
have
it
possible
to
configure.
E
A
A
B
This
one
here
is
being
worked
on
by
utong,
so
I
just
put
it
at
the
top.
The
connection
tool,
sizing.
E
It's
gonna
be
required
for
staging
because
of
the
trading
model,
but
I
think,
like
we
can
probably
live
with
this
limitation.
The
single
table
and
probably
do
it
like
in
the
14.2,
but
it's
gonna,
be
quickly
become
a
problem.
E
One
here
as
well,
because
it's
about
like
making
our
customers
to
use
like
minor
databases
and
probably
joining
them
and
probably
needs
to
be
handled
by
the
distribution
team
in
the
end.
A
A
C
C
Yes,
but
what
was
the
question?
Can
we
get
to
staging
without
those
two
things
as
in?
Can
we
move
those
out
of
14.1
and
they
even.
E
C
E
We
only
need
to
be
able
to
configure
so,
like
omnibus
cng
needs
to
create
database
yml.
We.
E
To
them
to
manage
databases,
yet,
which
is,
I
I
I
think,
like
the
different
objective,
which
is
like
one
described
by
that.
E
Databases,
yes,
we
we
have
number
of
like
things
like
recovery,
flux
and
other
stuff.
I
don't
know
yet
how
to
handle
that.
I
think,
like
we're,
gonna
know
more
as
soon
as
we
actually
enable
more
databases,
but
I
have
no
idea
yet.
B
Maybe
we
can
leave
it
back
up
and
resort
tasks
sounds
like
something
for
later.
Yeah
later
define
behavior
for
two
pc
transaction
pattern.
E
B
Essentially
anything
up
to
up
to
here
right
did
we
talk
about
the
migration
helpers.
E
So
yes,
so
so
fabian,
I
think,
like
the
cng
provisions
and
nominee
must
provisions.
I
think
it's
not
what
we
need
now.
So
we
just
okay
that's
outside,
but
we
need
like
can
be
configured
right.
B
Let
me
quickly
do
we
need
the
might
the
discover
and
handle
failures?
We
were
unsure
right.
C
E
I
think
I
think
you
are
right,
like
the
like.
The
problem
with
migration
helpers
is
like
that
database
migrate.
When
you
configure
additional
database,
it's
going
to
be
executed
exactly
in
this
context,
the
proper
context.
The
problem
is
really
like
with
the
background
migration,
because
background
migration
doesn't
provide
a
it
doesn't
have
the
context
today.
B
Okay,
that's
fine,
but
other
than
these
two,
which
I
messed
up.
I
think
essentially,
these
five
here
at
the
top
are
what
we
need
like
gdk
gck
support,
many
databases
can
be
configured
and
multiple
schemas
cng
configuration
provisioning
is
wrong.
This
is
wrong.
This
can
be
done
later
and
the
rest
is
for
for
later.
Does
that
sound
right.
B
Okay,
so
this
is
this
one
we're
a
little
bit
late,
I'm
sorry,
but
it's
I
think
it's
important
the
ci
table
decomposition,
I'm
honestly
a
little
bit
confused
as
to
what
we
need
to
do
here
for
the
goal
that
we
outlined.
If
anything
we've
identified,
the
first
ci
charting
table
I'll
just
close
that
later
is
this
one
here
is
the
verify
work
right,
so
we
we
can
ignore.
That
is
this
something
that
we
even
need
to
care
about
in
14.1.
E
I
would,
I
would
create
an
issue
clearly
citing
create
ci
ci
instance
variables
on
additional
database,
and
this
is
our
goal.
E
And
we
only
have
this
one
plant
because
identify
first
ci
table
of
the
chart
using
the
composition
I
think
like
we
there
are.
We
actually
close
that
already
right
and
the
outcome
of
that
issue
is
exactly
the
one
that
you
are
creating
right
now,
and
this
is
what
we
are
doing.
This
is
what
we
are
focusing
on.
B
We
don't
have
very
many
issues,
but
we
have
one
that
I
think
is
already.
I
think
the
idea
here
was
that
we
know
we
need
it.
We
know
it's
going
to
take
us
a
while
to
get
it
right,
so
we
should
start
now,
even
though
we're
not
going
to
ship
necessarily
anything
in
14.14.1,
but
that's
up
for
discussion.
E
A
I
have
a
comment
in
that
first
issue
with
two
ideas,
so
I
think
we
can,
if
you
have
the
necessary
permissions,
we
can
use
something
similar
but
dylan
research.
The
good
thing
here
is
that
we
can
easily
set
up
replication
on
the
whole
table,
so
we
don't
need
to
do
manual
filtering,
so
the
high
level
process
is
basically
we
need
to
create
the
database
table
on
the
other
database.
A
Server
kick
off
the
data
sync
or
application
figure
out
a
point
when
the
data
is
actually
in
sync,
do
some
sort
of
looking
to
replace
the
connection
so
the
old
model,
so
the
model
connects
the
new
database
at
some
point,
we
need
some
sort
of
force,
reconnect
or
some
sort
of
event
that
make
this
happen.
A
A
So
using
standard,
postgres
replication,
logical
application
to
keep
the
people
up
to
date.
C
C
We
just
yeah,
we
just
don't
allow
rights
and
we
500,
or
somebody
tried
to
create
an
instance
variable
during
a
period
of
time
with
which
we're
actually
just
copying
it
from
one
place
to
another
like
they're,
two
separate
rails
models,
and
you
we're
just
literally
something
is
going
to
loop
over
the
first
table
and
right
to
the
second
table.
While
that
thing
is
running,
if
anybody
tried
to
create
one,
we
just
fail
it.
C
E
And
like
okay,
I'm
gonna
comment
on
that,
but
I
I
have
like
a
few
remarks
to
consider
like
this
is
like
a
single
table
out
of
like
50,
more
tables
like,
and
I'm
kind
of
wondering
like.
E
So
is
it
mean
like
we
are
not
maybe
performing
rights
now
or
maybe
we
do
concurrent
rights
to
databases
or
we
do
something
different,
but
I
think,
like
my
my
perception
is
like
we
need
some
somehow
something
with
the
migration
that
we
can
reset
migration
and
start
everything
from
scratch,
because
we
find
that
we
need
to
do
it
at
some
point
because,
right
now
we
start
with
a
single
table.
It's
very
simple,
but
the
more
tables
we
move.
D
E
D
Also,
a
good
enough
reason
to
do
what
dylan
suggests,
because
it
might
be
quite
tricky
to
achieve
the
same
with
low
level.
Postgresql
features
like
replication
and
by
using
high
level
ruby
might
be
easier
to
model
such
behavior
yeah.
C
So
I
I
was
going
to
say
that
I
don't
think
whatever
we
implement
now
will
even
be
applicable
to
what
we
implement
for
the
next
and,
like
you,
you
said:
okay,
we're
doing
one
table
and
then
we're
going
to
start
doing
more
tables.
I
said
I
think
we
should
stop
thinking
about
that,
because
my
assumption
is
we're
going
to
do
one
table
and
then
we're
going
to
do
the
rest.
C
E
C
Yeah,
so
whatever
we
write
from
migration
now,
we
should
just
do
the
dirtiest
way.
We
can,
because
we
just
won't
reuse
it
that's
my
assumption,
and
if
we
wanted
to
do
something
at
scale,
we
won't
be
able
to
test
it
either
now
so
like
we'll
constantly
be
debating
while
reviewing
the
code.
Is
this
going
to
scale?
Is
this
not
it's
like?
Let's
not
even
worry
about
it,
nobody's
writing.
B
So
I
don't
disagree,
but
I
have
one
comment
I
think
maybe
both
things
need
to
happen
a
little
bit
in
parallel
right,
because
we
know
that
the
next
step
is
going
to
be
do
everything
right,
at
which
point
we
need
to
care
about
all
of
those
things,
and
if
we
wait
until
we
are
done
with
our
first
iteration
to
kick
that
off,
I'm
worried
that
it'll
just
take
a
long
time
right.
So
maybe
there
is
a
path
here
where.
C
Yeah,
we
met
a
point
where
we
were
trying
to
we're
trying
to
like
get
away
from
that
before.
But,
like
I
agree,
we
do
need
to
put
things
in
parallel,
but
we
need
like
this
meta
communication
technique
where
we
can
say
like
while
reviewing
code.
While
we're
writing
code.
There
is
code,
that's
going
to
get
us
to
ci
instance
variables,
and
there
are
discussions
and
issues
that
relate
to
that.
And
then
there
is
parallel
work.
E
Consistency
we
kind
of
want
to
like
do
all
of
that
without
a
downtime.
E
So,
like
I,
I
think
my
perception
like
we
should
use
whatever
like
postgres
offer
us
so
either
it's
physical
replication
or
it's
logical,
replication,
logical
replication
is
more
flexible.
E
E
That's
that's
that's
my
concern
because,
like
I
know
that
if
we
get
to
some
point
of
logical
replication,
it's
very
likely
that
we're
going
to
run
this
replication
five
times
until
we
are
fully
confident
that
all
of
data
is
properly
migrated
and
it's
consistent.
E
So
I
don't
trust
by
grant
migration
like
to
like
to
provide
consistency
on
updating
data
between
two
databases
unless
we
kind
of
get
to
the
using
database
figures.
D
I
agree
with
that,
but
I
doubt
that
postgresql
replication
is
flexible
enough
to
achieve
passage
of
our
goals.
B
Just
to
to
make
sure
we
move
move
forward
adam
what?
What
is
your
opinion
on
this
because
you've
written
down
these
these
ideas
before.
A
Yes,
so
back
to
to
dylan's
idea
to
do
the
really
simple
migration
as
the
first
step,
I
think
that's
a
good
idea
to
start
with
that,
because
it's
quite
simple
what
we
need
to
do.
We
need
to
plug
data
from
the
old
database
and
then
just
insert
it
into
the
new
one
and
then
make
some
sort
of
magic
to
switch
the
model.
A
I
don't
know
how
we
do
that
yet
to
point
to
the
new
connection,
but
implementing
these
more
complex
migration
steps
that
either
using
replication
or
using
a
trigger
solution
will
definitely
require
as
much
much
more
time
and
thinking,
and
I
don't
think
it
will
fit
into
one
milestone.
But
I
think.
B
B
So
I
think
the
decision
maybe
here
is:
we
can
either
create
another
issue
and
say
like
migrate,
ci,
instant
variables
right
and
do
it
in
a
scrappy
way
right
and
then
focus
on
sort
of
the
longer
term
how
to
do
it
right
when
we
have
to
move
all
of
our
data
right
and
maybe
break
that
down
a
little
bit
more,
but
it
also
feels
like
we
haven't
really
settled
on
the
path
right,
then,
maybe
more
discussion
needed
that
we
can
have
async.
Is
that
fair.
E
E
C
E
I
would
I
would,
I
would
focus
on
logical
application
with
the
process,
with
the
focus
on
like
ci
instance
variables,
with
the
intent
that
we
migrate
or
the
res
data,
but
I
would
not
focus
on
the
migrating
ci
instance
variables
different
way,
because
we
don't
need
to.
There
is
zero
rows.
We
can
create
new.
C
I
I
I
just
kind
of
don't
want
to
needlessly
conflate
like
we're
trying
to
do
the
simplest
thing
with
one
table
and
like
want
to
get
a
bunch
of
issues.
Now
that
say,
that's
what
we
need
to
do
to
get
that
one
table
done
and
if
we're
talking
about
replication
for
the
rest
of
the
tables,
I
think
it's
better
to
just
think
about
in
that
way
like.
C
If
that's
the
objective
of
the
engineer
working
on
this
task
to
do
to
move
five
terabytes
worth
of
data,
they
need
to
come
up
with
a
solution
that
moves
five
terabytes
worth
of
data.
We
can't
like
give
an
engineer
like
a
mixed
objective
of
something
that
would
maybe
work
for
a
bit
a
lot
of
data,
but
like
make
it
work
for
one
row
now
like
it
seems.
E
Confusing
so
I
I
think
like
we
should
right
now
start
concurrently
thinking
about
like
migration,
but
really
like
on
the
migration
that
we
need
to
run
in
the
end.
B
Okay,
so
I
my
like
my
suggestion
here
is
we
had
in
the
beginning
a
discussion
on
like,
let's
create
at
least
one
variable,
because
then
we
can
do
like
a
scrappy
way
of
migrating.
B
I
think
the
discussion
seems
to
have
turned
where
we
are
essentially
saying:
let's
not
care
about
it,
because
we
don't
have
to
let's
care
about
the
like
it's
more
efficient
to
care
about
the
longer
term
objective
here,
which
is
five
terabytes
of
data
right-
and
you
know
this
specific
work
item
here-
will
focus
on
that,
rather
than
artificially
having
to
create
code
and
worrying
about
things
that
aren't
there,
and
I
agree
that
that
is
maybe
more
straightforward.
If
people
are
happy
with
that,
I
we
can.
C
B
Good
okay
last
thing
to
discuss
is
this:
like
observability
for
multiple
databases?
I
know
that
dylan
has
one
item
working
on
this
right
now.
I
know
that
we
need
better
monitoring
and
observability,
but
I
wasn't
sure
if
that
is
something
that
we
need.
C
B
Fine,
then
I
will
actually
drop
it
because
that
may
make
it
more
focused
from
from
this
release.
Okay,
so
I
think
we're
kind
of
at
the
end
in
my
mind,
what
we're
trying
to
accomplish
in
14.1
is
we're
going
to
try
and
have
staging
connect
to
many
databases
with
ci
variables.
Migrated
doesn't
have
any
data,
so
essentially,
like
tom,
said,
it's
connection.
Switching,
that's
the
one
major
thing.
B
The
second
thing,
which
is
a
longer
term
objective,
which
will
not
ship
in
14.1,
is
to
start
figuring
out
the
migration
tooling
for
the
rest
of
the
tables,
which
is
five
terabytes
of
data
right.
So
we
probably
need
to
like
break
that
down
a
little
bit
more.
I
think
adam
has
ideas.
Janus
is
not
here.
He
probably
has
ideas,
so
imagine
a
few
items
spin
out
of
that,
but
that's
kind
of
how
I
see
it
and
I've
assigned
the
items
to
the
milestone
to
kick.
That
off
is
that
sort
of
the
the
state
of
affair.
C
Are
you
suggesting
we
work
on
the
decomposition
create
migration
tooling
in
from
now
like?
If
you
look
at
all
those
names,
as
does
this
imply
that
only
three
people
will
work
on
priority
one
and
we're
actually
going
to
work
on
that?
The
the
reason
I'm
asking
is
like
are
we
in
agreement?
We
want
to
start
working
concurrently.
While
there
are
open
issues,
start
working
on
something
we
won't
ship
in
14.1.
B
So
my
my
understanding-
and
this
may
be
wrong-
is
that
if
we
wait
work
like
wait,
wait
starting
to
work
on
the
migration
tooling
right,
just
in
terms
of
like
how
long
it
will
take
to
actually
complete
this
right,
we
wait
a
month
right
then
we
may
end
up
in
this
in
a
space
where
we
don't
have
as
much
time
as
we
want.
So
we
can
do
this
concurrently,
but
that
is
an
assumption
that
I'm
making,
because
I've
heard
that
it
is
very
complex.
B
If
that
is
not
true,
you
don't
have
to
do
that
right,
but
I
thought
that,
in
terms
of
team
capacity,
if
we
have
essentially
like
three
folks
working
on
p1
and
then
like
another,
three
folks
work
on
this
or
start
work
on
that,
that
would
be
a
good
way
of
sort
of
having
something
shippable
in
in
the
first
iteration,
while
already
starting
to
like
make
headway.
This
other
track.
That
was
my
thinking,
but
that
really
depends
on.
On
the
you
know,
the
type
of
the
work.
E
E
A
Okay,
make
sense.
E
B
E
I
I'm
still
going
to
say
like
getting
this
actually
running
on
staging
is
pretty
stretched.
I
think
it's
fully
expected
that
we
get
his
own
own
development
environment
because
on
staging
he
still
requires
necessary
involvement,
and
I
am
not
confident
that
we
have
people
to
help
out
us
with
that
at
the
end.
So
I
think
the
goal
is
still
like
to
get
this
initially
on
staging,
because
it's
like
the
first
environment
that
we
are
using.
E
B
A
quick
question
is
I've
put
down
folks
here
like
tong
and
yorick
who's,
not
here,
and
if
and
this
one
here.
I
think
we
only
need
to
do
one
thing
right,
that's
very
simple,
but
in
terms
of
like
who
wants
to
work
on
what
I
assumed
that
the
migration
tooling
would
be
interesting
for
adam,
because
that
seems
to
be
your
area
of
of
expertise
and
interest,
and
so
it
is
for
janis
who
has
other
priorities
as
well.
B
But
I
I
made
an
assumption
here,
dylan
that
this
is
something
that
you
would
be
interested
in
as
well,
but
I
may
be
completely
wrong
right.
I
just
wanted
to
make
sure
that
people
are
sort
of
comfortable
with
these
sort
of
focus
areas,
and
that
doesn't
mean
like
never
talk
to
each
other
again.
It
just
means
like
people
having
sort
of
a
primary
thing
to
think
about,
but
this
is
really
just
I
sat
down
on
friday
and
put
a
few
names
down
right,
so
I
wanted
to
validate
that.
This
is
not
completely
crazy.
C
C
B
A
I
I
think,
yeah.
I
think
this
is
fine.
I
have
a
feeling
that
yeah,
I
should
say,
it'd,
be
nice
to
kind
of
be
aware
of
what
other
things
are
doing
so
yeah
definitely
like.
We
will.
B
And
I
think
in
general
right,
what
will
happen
is
I'll
put
things
into
ready
for
development,
which
are
the
things
that
are
assigned
for
the
milestone
right
and
in
terms
of
how
to
work.
If
you
have
nothing
to
do
right
now,
because
of
review
cycles
or
whatever
it
is
right,
you
should
feel
empowered
to
just
pick
up
the
next
thing
and
start
contributing
right.
You
should
say
like
this
is
not
in
the
epics
that
I'm
supposed
to
generally
have
an
eye
on
right
and
never
look
at
other
things.
B
B
B
A
B
Look
you're
going
to
do
great,
like
I
think
I'm
actually
really
excited
about
this.
I
think
it's
going
to
be
a
really
challenging
thing
to
do,
but,
on
the
other
hand,
we
I
think
we
have
probably
one
of
the
more
challenging
phases
of
this
project
just
behind
us,
which
is
to
make
a
decision
what
we
want
to
do
so
I'm
optimistic.