►
From YouTube: 2021-09-07 Code Review UX 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
I
think
the
plan
for
today
was
to
go
over
the
issue.
That's
linked
to
number
one.
I
will
say
I
have
not
participated
in
the
issue
yet
which
I
make
it
a
bit
more
challenge,
and
my
plan
was
to
do
that
this
morning
and
then
you
know
best
laid
plans.
So
I
think
we
could
still
start
here.
I
don't
know
what
the
best
way
to
sort
of
go
through
this
or
pedro.
A
If
you
want
to
sort
of
like
share
and
go
through
some
of
the
things
that
you
put
in
here
and
we
can
discuss
those
or
if
anyone
has
other
thoughts
about
about
what
to
to
look
at
or
do
here.
B
Yeah,
so
I
think
I
I
went
through
the
the
questions,
the
prompts
and
also
the
themes,
and
I
think
that
what
we
had
been
discussing
in
that
other
issue
and
in
the
recent
weeks
about
problem
areas
fits
very
well
with
what
is
being
asked
of
us
right
now,
and
I
kind
of
in
my
my
comment
there,
I
kind
of
tried
to
overlay
those
with
with
the
prompts
biggest
competitive
gaps,
upselling
opportunities,
lovable
experience
and
risk
velocities
and
churning
customers.
B
I
mean
I,
I
might
have
done
this
more
from
a
user
experience
standpoint
so,
for
example,
in
terms
of
risk
to
lost
deals
or
charging
customers.
For
me,
the
biggest
two
biggest
risks
are
performance
and
navigation
and
clutter
ui,
and
not
so
much
new
features.
B
So
it's
improving
what
we
already
have
not
enhancing
existing
features,
not
adding
new
features.
But
I
might
be
wrong
if,
if
there
is,
if
there
are
other
opportunities
or
if
we're
losing
deals,
because
of
we
don't
have,
I
mean
it's
likely
that
we're
losing
deals,
because
we
don't
have
feature
a
or
b.
But
how
big
is
that
risk?
And
if
there
is
it's
a
consistent
loss
due
to
a
specific
feature
that
we're
missing,
but
anyway
yeah
biggest
competitive
gaps,
I
think
again
performance
and
navigation
clarity,
ui.
B
We
also
have
the
commit
by
commit
code
review
to
cross
project,
merge
requests.
These
are
also
things
that
we've
been
that
customers
have
asked
for
and
yeah,
and
it's
something
that
we
could
fill
those
gaps.
Some
competitors
do
this
very
well,
there's
not
so
much
it's
something
that
people
have
been
asking
and
could
give
us
a
competitive
edge
and
then
to
put
us
on
par
with
other
competitors.
B
We
haven't
really
built
a
good
review
feature,
so
our
batch
comments
feature
and
we
could
add
more
value
to
it.
So
that's
another
opportunity,
yeah.
I
could
go
on
and
talk
about
these
other
things
that
I
wrote
here.
I
don't
know
if
someone
wants
to
stop
me
there
and
comment
or
ask
questions.
A
Do
you
think
commit
by
commit
and
cross
project?
Mrs,
are
also
probably
part
of
losing
customers
or
churn
or
lost
deals.
B
I
think
if
I
commit
yes
cross
project
mars,
I'm
not
sure
because
it
seems
like
a
more
specific
use
case
and
it's
something
that
you
can
maybe
go
around
with
some
tooling.
Perhaps,
and
I'm
not
aware
of
anyone
doing
this
particularly
well,
I
mean
anyone
another
tool.
I
meant.
B
And
and
so
yeah
probably
we're
losing
deals
because
of
this,
I
I
don't
know
how
big
those
losses
are
and
if
they
justify
us
looking
into
this
and
taking
focus
away
from
other
things
that
impact
all
of
all
of
gitlab,
basically
and
all
the
users
that
use
kid
like,
for
example,
performance
and
navigation
clarity.
Why
you
tell
me:
what
do
you
think.
A
Yeah,
I
would
agree
on
commit
by
commit,
I
know,
of
a
handful
of
lost
users.
Seeds,
customers,
because
of
it,
but
not
not
a
tremendous
amount,
and
it's
largely
not
like
commit
by
commit
explicitly.
It's
people
just
want
garrett
and
github
or
in
gitlab.
That's
not
what
they
want
like.
A
B
And
and
these
two
things
that
they
are
huge
and
or
could
become
huge
things
for
us
to
work
on,
so
I
also
added
a
question
here,
because
I'm
not
sure
and
and
the
issue
where
that
sarah
created,
I
interpreted
this
as
a
short-term
vision,
so
the
problems
would
be
solved
or
addressed
until
the
end
of
the
fiscal
year,
which
is
january
31st.
B
A
Direction
pages,
I
think,
typically
outline
like
a
grand
vision
and
then
explicit
work
that
takes
place
over
like
a
year
is
and
or
less
is
sort
of,
I
think
like
the
scope
of
a
direction
page,
but
then,
like
group
pages,
are
sort
of
a
new
thing
that
are
going
to
come
out
of
this
that
have
potentially
longer
time
frames.
I
think
stage
pages
and
section
pages
do
like
three
and
five-year
horizons.
A
So
if
you
think
that
this
will
roll
up
like,
I
think
explicitly,
you
could
say
like
let's
just
take
commit
by
commit
if
we
were
going
down
the
commit
by
commit
path,
I
don't
think
there's
an
expectation
that
that
entirety
of
that
vision
is
realized
in
a
year
or
by
the
end
of
the
fiscal
year.
I
think
the
expectation
is
that
it's
important
to
our
vision
and
something
that
we
would
embark
on,
but
it
would
roll
up
over
longer
periods
of
times
sort
of
as
you
cascade
it
upwards.
A
B
Okay,
yeah
and
then
upselling
opportunities
is
I,
as
I
discussed
previously,
approval
rules,
reviewers
and
code
owners.
I
think
it's
something
that
we
could
leverage
and
work
together
with
source
code
to
have
this.
You
know
just
a
better
experience
and
an
experience
that
you
can
more
easily
communicate
the
value
once
you
have
a
story
and
you
can
show
it
to
customers
and
they're
like
hey.
This
is
really
easy
to
manage.
It's
really
easy
to
use.
B
We
talked
about
also
the
relationship
between
approvals
and
reviewers
and
then
the
reviewer
suggestion
out
of
assignment
that
the
applied
machine
learning
group
is
working
on.
It's
also
another
thing,
but
I'm
not
sure
I
mean
this
is
more
right
now
more
in
their
part,
so
not
necessarily
inside
of
code
review,
although
we
will
have
to
inherit
whatever
they
do,
and
then
we
have
a
stake
here
in
terms
of
the
user
experience.
A
A
B
Okay,
yeah,
I
mean
we
don't
have
to
discuss
the
details
now,
so
I'm
I'm
okay
with
that.
I
don't
have
a
strong
opinion
at
the
moment.
I
just
mean
like.
Would
you.
A
Maybe
let
me
think,
if
you
think
about
like
code
review,
like
code
review,
has
very
few
paid
features
as
it
stands
today
and
very
few
free
things
that
you
could
turn
like,
you
could
add
more
value
to
to
turn
them
into
paid
features.
Sort
of,
although
we
have
is
really
like.
A
In
tech
we
sort
of
don't
even
own
approval
rules,
we
really
only
have
like
approval
rules,
I'm
not
even
now,
I'm
thinking
through
this-
I
don't
even
know
if
we
have
any
paid
features
in
code
review
and
it's
not
because
like
we
don't
have
paid
features.
It's
because,
like
I've
had
this
conversation
with
others
like
we
used
to
have
approval
rules
when
it
was
source
code
code
review
and
then
like
those
got
split,
and
so
we
lost
that
paid
feature.
A
If
you
think
about
like
the
things
that
compliance
group
works
on
where
they're
working
on
like
enforcement
across
groups
with
approval
rules
like
that
would
have
at
one
point
prior
to
the
compliance
group,
existing
been
paid
code,
review,
features
or
paid
source
code
features
on
review.
Similarly,
right,
like
smarter,
reviewer
selection
would
have
been
a
paid
code
review
feature
now.
It's
technically
belongs
to
like
the
applied
ml
group
and
so
like
it's
their
paid
feature,
not
our
page
feature,
and
so
it's
not
that
we
don't
have
paid
features.
A
It's
that,
like
anything
that
we
would
do
is
like.
Oh
every
time
we
like
get
to
the
point
of
paid
features.
Other
groups
sort
of
like
own
the
paid
surface
area,
whereas
this
is
like
the
one
I
guess
like
you're
you're
upselling
here
when
I
read
these
there's
not
like
you,
don't
have
like
two
or
three
ideas
here
you.
We
really
got
like
one
idea
around
approval
rules
and
reviewers
and
sort
of
like
making
that
experience
stronger.
A
But
it's
not
like
it's
not
like
we're
talking
about
approval
rules
reviewers
as
either
two
separate
things
or
we're
not
talking
about
some
other
like
unknown,
non-existent,
paid
feature.
That's
like
we
have
a
free
thing
in
the
product
and
if
we
spent
more
time
on
it,
we
could
make
that,
like
the
paid
feature.
B
You
know
I
don't
know
if
that's
clear
or
not
I
mean
there
could
be
other
opportunities.
These
are
the
ones
that
immediately
came
to
mind
as
affecting
directly
affecting
code
review,
without
using
anything
else
and
just
focusing
on
pure
the
pure
review
cycle
and
and
and
yeah
here.
I'm
I'm
not
necessarily
thinking
about
paid
features,
just
inside
of
korea
because,
as
you
said
like
these
affect
code
review
in
the
organization
structure,
they
ended
up
in
other
groups,
but
if
those
groups
didn't
exist,
it
would
fall
to
us
right.
B
So
it
was
just
a
matter
of
organization,
so
I
think
it's
worth
talking
about
these
and
even
if
it's
just
to
elevate
the
whole
experience,
because
in
the
end,
in
the
user
journey
and
through
the
user's
eyes,
they
don't
care
which
group
it
comes
from,
they
will
see
these
features
as
code
review
features,
atta
features
attached
to
the
concept
and
the
activity
of
reviewing
code.
B
So
they
don't
care
about
that.
I
think
it's
different
when
you
consider
than
ci
and
automated
review
systems
that
you
know
tell
you
hey.
This
is
a
code
quality
issue.
This
is
a
security
issue
or
the
pipeline
is
failing.
That
is
they
also
review
code,
but
it's,
I
think
it's
a
different
mental
model
here.
B
I
I
think
users
consider
this
to
be
part
of
the
code
review
activity
and
there
may
be
other,
as
I
said,
other
upselling
opportunities,
but
I
I
haven't
spent
a
lot
of
time
thinking
about
them,
because
I
also
think
that,
because
we
have
these
groups
that
can
help
us
with
these
upselling
opportunities,
I'm
much
more
comfortable
with
spending
time
on
the
lovable
experience
and
and
addressing
the
performance
and
and
just
the
current
ux,
then
new
features
and
that's
something
that
we
that
we
talked
in
the
past
as
well.
B
Thanks
yeah
and
then
level
experience.
B
And-
and
here
I'm
just
thinking
about
what
things
we
can
do,
that
will
impact
the
biggest
audience
of
code
review
and
I
think
what
annabelle
highlighted
in
another
comment
in
this
issue
of
understanding
how
changes
are
connected
across
the
repository
and
how
changes
in
this
file
are
related
to
changes.
It
could
affect
other
files
with
native
code
intelligence,
for
example,
or
allowing
people
to
browse
the
repository
inside
of
a
merge
request
without
having
to
go
to
the
repository
view
or
without
having
to
clone
and
check
out
the
branch
locally.
B
B
A
B
Code
extension,
it's
really
good
because
we're
attacking
attacking
is
a
strong
verb,
but
we're
we're
connecting
with
users
at
the
touch
points
and
where
that
they
already
know
and
where
they're
always
in
and
on
the
other
side.
I
think
we
could
do
the
same
thing
so
vs
code
we're
bringing
gitlab
into
vs
code
and
from
git
lab
the
gitlab
site.
I
think
an
an
experience
that
can
be
more
reliable
is
to
bring
more
of
the
ide
into
gitlab
and
into
the
code
review
experience.
B
Then
what
I
already
mentioned
make
mergers
ui
more
organized
in
the
experience
and
adding
value
to
our
batch
comments.
I
think
all
of
these
are
you
know,
I'm
repeating
myself
a
little
bit,
because
all
of
these
are
kind
of
related.
A
A
A
Does
seem
in
line
sort
of
with
how
we've
been
thinking
and
talking
for
for
many
months
now,
so
it
doesn't
nothing.
Nothing
seems
super
surprising
in
there,
which
I
guess
is
both
good
and
maybe
not
quite
the
point
of
the
exercise.
But
I
guess
it's
good.
B
I
I
think
I
think
it
goes
to
show
that
we've
been
thinking
about
this
a
lot
I
don't
know
about
other
groups,
I
looked
at
mural
and
it
seemed
like
editor
has
a
hard
time
because
they
have
so
many
categories
in
different
categories.
You
know
wiki
snippets
web
id.
B
It's
it's
it's
a
lot,
so
I
think
they
might
have
a
harder
time
connecting
all
of
that
because
they
have
such
a
big
surface
area.
Yeah.
I
don't
know
I.
This
is
my
opinion
and-
and
you
said
that
what
you
just
said
like
it
seems
like
there
are
no
surprises.
I
I
then
interpret
that
as
you
think,
more
or
less
along
the
same
lines
and
that's,
I
think,
that's
that's
good.
A
Yeah,
nothing,
there
is
surprising
and
I
would
sort
of
agree
that
and
we
you're
right.
We
had
this
issue
a
month
or
two
ago,
where
we
sort
of
nailed
down
that
we
were
going
to
think
about
user
experience
and
not
look
at
sort
of
look
at
these
other
things,
and
so
I
think
that's
where
our
head
has
been
pretty
consistently
for
a
while
too
so,
and
that
makes
sense.
A
You
did
have
like
a
last
question
in
here
about
problem
statements,
because
one
of
the
one
of
the
outputs
being
looked
for
is
opportunity
canvases
and
like
what
I
was
thinking
for
those.
I
think
one
that
I'd
like
to
do-
and
I
because
I
am
interested,
is
either
validating
a
another
editor
to
support
like
a
local,
ide
or
or
investing
in
the
command
line,
get
lab
tool
as
well
either.
A
One
of
those
is
high
on
my
personal
interest
lists,
but
I
don't
have
another
good
problem,
so
that's
one
of
the
ones
that
I
want
to
do
and
we
sort
of
started
talking
about
that
with
jetbrains
and
so
I'll.
Add
that
as
a
comment
there
that
I
think
that's
a
an
area
that
we
should
probably
explore.
I
think
we've
reached
a
interesting
maturity
point
with
vs
code
that
we
can
continue
to
optimize
for
sort
of
little
things,
but
we're.
A
We're
beholden
to
other
groups
now,
which
is
one
of
the
problems,
that
the
extensions
will
always
have
we're
missing
support
for
things
that
we
want
to
do
in
vs
code
and
we
need
other
groups
to
allocate
engineers
to
build
apis
and
do
all
these
other
things
and
unless
they
they
are
willing
to
do
that.
Then
that's
there's
not
much.
We
can
do
to
move
more
of
gitlab
into
that
space,
so
so
it
sort
of
seems
like
an
opportunity
to
go.
Do.
A
So
that's
one
I
think
the
other
one
is
and
then
I
yeah,
I
don't
know
what
I
would
do
for
another
one.
I
think
we,
it's
probably
something
in
the
merge
request
space
that
we
need
to
figure
out,
but
I
don't
because
we
haven't
been
looking
about
features.
I
haven't
been
thinking
about
problems
necessary
to
go
solve
that
we
haven't
already
done
opportunity
canvases
for
or
or
looked
at
sort
of
in
depth.
A
A
I
think
it's
adoption,
I
think
adoption
is
still
the
biggest
hurdle.
The
extension
has,
if
you
think,
about
sort
of
sort
of
involved
right
for
a
developer
to
even
find
out
it
exists
and
then
like
and
then
set
it
up.
I
think
once
someone
finds
out
it
exists,
they
set
it
up
and
like
then,
it's
installed
in
their
vs
code
and
they
sort
of
move
on
with
their
life
and
like
if
they
click
on
to
it
and
use
a
feature.
A
Then
we
we
know
we've
made
requests
and
we
get
that
information
like
the
blue
bar
at
the
bottom
gives
a
bunch
of
get
lab
status
as
soon
as
you
sort
of
install
and
activate
the
extension.
So,
but
I
think
getting
people
to
even
become
aware
of
it
is
where
the
challenge
is
right.
Now,
like
adoption,
is
just
hard
and
slow
and
we
don't
market.
A
A
I
don't
think
we
have
like
partners
or
sales
people
that
promote
it,
because
it's
not
sort
of
the
primary
flow
that
they're
selling
they're
trying
to
sell
git
lab
is
like
an
integrated
tool,
and
this
is
supportive,
but
counter.
Just
to
some
of
that
right,
there
is
a.
There
is
a
bit
of
a
disconnect
in
terms
of
like
strategy
in
terms
of
being
in
in
local
ids,
but
yeah.
I
think
it's
it's
to
me.
It's
an
adoption
issue.
A
If
you
look
at
sort
of
the
ramp
of
the
male
graphs
and
stuff,
it
seems
like
dot.
Com
has,
I
want
to
say
plateaued,
but
it
isn't
gaining
very
quickly
and
if
you
think
about
how
many
users
are
on
gitlab.com
and
then
you
think
about
what
most
research
suggests
that
there's
you
know,
50
of
market
share
exist
in
vs
code
like
we
should
have.
A
You
know
tens
of
thousands,
hundreds
of
thousands
of
more
users
than
there
are
on
the
extension.
But
if
I
can't
ever
tell
you
that
it
exists,
then
then
you
don't
get
it,
and
then
I
don't
get
you
as
a
user,
and
so
I
think
that's
where.
A
I
don't
think
we're
missing
features,
I
think
there's
enough
in
there
that
provides
value
to
a
user,
and
it's
not
like
the
the
addition
of
one
extension
to
your
vs
code
is
sort
of
like
detrimental
to
your
overall
vs
code
experience.
So
you're
not
willing
to
do
it.
I
think
it's
you
have
to
know
it's
there
and
think
that,
like
you
know
and
get
it
that
way,.
B
Yeah,
I
I
wonder
if
it's
in
that
case,
I,
the
vs
code,
is
vs
code.
The
biggest
idea
in
terms
of
market
share.
A
As
an
individual
ide,
it
is
largely
regarded
yes
to
have
the
biggest
market
share.
It
gets
complicated
because
jetbrains
ides
all
get
reported
separately,
but
they
share
a
common
extension
framework.
So
from
an
integrator
perspective
you
could
aggregate
all
of
them
and
then
it
becomes
fairly
comparable,
but
most
data
when
I've
looked
at.
It
shows
vs
code
at
over
50
percent.
So,
like
you
have
to
assume
it's
sort
of
the
largest,
even
if
you
aggregated
all
of
the
jet
brains.
B
And
so
if
we
haven't
solved
vs
code,
I
mean
from
a
feature
perspective.
Yes,
but
not
from
an
adoption
perspective.
We
haven't
solved
vs
code
yeah,
I'm
wondering
if
going
for
jetbrains
couldn't
just
you
know,
dilute
our
already
scarce
resources.
B
A
Attention
yeah,
it's
an
interesting
question.
I
largely
think
about
adoption
at
this
point
being
outside
of
our
group
and
engineering.
It
almost
feels
like
something
that,
like
could
be
driven
with
marketing
and
sales
and
tams
and
product
versus,
like
taking
away
capacity
out
of
sort
of
the
group's
throughput
and
engineering
efforts.
Right.
I
don't
think
adoption
is
in
this
case
is
like
the
onboarding
is
too
hard
or
we
need
to
fix
xyz
to
get
sort
of
those
triggers
and
vs
code
happening.
I
think
the
adoption
is
I'd
say
it's
more
broadly,
like
awareness.
B
Yeah
yeah
for
sure
yeah
and
I
think
it
goes
hand
in
hand
right.
So
if
you
don't
have
adoption
much
like
you
know,
dog
footing
at
gitlab,
if
people
don't
use
it,
it's
difficult
for
us
to
know
what
we
need
to
improve.
What
we
need
to
work
on
next,
if
it's
valuable
or
not,
we
don't
have
critical
mass.
So
yeah,
I
don't
know.
B
I
don't
know,
but
anyway,
we're
over
time,
but
about
the
crafting
problem
statements
for
for
tomorrow.
If
you
want,
and
if
you're
able
to
work
on
that
today,
I
can
then
look
at
the
mural
and
and
provide
some
feedback
if
you'd
like.
A
Yeah
I'll,
that's
my
plan
for
the
rest
of
the
day
is
to
to
sort
of
work
on
this
stuff
and
so
I'll
make
sure
that
you
got
a
comment
before
I'm
out
in
a
day
and
then
you
can
look
at
in
the
morning
tomorrow.
A
B
Awesome
good
talking
with
you
kai
and
keep
growing
that
beer.