►
From YouTube: 2020-02-03 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).
B
I
was
just
going
to
mention
him.
Real,
quick,
like
the
share
drive
is
worth
I
don't
know.
If
people
know
they
were
all
added,
it's
open
to
everyone
in
the
code
review
group.
I
think
so
anyone
can
put
documents
there,
but
it's
where
I
put
stuff
when
I
talk
to
people
or
partners
or
whatever
those
docs
and
recordings
all
end
up
there,
if
you're
ever
curious
and
then
the
other
one
is.
I
woke
up
to
that
issue
that
says
kenny
will
be
the
acting
group
manager
for
create.
B
So
I
don't
know
if
that'll
impact
anything
for
us,
but
just
as
an
fyi
and
yeah,
I
think
david's
gonna
stay
as
the
director
I
don't
know
so
yeah.
That
is
the
the
latest
there
in
case
anyone
was
curious.
A
Cool
thanks
for
sharing
it's
gonna,
be
an
exciting
month
for
dev
yeah.
My
first
point
is,
I
think,
just
to
like
thank
everyone
for
keeping
all
of
the
discussions
and
meetings
that
happened
around
code
review
in
the
same
document
for
me
has
been
very
helpful
to
go
back
and
forth
between
the
meetings
and
link
some
of
the
topics
that
sometimes
we
discuss
in
the
weekly
other
times.
We
discuss
it
in
the
ux
and
yeah,
because,
in
the
end,
everything
is
related
and
yeah.
A
C
B
Yeah,
so
I
had
a
conversation
with
review
nb,
who
does
it
has
a
tool
for
diffing
and
doing
code
review
of
jupyter
notebooks,
which
are
used
by
like
data
scientists
and
like
data
teams
and
sort
of
in
that
community,
I
think,
is
largely
where
they're
used
they.
B
There
is
an
ask
on
our
side
to
like
provide
jupiter
notebook
diffs
in
a
like
rich
format,
because
they're
like
they're,
a
format
that
then
generates
like
graphs
and
other
things
like
inside
of
it
in
the
rendered,
jupyter
notebook,
and
so
people
actually
want
to
diff
like
the
the
render,
not
the
raw
code,
because
that's
sort
of
just
like
xml
or
svg
type
markup,
but
plots
all
of
that.
Eventually.
B
That
would
be
complicated.
I
think
for
us
to
build
and
like
work
in,
and
so
I've
asked
them
if
they
want
to
do
it
because
they
do
it
for
github.
That
is
github's
sort
of
answer
to
it
as
well,
but
there's
some
blockers
to
them
doing
that
right
now,
and
so
I
thought
it'd
be
worth
seeing
what
those
are
at
least
the
first
year
seem
to
be
in
terms
of
them
retrieving
the
diffs
at
all.
C
Yeah,
I
just
wanted
to
highlight
that
we
we
did
some
work
on
the
source
code
side
of
things,
enhancing
the
way
that
it
renders
on
the
blob
view,
so
that
was
good.
It
had
support
for
latex
and
other
fancy,
rendering
of
images
and
stuff,
but
yeah.
The
diff
thing
is
definitely
a
different,
a
far
more
complex
challenge,
so
if
they
have
a
tool
that
does
that
happy
to
consider
it
and
investigate
if
you
and
I
can
put
one
of
ics
one
of
our
ics
to
investigate
any
front-end
involvement.
B
B
C
A
plug
basically
yeah
yeah,
I'm
particularly
interested,
as
you
know,
about
the
intricacies
of
doing
this
with
the
self-hosted,
whether
they
have
would
have
have
a
feature
toggle
to
be
able
to
enable
or
disable
this
thing.
So
all
of
that
thing
is
just
the
usual
thing
that
you
already
know
all
right.
Keep
us
posted.
B
Them
I
liked
you,
that's
the
issue
on
our
side
in
terms
of
demand,
there's
quite
a
few
like
customer
links
in
terms
of
salesforce
and
zendesk
links.
You
may
have
quite
a
few
there's
a
few
and
then
the
issues
got
a
reasonable
number
of
up
votes
more
than
more
than
many
issues
that
we
work
on.
B
So
I
think
people
want
it
and
it
looks
like
we
looked
into
it
before
and
like
the
libraries
to
do
this,
don't
align
with
our
tech
stack
and
so
like
sort
of
a
problem
in
terms
of
like
how
we
would
be
even
like
you
do
these
things
like
the
libraries
that
exist.
B
Aren't
I
mean
maybe
this
has
changed
in
a
in
a
year
or
two,
but
it
wasn't
even
that
long
ago,
the
last
time
phil
looked
at
it
so,
and
I
think
this
gives
us
a
way
to
not
do
it
but
provide
an
option.
And
then,
if
customer
demand
is
like
good
for
it,
then
we
can
monitor
and
measure
that
and
then
we
could
always
go
and
build
it
ourselves.
But
I
don't
think
it's
anything.
We
want
to
spend
the
time
building
right
now,.
B
Yeah
not
for
us
to
do
it,
but
we
may
need
to
do
the
work
to
enable
someone
else
to
do
it
again
would
be
the.
C
Yeah,
we
look,
I
think
we
we
consider
looking
at
some
of
the
libraries
that
do
rendering
on
the
front
end
of
this,
because
the
backend
tool
that
exists,
like
you,
said
it's
mostly
python,
based
not
ruby,
so
it's
kind
of
like
hard
to
plug
it.
But
the
way
that
I
see
it
is
like
some,
the
customers
who
use
this
use
this
extensively,
the
ones
who
don't
don't
even
know
about
it.
So
it's
kind
of
like
that.
B
Yeah
and
then
the
and
then
it's
usually
like
a
small
number
of
people
inside
of
a
company,
because
it's
typically
only
like
especially
for
the
ones
where
it's
like
data
scientist,
focus
and
stuff-
that's
like
at
gitlab.
That
would
be
like
four
people
who
would
who
would
be
like
contributing
and
doing
things
with
with
that,
not
the
entire,
like
1300
plus
organization,
and
so
it's
like
it's
even
smaller,
subset
of
like
people
inside
of
a
company
who
might
even
care
about
this,
and
so
it's
just
a
little
bit
different.
In
that
sense,.
B
The
next
one
is,
I
don't
know
I've
been
spending
some
time,
looking
at
approval,
rules
and
code
owners
and
thinking
about
reviewers
and
sort
of
the
future
of
that,
and
we've
been
talking
a
lot
about
like
reviewer
roulette,
and
if
you
look
at
all
the
data
that
reviewer
roulette
gets.
You
know
it
gets
this
amazing
source
of
data
because
it
pulls
from
team.yaml
and
slack,
and
all
these
other
things
that,
like
are
obviously
not
native
to
the
product
and
one
of
the
things
that
is
native
to
the
product,
is
code
owners.
B
The
gitlab
project
is
sort
of
has
a
laughable
use
of
code
owners
at
best
and
that,
like
anything,
that's
a
ruby
file
is
just
like.
Oh
it's
back
in
and
like
it's,
not
it's
not
segmented
down
to
even
like
these
things.
You
know
like
there's,
not
a
section
for
like
every
single
stage
group,
even
though
you
would
expect
sort
of
like
stage
groups
to
be
more
responsible
for
things
that
are
in
their
area,
and
so
I
don't
know
if
there's
any
like.
B
I
just
want
to
gather
some
ideas
of
like
how
can
we
get?
I
think
for
us
to
push
forward
on
reviewers,
and
even
I
know
when
we
were
having
trouble
with
code
owners
and
approval
rules
last
year.
You
know
a
lot
of
that
stems
from
our
lack
of
usage
there,
and
I
think
we
need
to
be
a
lot
better
about
that,
and
I
know
that
potentially
could
create
some
friction
and
like
the
development
organization,
where
might
need
more
explicit
approval
rules
and
things
could
get
sort
of
inadvertently
blocked.
B
D
But
if
we
can
get
the
optional
section,
optional
section
approve
bowls,
and
then
we
can
probably
open
an
issue
to
propose
it
for
the
actual
gitlab
project
as
well.
But,
like
you
said,
we
really
had
a
rough
year
last
year
and
it's
every
time
something
happened.
It
went
back
to
like
well,
we
didn't
know
that
the
customers
were
using
it
that
way,
that's
not
how
we're
using
it
and
in
most
cases,
we're
not
using
approval
rules
or
code
owners.
The
way
customers
use
it
anywhere
on
in
the
gitlab
projects.
D
So
I
think
sectional
code
owners
has
already
been
released.
I'm
not
sure
what
the
status
is
of
the
optional
approvals,
but
that
is
the
start,
I
think,
can
contribute
to
the
www
issue.
B
Yeah,
do
you
think,
without
even
like
building
approval
rules?
Do
you
think
there
would
be
like
resistance
to
having
like
more
specific
code
owners
just
like
if
we
contributed
an
mr
that
was
divided
up
and
made
a
bunch
of
sections
and
put
them
out
to
groups?
Do
you
think
there
would
be
resistance
to
like
see
that
merged
in
general,
because
I
don't
know
that
we
necessarily
need
approval
rules
right,
like
I,
don't
think
we
I
don't
know.
If
we
have
code
on
our
approval
rules
turned
on,
I
don't
think
we
do.
B
But
what
would
be
nice
is
to
have
code
owners
as
a
source
of
data,
that's
sort
of
what
I
want
to
have
to
in
order
to
enable
reviewers.
It
doesn't
necessarily
need
to
be
approval
rules,
but
it
needs
to
be
a
source
of
data
as
well
for.
D
C
Michelle
we
have
the
concept
of
domain
experts
and
that
could
be
a
good
place
to
start
on
now
that
we
have
the
optional
sections,
if
you
could
start
layering
in
those
sections
of
the
main
expertise,
I
know
that
the
front-end
user
used
them
extensive
and
we
have
a
lot
of
them
already
identified.
D
C
B
Yeah
I
mean,
or
in
true
get
love
spirit.
We
could
just
put
an
mr
forward
and
like
actually
make
the
changes
in
the
code
owner's
style,
and
I
think
if
it
was
a
non-workflow
impacting
change
like
that's
sort
of
a
start
right
like
that,
helps
get
us
down
a
path
and-
and
then
you
know,
I
think,
if
we
want
to
start
building
in
approval
rules,
we
might
have
to
ask
permission-
or
maybe
we
asked
for
we
don't
know
about
any.
B
I
mean
that
might
be
a
little
more
challenging,
but
at
least
we
could
at
least
if
we
lay
the
groundwork
and
we're
more
in
a
spot
where,
like
we
want
the
feedback,
I
think
I
think
we
should
do
the
non-controversial
things
and
then
like
wait
until
we
know
it's
going
to
be
controversial
to
sort
of
like
here's.
What
we've
been
doing-
and
this
is
why
and
like
this
is
the
last
step
that
we
need
to
do
to
like
be
able
to
really
get
this
in
understanding.
C
C
I
don't
know
exactly
who
has
the
rights
to
enable
coroner
approvals
enforcement
on
the
project,
but
we'll
we'll
take
a
look
at
that.
C
A
No
yeah,
I
think
it's
it's
just.
I
think
we
already
talked
about
it's
just
saying
that
I
think
we're
just
not
using
them,
regardless
of
the
way
we're
using
them
and
yeah.
I
agree:
that's
pushing
something
forward
to
change
that
as
soon
as
possible
is
the
best
way,
because
we
need
to
feel
the
pain
in
order
to
improve
things
and
to
learn
more
about
them
yeah,
and
it
feels
like
we've
been
avoiding
it
somehow.
A
D
Totally
agree,
my
the
milestone
check-in.
My
overall
progress
here
is
71,
so
I
am
very
pleased
I'm
not
concerned
at
all.
We
are
not
blocked
with
anything.
We
have
seven
issues
that
are
closed
or
under
verification,
that's
more
than
half
of
the
issues
that
are
already
taken
care
of,
and
then
about
even
in
review
and
in
doubt,
and
so
we're
working
through
that.
I
don't
expect
anything
bad
to
happen.
I
hope
yep
go
ahead.
Andre.
C
Yeah
thanks,
that's
great
from
our
side
we're
so
the
the
elapsed.
Time
of
the
milestone
is
at
56
percent.
It's
something
I
always
check
to
compare
with
the
progress
we're
at
50
57
of
progress,
which
sounds,
is
an
estimated
number,
but
it
does
feel
like
we're
on
track.
There's
a
couple
of
things
that
we
haven't
covered,
as
so
you
already
know
about
that.
Unexpected.
C
Finding
on
the
replacement
of
variables
in
the
custom
commit
message
when
applying
suggestions,
work
where
the
solution
we
found
we
pursued
with,
doesn't
make
it
easy
to
make
it
work
on
the
overview
tab.
It
works
on
the
changes
tab.
It
doesn't
work
on
the
overview
tab
we'll
pursue
that
on
a
separate
effort.
I'll
have
to
find
a
better
solution
for
that.
C
But
yes,
we
agree
that
we're
not
blocking
the
feature
rollout
for
that
and
yeah.
So
it
does
feel
like
we're
on
track
overall,
there's,
no
major
red
flag,
there's
some
investigation
issues
that
we
have
scheduled
this
issu,
this
milestone
that
haven't
started.
So
I
last
I
heard
they're
going
to
be
started
soon
over
the
next
couple
of
days,
so
we
should
be
getting
that
rolling
as
well,
so
yeah,
no
major
red
flags.
There.
A
Is
so
the
original
issue
that
thomas
is
working
on
this
milestone?
It
is
labeled
as.
D
Yeah
I
just
wanted.
I
don't
know
if
this
is
useful,
but
maybe
this
is
useful.
Just
for
my
own
self,
we
do
have
two
feature
flags
we're
looking
to
remove
or
enable
this
release.
So
I
feel
like
maybe
a
call
out
for
those
separate
is
at
this
point
may
be
warranted,
so
merge,
refs
and
reviewers
nothing
to
do
about
it.
I
just
think.
Maybe
if
we
don't
trust
the
data
that
we're
getting
andre,
maybe
we
should
verbalize
what
the
status
of
our
feature
flags
are
for.
C
C
That's
a
good
point
and
the
custom
commit
message.
The
feature
flag
is
also
being
enabled
by
default
over
the
I
think
it's
between
today
and
tomorrow.
So
that's
good.
D
B
Yeah,
I'm
I'm
optimistic
that
we
could
get
it
on.
I
don't.
I
don't
think
we
should
try
and
default
it
on
and
self
managed.
B
Actually,
sort
of
like
cautious
about
that
one,
because
I
feel
like
that
one's
going
to
be
tougher
to
roll
back,
but
I,
like
the
sooner
we
get
it
on
like
the
easier
that
decision
becomes
over
the
next
like
week
and
a
half
so.
B
Cool
thanks
for
all
the
updates
everyone,
it's
good
to
see
everyone
enjoy
the
rest
of
your
wednesday
week.
Things
look
good,
they
look,
they
look
really
good.
So.
C
We're
getting
there
awesome
just
as
a
teaser
and
tomorrow
the
the
front
end
team
is
going
to
be
gathering
with
the
verified
team,
we're
going
to
have
our
end
of
quarter
gathering
the
topic
is
going
to
be
about
availability,
dealing
with
availability
on
lovable
product
categories,
so
we're
going
to
be
sharing
tips
and
tricks
and
experiences
that
we've
had
to
deal
with
on
the
front
end
teams,
because
the
verify
is
also
dealing
with
that
lovable
problem,
we're
dealing
with
it
as
well.
The
pressure,
the
rolling
out
the
feature
flags.
C
C
A
I
actually
have
oh
okay.
Let
me
show.
A
No,
it's
okay,
it's
just
more
fyi,
but
I
just
wanted
to
share.
I
think,
like
thomas
is
already
aware
and
kai
as
well,
but
I
don't
think
you
andrei
and
michelle
you
were
not
aware.
A
So
I've
been
mapping
all
of
the
states
of
the
merge
widget
and
you
can
find
a
link
to
the
issue
there
and
the
next
steps
will
be
competitive
analysis
so,
basically
looking
at
what
our
competitors
are
doing,
so
how
github
handles
the
merge,
widgets
and
garrett
and
all
of
them,
and
and
then
designing
a
framework
or
coming
up
with
a
design
framework
that
is
scalable
and
that
could
serve
as
the
foundation
for
to
apply
the
similar
patterns
to
the
other
widgets.
A
A
But
right
now,
I'm
focusing
on
the
merge
widgets
the
merge
button,
because
it's
I
was
thinking
about
it
the
other
day
and
it's
probably
on
the
top
three
most
important
buttons
of
the
product
after
register
or
login.
You
know
and
maybe
commits-
or
something
like
that
after
that,
the
merge
button
is
is,
is
up
there,
so
we
we
need
to
make
it
lovable.
So
it's
more
of
an
fyi
and
take
a
look
if
you're
interested.
A
Are
you
aware
of
the
verify
effort
to
refactor
mergability
check
code?
I
think,
is
that
the
working
group
thing?
Yes?
Yes,
so
it's
yeah,
it's
more
or
less
the
same
thing
that
I'm
doing,
but
from
the
wax
perspective,
I
believe
that's
how
I'm
interpreting
it
yeah
thanks
for
linking
to
that
kai.
Do
you
want
to
voice
your
point.
B
Yeah
I'll
just
say,
I
have
also
seen
the
working
group
issue
thing,
and
I
think
you
know
my
perspective
is
that
as
the
group,
that
is
the
owners
of
the
merge
request
and
now
overtime,
we
should
be
sort
of
defining
and
owning
what,
if,
if
the
merge
button
and
merge
ability,
checks
and
those
things
were
going
to
be
refactored
as
the
group
that
will
ultimately
be
responsible
for
sort
of
how
that
ends
up
needing
to
be
maintained
or
dealt
with,
we
should
be
the
ones
sort
of
leading
that
and
was
certainly
supportive,
but
of
other
groups
wanting
to
contribute
to
that.
B
But
it
should
be
based
in
in
our
definition
of
what
we,
how
we
want
the
button
to
behave
and
what
we
want
the
states
to
do
and
what
data
we
want,
based
on
pedro's
findings
and
then
how
that
gets,
architected
and
the
back
end
and
front
end
should
be
a
something
that
we
we
agree
with
and
in
our
consistent
with,
and
not
necessarily
what
like.
The
other
group
wants
right
like
this
is
the
experience
that
we
own
and
it
is
okay
to
sort
of
dictate
backwards.
E
C
Or
something
no,
I
can't
see
here
under.
Can
you
hear
me
now.
E
C
E
C
Right
I
was
saying
that
this
is
going
to
be
a
topic
over
the
next
couple
of
weeks.
I've
already
reached
out
to
sam
beckham
the
front
end
manager.
I
already
gave
him
all
the
feedback
that,
apart
from
the
mergeability
checks,
there's
also
some
code
review
checks
that
we
do
dependencies
unresolved
threads,
so
they're
going
to
have
to
be
very
much.
C
They
can
work
on
their
part
of
the
mergibility
checks
and
have
that
feedback,
but
we
have
to
then
circle
back,
so
I
already
put
him
in
a
path
to
find
to
unify
all
these
people
pedro
vitica,
the
designer
from
this
side,
potentially
even
the
pms,
will
be
reached
out
so
they're
still
in
the
forming
stage
of
this
group,
whether
this
would
be
a
working
group
or
not,
but
I
agree
with
you
kai.
We
definitely
should
take
an
ownership
perspective
here.
B
Yeah,
I
think
that's
the
piece
to
be
clear
on
is
that
I
think
there
are
lots
of
checks
and
lots
of
data
that
we
want
displayed
like
pedro,
is
going
to
define
like
what
that.
What
the
ultimate
like
end
result
looks
like
right,
because
that
that
is
what
we
want
to
control
and
then
how
the
data
gets
there.
I
think
we
should
we,
as
in
code
review,
should
also
be
doing
that
and
then,
if
verify,
has
things
that
they
need
to
do
like
hey
verified.
B
This
is
how
you
do
it
versus
sort
of
like
a
verify
saying
this
is
how
we're
going
to
do
it
in
code
review
saying
this
is
how
we're
going
to
do
it,
because
there's
a
lot
of
things
that,
like
we're
doing
in
terms
of
refactoring
the
view
or
and
other
things
that
like
might
dictate
a
different
direction
than
what
it
looks
like
is:
maybe
the
right
choice
now
and
so
like
just
to
be
more
aware
of
that.