►
From YouTube: 2021-09-07 Create:Code Review UX Weekly
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.
B
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
A
B
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
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
A
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
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
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
A
A
B
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
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
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
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
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.