►
From YouTube: Create:Code Review PM+ENG+UX Weekly Sync - 2021-01-13
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
Okay,
this
one
is
about
the
road
map
and
engaging
with
the
team
more
to
understand
what
we're
working
toward
it's
actually
been
brought
up
a
few
times,
but
more
so
recently
by
different
people
in
the
team.
In
the
beginning
I
just
pointed
them
to
the
direction
page
and
kai.
I
know
you
just
updated
the
direction
page,
but
that's
not
really
kind
of
what
they're
looking
for.
I
think
these
calls
are
super
useful.
The
monthly
call
is
super
useful.
B
Yeah,
I
think
one
of
the
things
I'll
say
is
that
you
know
direction
roadmap
probably
still
aren't
set
in
stone
or
clear.
Yet
is
probably
part
of
the
reason
why
we're
not
there's
nothing,
there's
sort
of
nothing
to
share
there
or
nothing
that
we
could
share
sort
of
reliably.
B
So
that's
really
the
first
thing
that
I
said
the
second
and
as
part
of
that,
I
think
one
of
the
things
that
I'd
like
to
do
is
pedro
and
I've
talked
about.
This
is
get
to
a
point
where
we.
B
We
should
figure
out
how
to
get
that
back
on
the
calendar.
I
don't
I
don't
know
what
to
do
in
terms
of
timing,
for
that.
Monthlies
have
been
hit
and
miss
when
I
had
done
them
in
another
group
only
because
that
group
sort
of
showed
up
to
every
weekly
meeting,
and
so
it
was
just
a
longer
version
of
it.
I
think
in
here
we
should
do
something,
maybe
more
explicit,
but
I
don't.
B
B
A
I
don't
know
about
andre's
team
what
time
zones
they're
in
but
like
5
p.m,
central
time,
it's
a
sweet
spot
for
my
team,
but
somebody
will
always
be
left
out.
So
having
maybe
two
that
day
is
not
a
bad
idea.
C
Yeah,
I
think
so
to
I
think,
we've
tried
only
one
the
blast
editions
we
did
but
I'll
be
up
to
trying
to,
because
we
I
do
have
some
people
like
in
eastern
europe,
not
really
apec,
but
could
probably
attend
that,
but
sorry
yeah
for
the
no
they'll
probably
attend
the
the
one
more
early
and
then
the
one
that
they
back
will
get
later.
It's
tricky.
C
I
don't
know
really.
If
my
team
will
be
affected
by
that
the
one
I
have
is
it
depends
on
on
how
early
the
the
first
one
will
be,
because
you,
you
so
kai,
for
example,
this
time
that
we're
having
this
call
would
work
for
my
entire
team,
except
one
samantha
on
the
on
vancouver,
which
would
take
the
eight
back
call.
So
I
don't
know
we
could
try
to.
A
A
B
Other
that'd
probably
be
my
fear
of
two.
That
would
be.
The
only
thing
would
be
that
you
would
potentially
like.
The
second
call
might
like
one
of
the
calls
will
feel
like
a
lesser
call
right,
because
it'll
have
potentially
fewer
people,
but
I'm
happy
to
do.
I
think
the
other
piece
would
be
like
winning.
The
milestone
is
convenient
for
people.
I
think
that's
the
other
piece
that
I'm
not
sure
I
don't
necessarily
have
a
preference.
B
I
know
like
the
week
leading
into
release
and
coming
off
of
release
or
challenging,
but,
like
I
don't
know,
if
that
I
think
historically
they
were
done
on
the
first
of
the
month
or
around
the
first
of
the
month.
Is
that
still
generally
fine
for
most
people.
C
D
Yeah,
I
was
going
to
say
so,
yes
to
the
monthly,
I'm
not
sure
when
the
best
time
it
is,
but
I
think
because
of
the
time
zones,
I
think
we
should
aim
for
just
one
meeting
with
the
biggest
overlap
possible
instead
of
two
and
then
to
accommodate
people
that
are
not
able
to
join.
D
I
think
we
should
prepare
the
agenda
beforehand
so
that
everyone
can
read
what
we
will
be
sharing
or
talking
about
and
that
can
contribute
their
own
questions,
their
own
topics
and
yeah.
So
they
can
see
them
answered
or
discussed
if
they
want,
and
then
they
can
see
the
responses
afterwards
in
the
agenda
or
in
the
recording.
D
I
think
what
what
I
was
missing
a
little
bit
from
the
previous
iteration
of
the
monthly
call
was
signaling
to
the
team,
like
the
monthly
call
is
coming
up.
Hey
participate
with
what
you're
thinking
about
with
questions,
and
things
like
that.
It
felt
mostly
like
at
least
the
first
half
of
the
agenda
felt
like
something
that
could
be
previously
recorded
and
andre.
Are
you
taking
a
selfie
or
no.
D
D
Yeah,
what
I
was
going
to
say
is,
I
think,
the
group
conversation
model
works
well
in
informing
and
inviting
participation
while
also
being
mindful
of
everyone's
time,
and
if
we're
able
to
do
that
with
a
good
time
of
advance
in
advance.
I
think
it
would
be
beneficial
for
anyone
wherever
they
are
or,
if
maybe,
if
they're,
not
able
to
join
on
that
day.
D
And
then
what
I
was
going
to
say
about
engaging
with
the
team?
I
don't
know
if
this
addresses
the
concerns
that
you
heard
michelle
about
the
roadmap,
but
would
it
help
if
everyone
just
knew
like
from
kai
myself
and
and
others
that
want
to
contribute
basically
hey?
This
is
what
we're
thinking
about
like
this
could
be
a
good
bet.
This
may
be
a
good
bet,
but
we're
not
sure
so.
Would
that
help,
or
is
it
just
they
want
to
know
like
this
is
what
we're
going
to
do
like
90
sure.
A
A
What's
what's
the
future
of
this,
like
I've
got
this
iteration
that
I
need
to
work
on
this
milestone,
but
what's
it
going
to
be
in
five
milestones
and
ethics
do
a
really
good
job
of
that,
but
sometimes
it
doesn't.
Sometimes
we
work
on
an
issue
as
like:
let's
try
this
out
for
the
first
step
and
then
in
our
heads,
we're
like,
but
if,
but
if
this
first
step
is
successful,
oh
the
things
we
can
do,
and
so
I
think
it's
kind
of
both
of
those
things
like
of
what
we're
working
on
right
now.
A
C
Okay,
so
my
my
next
point,
something
that
we
have
historically
always
done
and
with
some
fluctuating
feedback
is
setting
the
milestones
on
the
issues
themselves
and
I've.
I've
been
on
several
calls
where
people
be
like.
Oh
it's
it's
going
to
be
it's
going
to
be
handled
on
39.
C
and
then
and
then
we
give
that
disclosure
that
disclaimer,
actually
it's
aimed
at
39,
but
until
it
has
a
deliverable
label
on
it's
not
really
committed,
and
I
understand
that
confusion
like
it
really
we're
setting
a
mouse
on
an
issue
and
some
of
them
roll
over
to
the
next
milestone.
After
that.
So
thinking
about
that,
I
was
wondering
about.
I
think
other
groups
do
this.
I
might
have
taken
that
idea
out
of
them
implicitly,
which
is
to
set
a
label
indicating,
what's
our
targeting.
What's
the
muscle
we're
targeting?
C
What's
the
muscle
we're
aiming
at
and
only
put
a
milestone
when
we
actually
setting
it
as
a
deliverable
and
we're
going
to
be
working
on
it.
A
C
They're,
probably
going
to
be
some
exceptions
like
slos
performance
work,
security,
work
that
that
really
are
more
strict
planning
or
scheduling,
but
for
the
overall
work
would
be
using
something
like
not
setting
the
milestone.
What
do
you
think
about
it?
Just
a
crazy
idea.
I
don't.
I
don't
really
feel
incredibly
strong
about
it,
but
I
thought
it
would
be
worth
discussing.
D
C
D
Okay,
okay,
yeah
and
also
I've
also
seen
next
up.
I
don't
know
if
anyone
uses
it.
C
B
My
question
is
more
broad:
I've
I've
seen
other
teams
that
do
this.
I
guess.
Are
you
trying
to
solve
a
team
problem
or
are
you
thinking
of
solving
an
external
problem?
I
guess
I'm.
B
To
do
because
I
I
guess
I
will
that's
probably
leading
in
the
sense
that
I
don't
like
the
candidate
label,
because
I
think
it's
incredibly
challenging
to
like
have
yet
another
label
on
issues
that
that
needs
to
be
filtered
on
top
of
sort
of
still
filtering
for
like
milestone
and
other
things,
because
some
things
will
just
already
be
locked
into
milestones.
And
so
it
becomes
like
one
more
thing
to
try
and
like
use
in
the
filter
bar.
C
It's
mostly
external,
this
happened
on
a
working
group
call,
and
I
think
historically,
we've
had
sometimes
users
or
customers
following
certain
issues
and
just
gets
rolling
over.
So
that
could
happen
too.
It's
mostly
external
that
triggered
this
conversation
more
than
internally
for
me,
filtering
by
milestone,
reflecting
by
a
label.
So
by
the
time
that
we
were
grabbing
the
issues
to
set
weights
on
and
put
them
deliverable
to
see
which
ones
are
deliverables.
C
A
Sorry
yeah,
so
I
took
this
as
completely
like
just
our
own
engineering
manager,
engineering
and
total
processes,
because
andre's
right,
we
run
a
lot
of
reports
on
targeted
milestones
and
they
always
come
with
that
caveat
and
people
seem
to
never
remember
that
and
so,
and
we
do
reports
sometimes
weekly
and
sometimes
monthly,
depending
on
what
the
report
is
on
and
in
those
reports,
it'll
be
like
okay,
but
you
had
15
things
scheduled
last
week
and
now
there's
only
two
things
scheduled
and
it's
like
yeah,
because
we
went
through
planning
and
we
kicked
out
13
of
them
and
that's
what
the
decrease
is
so
they're,
not
very
valuable.
A
So
that
would
help.
But
the
other
thing
I
wanted
to
mention
is
I
keep
a
personal
git
lab
project
to
like
organize
my
life
here
at
get
lab,
and
I
always
have
a
planning
issue
open
with
things
that
I'm
not
comfortable
assigning
a
milestone
to
that.
I
still
want
to
bring
up
in
the
planning
issue,
and
so
that's
really
just
one
internal
little
small
thing
that
would
go
away.
C
We
remember
the
snowball
conversation
we
had
a
couple
of
months
ago,
which
was
basically
we
were
just
postponing
bugs
on
and
on,
and
it's
just
like
a
snowball
growing
in
front
of
us
and
then
kai
started,
putting
things
on
the
backlog
which
helped
a
lot,
because
you
were
being
more
honest,
putting
it
in
the
backlog,
then
just
rolling
them
over.
That's
part
of
the
solution
to
that
problem.
C
This
would
be
a
second
approach
to
make
it
clearer
that
we're
not
fully
committed.
It's
just
an
aspirational
thing.
B
Yeah,
I
think
if
it
sounds
like
there
would
be
benefit
to
people
to
try
it,
and
so
I'm
happy
to
try
and
adjust.
B
I
and
I
will
say
that,
because
I
just
put
stuff
in
a
milestone,
that's
how
I
deal
with
michelle's
list
problem
is
I
just
put
them
in
the
milestone
and
then
when
we
get
to
planning,
then
we
go
through
and
we
say:
well,
we
don't
actually
have
room
for
all
of
this,
because
what
I
and
and
part
of
the
reason
I
do
that
is
so
like
right
now,
I'm
looking
at
like
the
13
9
board,
because
I've
been
doing
the
last
couple
days
is
I
keep
pulling
up
the
13
9
board
and
I'm
looking
and
I'm
going?
B
Okay,
what's
all
in
here
because,
like
michelle
sent
you
know
capacity
and
andre
sent
capacity
and
I'm
so
I'm
looking
I'm
going.
There's
a
lot
in
here
so
like
I
can
start
to
immediately
sort
of
prune
that
list
back
out
and
just
like,
take
thirteen
nine
and
either
kicked
up
to
thirteen
ten
or
move
it
to
backlog
very
quickly
sort
of
one
set,
and
I
guess
the
label
would
work.
B
Similarly,
as
long
as
we
were
incredibly
consistent
about
applying
it
versus
like
a
label
plus,
a
a
milestone
is
sort
of
like
feels
challenging
like
some
stuff
might
say,
candidate,
thirteen
nine
some
stuff
might
say,
milestone
thirteen
nine
and
we
don't
support
or
filtering
anywhere
so
like.
I
can't
actually
see
a
list
that
has
both
of
those
things
in
it,
and
so
I
worry
that
my
fear
is
that
it
becomes
harder,
because
you've
got
two
things
sort
of
indicating
when
you
might
do
something
versus
a
single,
a
single
piece.
There.
C
That's
true
and
I
can
even
see
a
situation
where
we
have
disjoint
milestones,
candid
for
39
miles
in
1310
who
wins
milestone.
I
guess,
but
we
could
set
that
as
a
rule.
But
if.
A
But
if
we
did
get
better
about
that,
I
guess
it
would
be
okay
to
just
put
all
of
it,
because
I
think
part
of
why
this
is
important
for
us
is
because
our
milestones
are
crazy
and
we
never
get
to
all
of
it.
But
the
other
thing
that
I
use
like
this
label
if
I
were
to
use
it,
would
be
to
remind
myself
that
if
it
does
not
make
it,
I
need
to
add
a
comment
indicating
why
it's
going
to
get
pushed
back.
A
C
Okay,
so
maybe
we
can
just
keep
it
in
the
in
the
back
of
our
minds
for
now.
Don't
execute
anything
just
get
better
at
pruning
and
we'll
see
if
this
comes
back
again,
but
for
now
it
feels
like
there's
some
side
effects
that
could
lead
to
more
confusion,
yeah
getting
better
at
pruning.
That
seems
like
to
be
the
takeaway
right.
B
B
We
will
lock
the
milestone
at
some
point
and
we'll
say
this
is
what
it
is,
and
this
is
the
deliverable
list
and
what
we
did
last
month
is
as
soon
as
we
were
done
with
those
calls
everything
that
didn't
make,
that
cut
either
moved
to
1310
or
move
to
a
backlog
right
like,
and
so
I
think,
as
long
as
we're
sort
of
diligent
about
making
sure
that
we
draw
that
cut
line
and
get
them
out
of
the
milestone,
then
that
helps
that
at
least
helps
keep
the
milestone
crazy,
but
yeah
we've
gotta,
we
gotta
make
sure
we
prune
the
list
and
don't
get
to
the
situation
where
they're
like
hey,
there's
this
issue,
that's
got
missed
since
13
and
everyone's
like
oh
yeah.
B
C
Okay,
yeah
thanks
for
the
conversation
people,
okay,
go
for
the
next
point.
B
You'll
get
the
last
one,
and
I
know
there
was
resistance
at
first.
I
am
interested
in
proposing
again
that
we
try
to
have
individual
contributors
provide
a
weekly
status
update
in
the
planning
issue.
I
know
the
resistance
before
was
like
well,
that
should
be
happening
in
the
actual
issues,
we're
working
on
or
sort
of
these
other
things,
and
I
will
say
I
have
not
seen
many
if
any
individual
contributors
on
even
a
slightly
regular
basis,
comment
on
any
of
the
issues
that
are
being
worked
on.
B
Versus
being
like,
hey,
everything's,
okay,
here
or
hey,
I
haven't
looked
at
this
one,
but
I'm
planning
on
looking
at
this
one.
You
know
next
week
we
don't
even
see
sort
of
like
those
kind
of
things
and
I'll
say
like
what
I
saw
this
week
was
sort
of
hey
we're,
not
gonna.
Get
to
this,
like.
B
Even
if
you
haven't
looked
at
it,
is
that
you,
like,
I
think,
as
an
individual
contributor
you're
aware
that,
like
hey,
I've
got
that
list
of
five
things,
and
maybe
it's
looking
more
and
more
unreasonable
that
I'm
gonna
get
to
those
five
things,
and
I
can
like
say
something
sooner
but
yeah.
I
I
know
there's.
I
know
it's
more
overhead
and
potentially
creates
like
a
second
area
where
this
happens,
but
I
think
it.
I
think
it
would
help
me
understand.
B
I'll
also
say,
like
I
put
the
example
in
about
suggested
change,
commit
messages
which,
like
was
it,
carry
over
from
13
7,
and
so
I
would
have
expected
that
that
had
like
shipped
in
13
8
and
then
there
was
like
an
ask
for
a
docs
update
and
it
was
like.
Oh
well,
docs
aren't
coming
until
this
other
thing
comes
and
there's
a
feature
flag,
and
so
I
went
and
looked
at
the
issue
and
like
we
don't
say
the
word
feature
flag
anywhere
in
the
issue.
B
C
C
Most
of
the
team
started
two
weeks
in
and
we
didn't
even
do
the
mid
milestone
check-in
that
we
usually
do
and
that
you're
right
like
you,
you
don't
see
the
ics
doing
that,
because
that's
not
a
habit
that
we've
cultivated
along
the
months
so
but
it's
something
we
can
start
doing
michelle.
Do
you
want
to
say
anything.
A
A
All
week
the
team
has
been
talking
about
this
too,
what
their
cadence
will
be,
and
yesterday
somebody
was
like
it
would
really
be
helpful
if
I
was
able
to
do
this
daily,
you
think
anybody
would
get
mad
at
me
and
I
was
like
no.
I
don't
think
anybody
would
get
mad
at
you
all
right.
So,
let's,
if
you
want
to
do
kai,
if
you
want
to
get
us
like
an
example,
template
like
ideally,
this
is
exactly
what
it
would
look
like.
I'm
at
this.
B
C
B
Preference,
my
preference
is
the
planning
issue.
I
think
that's
in
conflict
with
what
we
would
consider
the
issue
to
be
the
single
source
of
truth.
But
I
would
say,
the
planning
issue
is
a
case
of
managing
up.
Sometimes
you
have
to-
and
I
say
up
in
the
loose
sense
that,
like
this
is
a
communication
to
me
or
to
other
stakeholders
like
the
four
of
us
or
some
in
terms
of
people
who
are
concerned
with
how
the
progress
might
be
going
in
the
milestone.
C
D
Okay-
and
I
think
at
least
in
the
beginning,
it
could
be
good
to
have
the
status
updates
by
the
whole
team
happening
in
the
punting
issue,
so
that
the
team
members
also
learn
from
one
another
and
get
inspired
about
how
others
are
reporting
on
their
updates
and
could
possibly
help
share
knowledge
across
the
team
and,
like
someone
might
have
solved
a
similar
problem
previously
at
gitlab
or
another
company.
So
I
think
at
least
in
the
beginning.
The
planning
issue
could
could
be
a
good
way
to
to
start
for
the
whole
team.
A
A
There's
no
way
I'll
finish
by
friday,
but
I
think
I
can
do
it,
but
I
just
saw
y'all's
faces
when
you
looked
at
it
and
your
jaw
dropped,
and
so
I
think
that
you
probably
all
know
that
that's
not
gonna
happen
and
so
yeah,
it's
a
good
place
for
accountability
to
just
kind
of
say
I
notice
you're
working
on
five
things
this
week.
Do
you
really
feel,
like
that's
gonna
happen,.
C
That's
a
good
point,
just
the
final
question:
do
you
feel
like
it
would
be
useful
to
set
a
a
consistent
day
on
the
week
to
have
this
update
be
done
for
everyone
like
every
friday
every
monday,
or
should
everyone
just
do
whatever
they
they
feel
like
it,
because
I
remember
editor:
did
it
on
fridays?
Was
it.
B
I'm
scrolling
the
editor
issue
right
now
and
one
of
the
things
people
do
is
they
put
the
date
at
the
top.
It
looks
like
there's
a
combination
of
like
fridays
and
mondays
and
wednesdays
and
thursdays
and
all
of
the
days.
I
think
it's
like
a
once
a
week
thing.
I
think
I
would
be
sad,
I
think,
like
as
a
first
generation
like
if
we
feel
like
we
need
to
say
like
do
it
on
this
day,
to
help
recommend.
C
B
C
Gotcha
get
that
format
up
to
us
and
we'll
we'll
circulate
that
with
the
team.
C
And
we're
at
time
capacity
is
delayed,
I'm
hoping
I'm
getting
it
to
you
today,
even
if
I
don't
sleep,
but
today
I'll
get
you
everything
in
there.
So
we
can
get
it
everything
just
like
michelle.
It's
a
crazy
week
for
for
us
we're
doing
a
bunch
of
things
for
the
team,
but
we're
definitely
gonna
get
it
on
time.
Hopefully
so.