►
From YouTube: 2022-03-08 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
All
right
so
number
two
on
the
agenda
was
just
a
feedback
thread
that
I
wanted
to
link
and
I'm
gonna
refrain
from
mentioning.
But
I
think
it's
a
good
place
for
us
to
look.
I
think
it's
from
a.
A
I
am
I'm
not
sure
if
I'm
happy
or
frustrated
or
what
about
the
feature
being
so
so
positively
received
with,
like
so
much
commotion
and
noise
and
sort
of
like
social
action
around
it.
It
it's
sort
of
mind-blowing
to
me,
but
I
think
that
sort
of
speaks
to
like
a
different
awareness
in
general
about
git
lab
sort
of
thing
versus
the
feature
in
general.
A
But
I
think
there's
things
we
can
learn
about
that
feature,
and
so
it's
obviously
a
good
way
for
us
to
to
get
more
information
and
insight
into
how
people
are
perceiving
it
in
other
places.
So
I
want
to
make
sure
we
saw
so
we
could
take
a
look
and
animal
thanks
for
adding
a
bunch
of
other
ideas
and
yeah.
We
can
look
for
issues
and
try
and
link
them
all
up
and
see
what
we've
got
or
don't
have
or
what's
missing
and
what's
not
and
then
go
from
there.
B
Yeah,
do
we
have
so?
I
was
surprised
too,
because
I
didn't
realize
people
liked
it
so
much.
I
thought
it
was
kind
of
only
useful
for
really
large,
mrs
and
after
watching
so
many
of
our
internal
users.
Reviewing
word
requests.
I
don't
remember
seeing
that
open
very
much.
I
could
be
wrong.
I
just
don't
remember:
do
we
have
data
on
how
many
people
use
it
or
have
it
open,
and
I
can't
check
this
anymore,
because
snowplow
debugger
extension
will
not
work.
I
have
uninstalled
everything
I
have
reinstalled
chrome.
I
restarted
my
computer.
B
I've
tried
it
on
firefox.
I've
screen
shared
with
two
people
to
figure
out
why
I
can't
get
that
that
extension
to
work,
it's
it's
just
so
classic.
This
would
happen
to
me,
but
I
don't
know
I'm
gonna
blame
whatever
our
like.
What
is
this?
That
little
spyware
thing?
We
have
sentinel,
oh
yeah,
I
don't
know
anyway.
A
A
A
A
No,
I
don't
so
I
I
don't
think
it's
instrumented,
it's
not
in
the
big
like
instrumentation
epic
listed
or
something
and
it's
not
on
the
mail
dashboard.
So
it
might
be.
A
Not
the
look,
I
don't
know
if
it
got
instrumented
like
via
like
sas
and
snowplow
only,
but
we
can
look
around
and
see
and
then
yeah.
It
would
help
to
know,
because
I
I
think
people
who
use
it
are
sort
of
reliant
on
it
and
I
think
people
who
don't
use
it
sort
of
don't
don't
use
it
and
don't
notice.
So
maybe
that's
just
where
it
is.
A
All
right,
let's
talk
about
number
three,
so
number
three,
which
thanks
for
bringing
this
here
annabelle.
I
pinned
you
on
an
issue
we
had
spoken
weeks
ago
about
auth
checks
on
uploads
and
how
we
were
going
to
enforce,
authentication
and.
A
The
context
here
is
that
we
rolled
this
out
and
we
got
to
like
10
or
15
percent
on
the
rollout
and
support
started,
getting
feedback
that
things
were
broken,
so
we
didn't
even
make
it
very
far
and
the
broken
pieces
are
in
service
desk
and
this
gets
complicated
because
service
desk
by
design
the
people
that
you
are
emailing
do
not
have
git
lab
accounts
right
because
it's
like
zendesk
sort
of
in
that
help
desk
nature,
and
so
by
design
those
people
don't
have
accounts
and
therefore
they
cannot
authenticate
to
the
uploads,
even
if
you
wanted
them
to,
and
so
there's
literally
nothing
that
we
can
do
about
it.
A
It's
not
like,
we
can
say:
oh
you
have
to
be
logged
in,
you
have
to
go
to
it
like
there's
nothing
for
them
to
go
to,
and
so
in
the
thread
that
I
linked
you
to
up
above,
we
sort
of
there
was
a
bit
of
a
conversation.
There
was
some
more
conversation
in
slack,
so
I
can
find
that
slack
thread,
but
the
sort
of
the
crux
is
we
could
go
down
a
path
and
like
build
logic,
to
account
for
service
desk
and
there's
some
upcoming
features
that
might
make
that
possible.
A
A
To
solve
the
pain
for
people
who
have
uploads
that
they
don't
want
to
be
public
to
to
allow
them
to
prevent
that
and
sort
of
like
send
it
down
an
authenticated
path.
And
so
that's
that
is
sort
of
the
backstory
in
where
we're
at
on
this.
So
I'll,
stop
there
and
then
see
if
that
helps
clear
it
up
or
if
you've
got
more
questions.
B
Yeah,
that
makes
sense,
and
so
I'm
not
really
sure
how
service
desk
and
how
that
works
and
how
companies
use
the
service
desk
and
zendesk
and
stuff
like
that
in
specifics.
Is
it
completely
unreasonable?
This
might
be
like
the
worst
question
ever
it's
completely
unreasonable
to
ask
them
to
have
gitlab
accounts
right.
A
Desk
yeah,
I
don't
think
so
I
think
that's
are
you
familiar
with
like,
like
support
ticketing
systems
at
all,
like
familiarity
with
like
using
being
a
like
someone
who
sends
a
submits
a
support
ticket.
A
A
Yeah
like
if
you
submit
support
tickets
right,
like
you
typically
do
that
via
email
and
then
in
the
case
of
like
zendesk,
which
is
what
we
use
for
support.
Our
agents
have
a
portal
that
they
log
into
like
you
can.
I
think
you
can
probably
log
into
zendesk
right
and
see
our
customers
tickets,
but
those
customers
can't
generally
log
into
zendesk,
although
in
some
cases
they
can,
but
they
can't
generally
log
into
zendesk
and
like
deal
with
that
and
respond
there.
A
B
A
A
Yes,
it
relies
on
a
feature:
that's
called
email,
participants
and
email
participants
as
a
feature
does
not
exist
yet
like
it's
there
and
it's
feature
flagged
with.
They
haven't
widely
rolled
it
out,
and
so
I
think,
you're.
A
I
think
we
could
sit
and
wait
and
sort
of
see
how
all
that
plays
out,
but
I
think
there's
a
lot
of
unknowns
with
sort
of
what
the
impact
to
email
participants
is
and
largely
that
feature
and
looked
is
geared
around
the
ability
to
basically
add
someone
to
an
issue
by
using
their
email
address
versus
like
if
they
didn't
have
a
gitlab
account
it'd
be
like
a
way
to
like
add
random
people
to
issues
that
don't
necessarily
have
gitlab
accounts.
A
B
Okay,
so
plan
going
forward
setting
at
the
group
level
here
for
protecting
or
for
requiring
authentication
for
images
uploads
and
also
reverting
the
revert
of
the
community
contribution,
or
is
that
kind
of
still
tabled
for
now?.
A
I
don't
think
we'd
revert
the
revert,
I
think
what
it
would
do
is
basically
design
the
path
and
place
and
framework
for
diffs
and
how
we
want
to
do
that.
The
dis
one
was
like
project
level
only.
A
It
was
a
setting
under
visibility,
which
I
don't
maybe
that's
where
we
ultimately
want
to
put
these,
but
I
don't
know
so
I
think
this
is
like
a.
A
We
will
do
the
image
one
and
then,
depending
on
the
lift,
we'll
contribute
the
diff
one,
or
it
at
least
gives
a
path
for
the
diff
one,
and
I
think
like
doing
this
from
the
beginning
of
group
level
and
project
level
and
making
sure
we
cascade
is
sort
of
key
to
making
sure
we
get
it
right
versus
having
to
like
try
and
take
something
back
up
and
cascade
it
down
or
or
the
other
way
so
yeah.
I
don't
think
it
reverts
the
revert.
A
It
clarifies
our
stance
on
a
setting
or
no
setting,
which
is
what
we
had
said
to
begin
with.
We
said
like
the
goal
was
no
setting.
A
A
I
think
the
ux
asks
so
like
the
as
specific
for
you
is
sort
of
like,
and
I
think
potentially
collaborate
with
tori
is
sort
of.
Where
does
this
setting
go.
B
Okay,
great
yeah,
that
all
makes
sense
I'll
think
about
that.
Where
this
this
setting
should
go
so
we're
not
thinking
about
the
the
diffs
at
all
for
this
milestone
or
even
next,
it's
it's
sort
of.
A
I
would
account
for
them
in
thinking
about
like
what
this
is
so
like.
If
you,
if
it's
a
new
setting
under
somewhere,
that's
like,
I
would
account
for
both
of
those
being
there,
and
I
would
account
for
both
of
them
being
in
the
project
wherever
we
put
them,
but
from
an
implementation
standpoint
we'll
do
one.
We
won't
do
both
if
that
makes
sense,
but
it
unless,
for
some
reason
we
think
that
the
settings
would
go
in
wildly
different
places,
but
I
think
it
seems
conceivable
that
they'd
go
in
very
similar
spots.
B
Would
they
and
I
haven't
looked
into
it
again-
I'm
just
just
talking:
would
it
make
sense
to
group
them
together
or
do
you
think
they
should
be
separate
like
never
show
dips
in
emails
and
also
authenticate
for
images.
A
I
think
they're
different
and
I
think,
they're
different,
based
on
some
of
the
feedback
we
had
seen-
and
this
is
I
it
sort
of
seemed
like
we
were
going
to
get
forced
into
a
setting
either
way
because
internal
instances
to
gitlab,
don't
necessarily
they
might
be
private,
because
they're
like
offline
or
they're,
behind
a
firewall
and
you
can't
access
them
and
so,
like
the
instance
is
private,
but
the
projects
are
public,
even
though
they
sort
of
don't
want
things
going
in
different
places,
so,
like
the
private
private,
wouldn't
have
necessarily
cascaded
to
those,
and
so
those
people
might
want
to
toggle.
A
This
on
diffs
is
similar,
we're
seeing
a
lot
of
feedback
in
the
diff
thread
from
pubset
customers
that
have
certain
requirements
about
code
not
being
able
to
hit
email,
but
that
might
be
different
than
like
the
visibility
of
the
project
or
the
instance
in
that
regard
as
well
so
yeah,
I
think
I
think
they're
independent
settings.
A
A
A
A
We
might
have
closed
the
feature
issue.
Actually,
we
may
need
a
new
issue
to
sort
of
like
do
all
of
this.
If
we
do,
if
you
want
to
move
it
out
of
the
yeah.
C
I
really
wanted
to
bother
pedro
because
we
we've
been
butting
heads
over
this
kind
of
terminology
for
milestones
now,
what's
one
more,
even
if
it's
not
for
this
group,
so
annabelle
welcome
to
welcome
to
the
discussion
already
in
progress.
C
The
the
issue
that
we've
circled
around
multiple
times
is
when
is
it
appropriate
to
use
very
specific
technical
terminology,
and
when
do
we
need
to
be
informal
and
friendly,
because
I
think
that's
the
difference
in
these
lines
that
he's
proposing,
if
you,
if
you
click
through
to
the
changes
tab.
No,
let
me
just
share
my
screen,
because
I
can
I
can
highlight
this
nonsense.
C
C
It's
okay!
It's
okay!
I
can
recap.
It's
cool.
Tell
me
what
the
last
thing
that
you
heard
clearly
was.
C
B
It's
not
just
you,
I
don't
know
what
it
is
either,
but
maybe
a
better
person
to
ask
would
be
a
developer.
Yeah.
C
The
first
line
he
proposed,
I
agree
with
the
second
line.
I
don't
know
kai
you're,
making
a
face,
use
your
words.
A
So
there's,
like
a
source
code,
has
a
larger
plan
to
sort
of
redo
these
settings
entirely
yep,
and
so
I
imagine-
and
I've
been
following
this
question
mike
and
peter-
have
been
spending
a
lot
of
time
going
back
and
forth
on
what
these
things
actually
mean
in
the
way
that
they're
like
currently
set
up
and
what
the
impacts
are,
and
so
I
imagine
this
is
a
clarification
to
that
that
they
both
understand
well,
because
they've
had
extensive
conversations
about
it
and
those
of
us
who,
every
time
those
emails
come
in,
and
I
read
them
and
I
go
I'm
glad
that
source
code
don't
have
like
good
feelings
about,
and
so
I
think
that's
how
I
that's
how
I'm
thinking
about
this.
A
A
A
And
I
think
what
we're
changing
is
when
a
similar
new
emerge
is
not
possible,
which
means
there's
more
than
just
a
merge
conflict
can
be
a
cause
of
why
the
user's
given
an
option
to
rebase,
and
I
think
that's
basically
the
way
to
think
about
this
change
is
like
it's
removing
the
like
specificity
of
merge,
conflict.
Being
the
only
reason
for
this
and
changing
it
to
something
else.
A
All
right,
yes,
yeah,
I
think
if
you
want
the
full
history,
you
go
read
the
issues
where
they've
been
discussing,
merge
strategies
back
and
forth,
and
then
you
might
walk
away
with
a
better
understanding
or
you.
You
will
have
seen
lots
of
graphs
of
commit
trees
and
have
yep
very
little
better
understanding.
A
B
Take
after
photos
you're
drilling,
so
I'm
a
little
nervous.
Okay,
yeah
have
a
good
day.
I'm
gonna
go
watch.
It.