►
From YouTube: 2020-03-03 Create:Code Review Weekly 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
From
the
last
one,
we
had
a
couple,
we
ran
out
of
time
towards
the
end,
and
we
were
talking
about
sort
of
encouraging
more.
I
can't
even
find
it.
I
should
have
linked
it
more
people,
you
know
to
feel
okay,
taking
community
contributions
or
like
ownership
or
sort
of
like
doing
these
other
things.
A
And
I
added
a
comment
sort
of
as
we
ran
out
of
time
that,
like
I
wonder
if
we
could
experiment
with
sort
of
like
20
times-
and
I
don't
know
if
that's
the
right
number,
but
if
that
would
sort
of
bridge
that
gap
and
give
people
that
freedom
to
go
and
work
on
things
that
they
want
to
work
on.
And
I
added
that
I
would
also
be
comfortable
sort
of
exploring
some
of
that.
A
Because
planning
for
nine
engineers
is
a
lot,
and
so
I'm
I'm
willing
to
like
let
engineers
plan
some
of
their
own
work
as
long
as
we
figure
out
how
to
like,
and
maybe
we
don't
have
to
figure
out
what
that
is
at
first.
Maybe
we
like
see
what
happens
if
we,
if
we
roll
some
of
that
back
out,
but
I
thought
it
was
worth
sort
of
like
continuing
to
talk
about
that
and
get
thoughts
on.
Maybe
what
people
thought
for
doing
that?
A
Maybe
we
tried
in
1311
or-
and
maybe
that's
part
of
the
kanban
stuff
too,
is
like
they
get
a
little
more
autonomy
into
that,
and
maybe
that's
what
they're
looking
for,
and
maybe
it's
a
different
way
to
do
that
or
part
of
it,
but
thoughts.
B
Yes,
I'm
all
for
it.
Instead
of
just
doing
it
loosely
of
like
hey,
you
can
work
on
whatever
you
want.
It'd
be
nice
to
have
a
buffer
like
a
buffer
issue
for
each
one
assigned,
and
then
they
would
claim
it
and
just
point
hey.
B
I
worked
on
this
thing
so
that
we
have
a
track
record
about
what
they
use
that
percentage
for
so
they
can
see
whether
that's
usable
or
that's,
useful
or
not,
and
the
second
is
to
to
have
a
clear
mark
about
what
are
the
issues
that
are
actionable
or
that
are
ready
to
be
taken.
We
could
use
the
ready
to
be
ready
for
development
label
as
like
the
the
decisive
factor
for
to
give
them
a
hint
like
here.
Here's
the
issues
that
are
up
to
be
picked
up.
B
C
A
I
think
the
other
piece
of
this
was
like
making
sure
they
find
the
the
right
work.
I
know
you
mentioned
using
ready
for
development,
and
that
may
be
one
thing
we
may
want
to
think
on
that
a
little
bit
more.
I
know-
and
I
say
this
because
I
I
know
that
I
contributed
to
david-
not
doing
the
filter
thing.
A
I
sort
of
explicitly
said
no
one
was
asked
and
then
phil
sort
of
went
and
did
it
without
asking
and
that's
why
it
got
done
right
like
it's
just
it
happens
with
kids
like
the
kids
ask-
and
you
know,
forgiveness
is
sometimes
better
than
permission
is
sort
of
like.
I
think
what
the
model
just
showed
us
there,
and
so.
A
But
I
don't
want
to
discern,
I
think,
we've
learned
a
lot
with
like
phil
pushing
on
it,
so
I
think
there's
a
way
to
do
that.
I
think
maybe
the
thing
to
figure
out
is
like
properly
setting
expectations
that
like
hey,
even
if
you
go
and
work
on
this
thing
like
we
might
not
merge
it
or
we
might
need
to
block
it
and
like
making
sure
the
team
is
comfortable
with
that
is
maybe
a
way
to
hedge
against,
like
people
taking
on
passion
projects
and
then
feeling
upset.
A
If
we
don't
do
anything
about
it
or
we
don't
respond
in
a
way
that
is
like
the
way
they
wanted
to
see
that
go.
So
maybe
maybe
that's
part
of
this
and
something
to
think
about.
I,
I
don't
have
a
good
answer
for
this
one
either,
but
wanted
to
make
sure
that
we're
thinking
about
this
aspect
of
it
too.
B
Yeah
kai,
I
100
agree.
Maybe
we
can
work
together
and
iterate
on
a
merge
request
to
update
our
team
pages
to
establish
this
expectation,
like
engineers,
are
welcome
to
contribute,
knowing
that
a
b
and
c
having
some
some
expectations
set,
and
I
think
if
we
do
that
on
our
team
pages,
then
we'll
know
the
people
in
those
teams
will
know
that.
A
A
Me
so,
okay,
I
will
go
and
I'll
go
and
start
something
and
then
pass
it
to
you.
Both
great
could
take
a
lot
of
the
merger
requests
on
and
I
don't
actually
know
where
our
team
page
is
anyway.
So
those
would
be
a
good
use
to
go
phone
cool
michelle.
You
get
the
next
one
up.
C
Okay,
this
is
more
of
an
fyi,
because
it's
a
slide
deck
and
it'll
take
a
minute
to
get
through,
but
andre
created.
This
awesome
slide
deck,
which
is
huge
and
robust
for
dog
fooding
reviewers
it's
going
to
be
sent
to
maintainers
today.
The
short
story
is
almost
exactly
the
same
as
david's.
Mr,
the
only
real
difference,
if
you
could
even
call
it
that
is
assignees,
are
exclusively
the
authors
or
dris
and
that
is
like
defined
versus
in
his
mr.
C
It
was
just
kind
of
like
you
do
do
what
you
want
there
so
we'll
see
how
that
goes,
but
any
questions
on.
A
That
you're
just
gonna
like
somehow
I
guess,
ping
all
the
maintainers
in
slack
and
be
like
hey
look
at
this.
I
wonder
if
we
should
do
like
a
a
couple
amas
and
like
maybe
do
sync
sessions
that
way
on
it
like
try
and
work
with
katie
to
schedule
like
just
the
maintainers,
for
the
sync
ama
like
over
the
next
yeah.
B
C
B
B
B
We
don't
even
need
to
do
the
ama,
but
if
we
do
see
some
noise
I
would.
I
would
expect
this
that
yeah.
We
should
definitely
address
that
feedback,
but
but
initially
not
not
start
with
that,
because
you
still
have
more
than
a
week
to
collect
the
validation
feedback
from
maintainers
there's
a
slide
there.
That
gives
it
a
timeline
and
it's
until
then
not
this
friday,
the
next
week's
friday
to
collect
feedback
and
then,
if,
during
those
days
after
today,
we
see
a
lot
of,
even
though
we
try
to
address
all
the
questions.
C
I'm
not
open
to
it.
Let's
see
how
it
goes
if
there
are,
if
it's
like
a
lot,
and
maybe
my
mind
can
be
changed,
but
overall,
I
feel
like
we
do
a
lot
of
amas
as
it
is.
That
is
not
very
empowering
for
the
nature
of
git
lab
and
the
async
nature
and
people
in
all
the
time
zones,
and
I
just
feel
like
we
should
be
so
clear
in
our
communication
that
an
ama
really
isn't
needed
and
that
that
kind
of
speaks
that
we
weren't
doing
good
enough
of
a
job.
C
A
I
guess
my
my
point
sort
of
was
that
an
ama
allows
you
to
explicitly
limit
without
excluding
the
audience,
whereas
an
issue,
even
if
you
only
ping
the
maintainers
that
issue's
gonna
move
fast
through
through
the
engineering,
org
and
you're
gonna
you're
gonna
see
the
feedback
show
up
from,
maybe
not
the
audience
that
that
we're
looking
for
would
be
sort
of
my
the
re,
I
think
that's
the
risk
that
we
run
is
that
you
end
up
back
in
the
same
position,
because
the
same
people
who
saw
the
first
time
are
going
to
see
it
this
time.
B
Yeah,
that's
a
good
point,
but
I
think
I
think
we
definitely
don't
want
to
hide
this
from
the
engineers
as
well.
It's
just
that
right
now,
the
stages
we
want
to
collect
just
a
validation.
We
don't
even
call
it
like.
What's
your
feedback,
it's
just.
We
just
want
to
make
sure
that
you
validate
this
iterate
iterative
step
on
the
process
and
we
call
it
exactly
that
and
we'll
see
how
it
goes.
We
have
to
keep
it
a
little
bit
loose.
B
Otherwise,
it'll
be
hard
to
just
sell
this
and
honestly,
it's
not
that
big
of
an
ask.
We
don't
we're,
not
changing
the
a
lot
of
the
way
that
the
people
are
changing.
The
process
that
they
were
doing
before
we
had
reviewers
is
just
trying
to
get
everybody
to
play
by
the
same
rules
and
have
the
same
expectations.
B
I
got
your
point,
I
got
you
fight
and
we'll
see
how
it
goes.
We
might
learn
a
few
things
thanks.
C
Michelle
yeah
mid
milestone
check
in
just
so
that
you're
aware
andre,
I'm,
I'm
never
gonna
put
the
percent
here
because
your
number
never
matches
mine,
but
I
think
we're
like
exactly
50
back
in
team.
Overall
progress
is
45,
which
is
awesome
because
that's
super
on
target,
so
everything
is
on
track
and
then
here's
a
breakdown
of
what's
going
on.
I
don't
know
this
is
this.
Is
the
calculation?
I
don't
know
why
two
issues
equals
20.
Also
three
issues
equals
20,
but
that's
the
breakdown.
We've
only
got
four.
That's
been
started.
B
Okay,
so
the
way
that
we
do,
the
calculation
is
just
we
check
the
total
of
the
weights,
and
then
we
check
we
consider
done
verification
at
100
done
in
review,
80
percent
done,
and
then
we
check
what
that
means
in
terms
of
the
total
of
the
weights.
That's
what
gives
the
percentage
so
my
my
status
update
is
we're
currently
sitting
at
52
estimation
of
completion,
so
it
looks
like
we're
on
track.
We
had
a
lot
of
work
already
finished,
like
the
smaller
things
already
merged
and
and
in
production.
B
Some
of
them
there
is
one
thing
that
I
would
call
out
is
like
for
staff
or
kr's.
Phil
is
working
on
a
big
bulk
of
work
to
refactor
the
emoji
drop
down,
so
that
might
be
holding
a
lot
of
points
of
weight
like
on
in
flight,
which
we
might
be
even
a
little
bit
ahead
of
52.
B
The
other
thing
is
that
when
I
hope
I
don't
get
this
wrong
gary
and
thomas
they're
working
on
the
synchronization
of
the
file
by
file
user
preference,
and
they
uncover
that
we
can't
use
the
existing
api,
because
the
existing
api
is
for
admin
only
and
we
want
this
to
be
non-admin
users
just
checking
just
setting
the
preference.
So
we
have
to
create
a
new
endpoint.
We
didn't
really
foresee
that
for
the
synchronizing,
the
user
preference
of
file
by
file,
I'm
looking
at
uk
your
face,
I
know
I'm
trying
to
figure.
B
B
We'll
so
the
idea
here
is
we'll
we'll
add
a
new
endpoint
to
update
the
user
preference
we're
already
reading
the
user
preference,
that's
a
good
thing,
but
it
might
be
that
the
back
end
work
is
finalized
like
later
in
the
milestone
in
the
front
that
doesn't
have
enough
time
to
ship
it.
But
even
if
it
slips,
it
might
be
just
a
slight
slip.
But
I
right
now
it's
at
risk.
B
A
B
We
haven't
done.
We
haven't
done
a
great
job
at
using
public
apis,
especially
in
code
review.
All
of
our
endpoints
are
customized,
so
we
could,
I
think,
graphql
kind
of
moved
us
in
that
direction
where
all
of
the
graphql
endpoints
are
kind
of,
like
already
prepared
for
kind
of
loose
consumption.
That's
like
the
nature
of
graphql,
but
yeah.
I
was
surprised
that
we
don't
have
batch
comments
on
apis.
That
was
a
surprise.
A
B
Yeah,
it
is
because
we
for
us
to
consume
graphql
on
the
on
the
diff
sepia
on
the
divs.
App
we'd
have
to
add
some
new
components
for
the
front-end
architecture,
basically
apollo,
and
we
don't
want
to
mix
vox
and
apollo
in
such
a
complex
application
with
memory
usage
problems
and
stuff
like
that.
B
A
A
Okay,
okay,
yeah,
there's
a
lot
to
not
yeah,
okay,
cool.
B
Okay,
we're
done
amy
hi.
E
So
I
mostly
wanted
to
check
in
with
kai
here,
to
find
out
what
I
should
expect
from
the
team
regarding
this
work.
I
don't
have
a
sense
of
how
important
it
is
to
the
team.
I
just
know
that
I
looked
at
it
and
said
I
can
move
this,
this
horrifying
piece
of
technical
debt
forward,
but
I
can't
finish
it.
So
it's
going
to
be
off
my
plate
soon
and
I
will
leave
the
rest
up
to
your
team.
Just
let
me
know
what
you
need
from
me.
A
C
C
What
do
we
need
to
do
what's
been
done?
What
do
we
need
to
do.
E
For
me,
I
know
that
right
now
I
don't
have
the
same
kind
of
deliverables
as
the
rest
of
the
team
and
I'm
coming
in
cold,
but
if
there's
something
horrifying
in
the
backlog
that
you
would
like
me
to
get
to,
let
me
know
I'm
going
to
be
looking
to
the
pm's
across
create
to
set
most
of
my
working
priorities.
A
He
sent
you
a
long
list,
so
I
think
that's
working
so
far,
but
yeah
andre
michelle
given
like,
if
you
do
know
of
anything
amy,
has
asked
in
the
planning
issue
for
like
a
list
of
issues.
A
So
if
you
run
across
steps,
that's
got
docs
or
text
changes
feel
free
to
add
under
the
list.
It
has
been
crazy
to
see
so
thank
you,
amy.
All
of
the
like
issues
and
merch
requests
of
all
these
things
that
we've
wanted
to
like
change
and
just
have
not
gotten
to
that
are
just
like
moving
along.
So
it
was
very
much
appreciated.
E
E
A
Awesome
cool
thanks
thanks
everyone
else,
we'll
see
you
around
I'm
off
tomorrow
and
friday,
I'll
be
home
tomorrow,
but
not
ready.
You
need
anything.
Ping
me
on
slide
sure
enjoy
your
time
off.
Man
you
deserve
it.