►
From YouTube: 2020-12-02 Create:Code Review Weekly Sync
Description
Weekly Prod/Eng/UX Sync for the Code Review Group
A
If
you
want
to
participate
last
day
to
sign
up
is
the
seventh
and
then
there's
some
other
details
if
you
click
the
link
and
go
to
the
forum,
there's
a
bunch
of
details,
but
I
added
a
few
to
that.
So
take
a
look.
I
think
it'll
be
fun
if
you're
interested
and
that's
it
the
first
one
on
the
block
for
discussion
is
instrumentation
for
code
review.
A
That
is
how
other
groups
do
this.
I
will
say
it's
a
little
bit
gamey
in
the
sense
that
it's
an
easy
way
to
inflate
the
account
of
your
users,
but
that's
the
metric
product
uses,
so
the
downside
to
all
of
our
telemetry
stuff
we
get
lab.
Is
it
takes
months
and
months
to
get
data
because
it's
like
a
90-day?
A
Well,
the
first
of
it
is.
Is
it's
like
70
days
from
the
time
you
release
to
the
first
time,
you'll
get
data
back
into
the
data
warehouse
from
self-managed,
and
then
you
bundle
that
with
an
additional
like
60
days
for
on
average,
people
are
within
three
releases,
so
you
have
to
like
wait
three
releases
from
the
time:
you've
gotten
it
plus
that
70..
So
it's
like
120
100
days
before
you
get
data.
A
What
do
we
need
to
do
to
get
time
on
both
of
those
efforts
to
make
sure
that
all
we
have
all
the
issues
in
place
and
that
because
this
will
like
even
on
the
vs
code,
like
all
the
back-end
code,
that's
going
to
need
to
go
into
gitlab
is
more
than
just
tomos
right.
Other
people
are
going
to
have
to
do
that.
B
A
Yeah,
I
think
that's
part
of
it.
I
would
say
the
question
that
I
would
have
if
some
of
these
are
instrumented
would
my
follow-up,
my
immediate
follow-up
is
going
to
be.
Are
they
instrumented
the
same
across
everything
and
measuring
the
same?
So
that
way
we
can
because
what
what
is
not
helpful
is
like.
Oh,
we
have
this
one
way
to
track
suggestions
and
it's
just
a
counter
and
it
counts
everybody
that
adds
a
suggestion.
What
we
need
is
the
like,
deduped
mal,
red
shll,
counter
sort
of
for
all
of
this.
A
That
way,
you
can
that
allows
you
to
say
this.
Specific
action
had
x
number
of
users
and
then
across
the
collection
of
the
actions
that
are
all
in
the
same
category.
Here's
the
like
deduped
list
of
users.
So
now
I
can
say
that
there
was
like
500
people
that
added
a
suggestion
and
and
total
code
review
had
10
000
users
or
something
that's
the
way
that
it
had.
A
C
Yeah
I
was
thinking
I
was
going
down
the
list
and
I
don't
I
don't
see
any
of
these.
That
is
front-end
only
because
if
they
are
front-end
only
then
we
need
to
implement
it
on
the
front
end
and
if
I'm
not
mistaken,
I'm
not
entirely
sure
how
all
the
instrumentation
has
been
done
so
far
because,
like
you
said
it's
mostly
back
end,
it's
basically
instrumentation
have
been
taken
care
of
on
the
back
and
for
these
now,
what
we're
looking
for
counters?
B
A
C
Now
I
wonder
if
there's
any
way
for
us
to
just
like,
I
don't
know
piggyback
on
those
on
that
code
that
generates
that
system
nodes
and
just
track
those,
because
if
you
track
the
system
nodes,
you
track
the
actions
and
I'll.
Actually
that
raises
another
question:
is:
can
we
go
and
backtrack
this
but
not
backtrack
this,
but
the
generator
is
backfilled?
Thank
you,
yeah
yeah,
I
don't
know
data
migration
or
something.
A
C
B
Yeah,
I
even
though
we
are
the
ones
who
implement
a
lot
of
the
usage
being
and
instrumentation
issues-
I
don't
know
where
they
end
up
or
how
to
get
them
or
how
they're
used.
So
maybe
daniel
would
be
a
really
good
help
there
for
me
to
understand
those
things
but
yeah
any
any
guidance
there.
Probably.
What
I
will
do,
though,
is
just
go
through
all
of
the
recent
usage
pink
stuff
and
see
how
they
were
done.
C
A
A
A
Yeah,
I
think
the
plan
would
be,
and
I
don't
know
this
is
this
is
where
it
sort
of
gets
complicated.
The
vs
code
extension
sends
its
own
user
agent,
so
we
know
when
it
makes
a
request,
and
so
you
could
look
for
that
sort
of
in
api
calls
and
then
put
a
lot
basically
count,
and
then
you
just
count
that
user
agent.
That
request,
because
it
came
with
that
user
agent
and
you
keep
a
a
total
count
in
git
lab
of
those,
and
then
you
report
that
total
count
as
part
of
usage.
Big
data.
A
C
The
alternative
would
be
to
intercept
them
on
the
on
the
vs
code
site,
the
vs
code
extension
site
and
do
a
double
request,
like
a
second
request
to
track
it,
which
is
not
ideal
but
might
be
a
way
around
us.
So
I
I
think
it's
just
a
matter
of
like
keeping
that
discussion
evolving.
I'm
I'm
looking
there's
already
a
bit
a
bunch
of
it
I'll
keep
an
eye
on
that
and
see.
If
we
can.
A
Contribute
yeah
thanks.
I
appreciate
it,
I
think
yeah,
I
know
the
telemetry
stuff
is
not
fun
and
we
re.
We
did
it
like
five
times
over
an
editor
because
they
kept
changing
as
a
moving
target.
So
I
know
it's
not
fun,
but
I'm
hoping
I'm
hoping
if
we
get
this
in
as
like
a
baseline,
then
sort
of
everything
new
we
do.
We
now
just
know
that
it
has
to
follow
this
like
reference
implementation
and
we
keep
it'll,
be
much
simpler,
sort
of
moving
forward
for
new
features.
A
B
C
So
maybe
maybe
summarizing
the
action
points
kai.
If
you
could
get
those
dashboards
to
michelle,
I
feel
like
that's
the
first
start.
Then
michelle
can
can.
Will
you
be
able
to
create
the
issues
for
13.8?
Because
that's
I
think,
that's
the
pressure
like
to
have
issues
prepared
for
thirteen
eight
in
line
to
be
implemented.
B
B
A
C
No
objections.
What
I
think
I'll
do
is
I'll
I'll
toggle
the
flag
on
again
for
those
projects,
our
gate,
labor,
git,
lab
and
gitlab
con
ww
and
being
the
people
that
reported
the
problems
to
check
immediately
if
they
see
something
out
of
the
ordinary
and
we'll
know
right
away,
if
they
do
okay
I'll
do
that
today,.
C
A
B
I
saw
that
too.
I
think
there
is
a
follow-up,
but
I
wanna,
I
wanna
wait
for
igor
to
reply
and
I
think
patrick
can
probably
jump
in
there
too,
because
I
think
part
of
this
is
the
work
that
patrick
did
in
order
to
optimize
storage
he's
deleting
all
of
all
of
the
closed,
mrs,
after
a
certain
amount
of
time.
So
there
probably
is
a
follow-up,
but
we'll
just
see.
C
Okay,
now
that
you're
talking
about
yeah
that
switch
between
what
was
reviewed
to
a
different
kind
of
diff
sounds
like
it
can
cause
some
trouble,
especially
if
like
when
we
merge
something.
We
want
to
go
back
to
the
comments
we
might
might
want
to
go
back
to
the
comments
and
we
can
link
to
a
comment.
C
A
A
C
All
right
can
you
move
on
to
the
next
one,
I'm
good,
all
right
so
doing
a
bit
of
a
middle
of
the
milestone
check-in.
I
took
a
look
we're
at
oh
gosh.
I
didn't
put
it
here,
we're
at
50,
wow
50
elapsed
of
the
milestone
like
to
the
mark,
specifically
50
and
the
front
end.
As
it
looks
it's
at
an
estimated
60
completion.
C
It
looks
like
we
have
a
big
bulk
of
work
still
in
dev,
so
we
have
10
issues
currently
in
dev
and
with
four
engineers,
that's
kind
of
like
two
per
engineer,
a
little
bit
more
than
that,
so
it
feels
like
we
should
definitely
get
make
sure
that
these
get
into
conclusion
and
from
what
I
looked
from
the
the
looks
of
it.
Thomas
was
on
vacation
last
week.
So
we
have
this
push
now
to
do
the
the
big
test
that
he
has
to
mark
the
files.
That's
reviewed!
C
C
C
C
This
is
in
a
way
if
you
want
to
keep
the
listing
simple,
based
on
the
order
of
the
back
end.
If
we
don't
want
to
keep
the
that
simple,
then
the
backend
needs
to
change
the
order
that
is
giving
the
files,
depending
on
the
file
tree
mode,
the
file
browser
mode.
That
complicates
a
little
bit
the
solution.
C
C
He
might
be
a
little
tight
to
get
this
done
by
next
wednesday,
and
even
if
so,
we
might
have
if
it
slips
we'll
find
someone
to
tackle
this,
whether
it's
13,
8
or
late,
13
7.,
we'll
see
if
we
have,
we
can
have
phil
jump
on
it,
but
just
wanted
to
be
aware
of
that.
There's
a
risk
of
that
slipping
summarizing.
B
A
C
C
So
moving
on
to
my
next
point,
we
have
five
minutes.
This
is
about
our
discussion
in
slack
that
you
opened
up
about
the
graphql
on
the
mergerquest
widget.
I
chatted
with
phil
today
and
basically
the
biggest
question
that
we
have
right
now
is:
where
is
the
line
where
we
can
turn
this
on?
We
don't
have
a
decisive
decision
on
this,
but
I
can
tell
you
that
the
the
situation
is
this
if
we
turn
it
on
right
now,
there
are
some
data
that
was
moved
over
from
the
rest
endpoint
to
the
graphql
queries.
C
They
were
not
removed
yet
so
I
feel
like
if
we
turn
it
on
right
now
we
have
the
impact
of
having
duplicated
data
being
loaded,
both
on
the
back,
both
on
the
rest
and
point
and
on
the
graphql
endpoint.
So,
there's
nothing
really
stopping
us
from
enabling
it
right
now,
except
this
wasteful
data
request.
C
Okay,
now,
ideally
to
do
this
properly
to
not
leave
like
stale
data
under
those
requests.
When
we
roll
this
out,
we'll
be
removing
the
code
from
the
rest
endpoints.
This
could
be
just
putting
the
inclusion
of
the
data
in
the
rest
endpoint
behind
that
feature
flag,
because
that
endpoint
is
specifically
for
the
widget.
It's
not
an
api
endpoint,
so
I
feel
like
we're.
Definitely
okay
in
customizing
that
so
that'll
be
my
plan
like
schedule,
an
issue
to
move
the
code.
C
In
the
rest,
the
data
in
the
rest
endpoint
behind
the
feature
flag
so
that,
if
it's
off
so
if
it's
on
the
graphql,
it
doesn't
return
that
on
the
rest,
if
it's
off,
then
it
returns
that,
on
the
rest,
that'd
be
my
suggestion
to
roll
it
out,
and
we
can.
We
can
start
doing
that
in
thirteen
eight
there's,
no,
nothing
blocking
us
there.
The
other
thing
I
wanted
to
mention
is
like
the
blockers
on
the
verify
side
and
all
that
I
from
what
I
understand
they
have
access
to
the
to
the
state.
C
C
I
feel
like
what
they're
talking
about
if
they're
relying
on
the
data
coming
from
the
graphql
endpoint,
they
will
only
be
able
to
use
that
if
that
flag
is
on,
but
I
I
think
we
should
roll
it
out
as
soon
as
regardless
of
that,
so
we'll
unblock
them.
Regardless
of
that
so
question,
I
wanted
to
get
your
feedback
on
the
plan
of
the
rollout
in
particular.
Does
that
sound
good.
A
C
So
so
the
the
the
the
work
that
we're
doing
on
migrating
states
to
graphql
is
phil
is
handling
that,
in
particular,
so
by
the
time
that
we're
moving
them
out,
they'll
already
be
using
the
graphql.
If
the
feature
flag
is
on
the
reason
why
it
complicates
the
rest
standpoint
is
we
can't
just
remove
them,
because
if
you
turn
off
the
feature
flag,
then
we'll
go
back
to
rest
standpoint.
So
we
need
to
have
the
data
there.
C
A
A
C
Yeah,
okay,
I
want
to
talk
to
them
to
make
sure
they
clarify
that
whether
they're
fully
fully
blocked
or
they
just
they
want
to.
They
don't
want
to
get
messing
with
that
part
until
we're
done
kind
of
thing,
but
I
don't
think
technically
they
are
blocked.
I
talked
to
phil
today
and
he
doesn't
have
the,
but
I'm
going
to
clarify
that
with
sam.
Make
sure
that
we
understand
that,
regardless
of
that,
we
should
definitely
roll
it
out
as
soon
as
we
possibly
can
so.
A
Yeah
we
should
roll
it
out
as
soon
as
we
can.
I
guess
the
with
them
being
blocked
it
sort
of
then
it
sounds
like
they
want
to
change
the
way.
Information
comes
back
to
the
widget
that,
like
defines
how
the
merge
button
knows
about
what's
wrong,
which
then
blocks
us
on
dependent.
Mrs
moving
that
error
message
closer
to
the
merge
so
like
all
of
it
is
sort
of
like
now
in
this
influx
very,
very
unclear
dependency
chain,
and
I
think
that's
the
piece.
That's
that
I
want
to
get
ahead
of
it's
like.
B
A
B
A
C
Okay,
so
we'll
prepare
an
issue
to
roll
this
out
and
I'll
aim
it
at
13
8,
and
also
discuss
it
with
sam
to
make
sure
that
we
clarify
the
blockage
to
your
other
questions
of
other
things
that
are
interdependent.
We
were
discussing
and
there's
still
a
thing
with
the
merge
requests
widget,
which
we
don't
really
have
a
clear
owner,
even
though
we
see
it
as
code
review.
C
This
particular
thing
about
clarifying
the
merge
button.
Now
it's
in
verify,
but
in
their
mockup
only
one
of
the
only
the
error.
Only
one
of
the
error
messages
is
verified.
The
other
is
source.
It's
called
code
review,
it's
kind
of
like
this
weird
gray
area,
so
we
definitely
need
to
yeah
collaborate
well
here,
so
I'm
happy
that
you're
in
you're
at
least
engaging
with
the
verify
there.