►
From YouTube: 2021-03-30 Weekly Create: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
A
Hey
everyone,
so
I'm
happy
to
report
that
we've
successfully
closed
the
external
survey
on
code,
review
problems
or
experience
problems
and
we've
had
a
total
of
244
responses.
We
were
aiming
for
at
least
a
hundred,
so
this
is.
This
is
great.
I
made
a
comment
there
below
about
having
a
lot
of
bots
spam
responses,
a
lot
of
them
and
it
seems
like
it's
a
recurring
problem
and
I'll
have
to
yeah
we'll
have
to
talk
about
this
internally
but
yeah.
A
That's
that
was
the
number
total
number
of
responses
kai
you're,
asking
about
referring
information.
We
do,
but
it's
very
basic.
We
only
get
if
they
came
from
an
email
or
from
somewhere
else.
We
don't
say
it
doesn't
say
if
it
comes
from
twitter
or
from
no
referrer
or
yeah.
No,
it's
just
coming
from
anywhere
on
the
web
or
from
an
email
client,
that's
what
we
get.
A
But
but
yeah
it's
I
had
to
manually
triage
it
and
there
were
a
lot
of
strange
responses.
Basically,
if
you're
curious
I'll
I'll
can
let
you
know
at
the
end
of
the
call
so
that
we
don't
waste
time
on
it,
but
it's
it
was
very
strange.
A
The
results
so
far
haven't
done
a
thorough
analysis,
but
the
top
three
problems
are
not
that
different
from
the
internal
survey
top
the
number
one
dealing
with
larger
mars,
the
second
one.
Knowing
what
happened
since
I
last
visited
an
mr.
Those
two
are
exactly
the
same
as
the
internal
survey.
The
third
one
is
different.
In
this
case,
external
respondents
classified
communicating,
slash,
understanding
the
intention
of
changes
as
one
of
the
top
problems
and
on
the
bottom,
from
most
to
least
important.
A
We
have
communicating
understanding
the
intention
of
comments,
balancing
reviews
with
other
daily
tasks
and
finding
appropriate
reviewers
for
an
mr,
if
I'm
not
mistaken,
compared
to
the
internal
survey,
the
only
difference
is
that
finding
appropriate
reviewers
for
an
mr
was
higher
on
the
list.
It
was
not
at
the
bottom.
A
This
is
interesting
to
say
the
least,
but
I'll
have
to
also
filter
the
responses
based
on
team
size,
because
if
I
imagine
that
if
it's
a
very
small
team
doesn't
have
that
much
need
to
find
an
appropriate
reviewer.
But
if
it's
a
very
large
team
organization
that
they
would
have
a
harder
time,
any
comments
or
questions
so
far.
A
All
right
and
then
some
interesting,
recurring
themes
that
came
up
in
the
open
text
responses
people
talking
about
how
difficult
it
is
to
know
what
has
happened
in
an
mr,
what's
new,
what
they've
already
seen
so
that
whole
catch-up
theme,
the
second
one
is,
is
perhaps
related
to
that
is
difficult
to
parse
the
activity
feed
with
many
threads
and
comments.
A
Okay,
go
ahead,
I
can.
I
can
write
it
for
you.
B
Like
in
the
sense
that
it's
turning
up
like
lots
of
comments
and
threads,
make
an
mr
large,
I
guess
I
think
that's
one
version
of
a
large,
mr.
The
other
version
of
a
large,
mr,
is
like
lots
of
code
changes.
B
So
are
these
sort
of
in
that
camp
of,
like
those
comments
felt
like
large,
mr
things
for,
and
they
were
large
in
march
because
of
lots
of
comments
and
stuff
and
not
large.
Mrs
because
there's
lots
of
code,
I
guess,
is
sort
of
the
way
I'm
trying
to
think
about
like
because
those
are
two
different
like
we
sort
of
arbitrarily
call
all
of
that
largemr
and
we
think
about
that
as
one
giant
problem.
But
they
are
two
things
that
have
similar
symptoms
and
similar
like
problems
with
their
different
experiences.
A
B
A
Definitely
related,
I
think
it's
difficult
to
to
define
the
line
between
them,
but
I
think
it's
a
mix
of
just
the
visual
design
that
makes
it
hard
to
parse,
even
if
you
don't
have
a
lot
of
activity
and
at
the
same
time,
it's
just
very
large
activity
feeds
and
how
mentally
taxing
that
is,
which
again
is
related
to
the
catching
up
on
an
mr
problem.
So
I
think
all
of
these
have
like
conflation
points,
which
is
the
activity
feed.
B
So
I
was,
I
now
wonder
if
we
large,
mrs
as
a
like
topic
of
rank
by
problem,
which
I
guess
we
knew
this
would
do-
is
not
specific
enough
to
know
what
kind
of
large
mar
problem
they're
talking
about
and
if
we
need
to
like
dig
in
further
just
on
that
sort
of
piece
to
understand
it
better.
A
Yeah,
that's
that's
what
I'm
trying
to
do
now
with
the
research
synthesis
and
I'm
almost
done
with
it,
and
there
is
clearly
to
put
it
short
because
so
I
don't
want
to
deviate
from
the
topic,
but
it
seems
like
it's
just
what
people
are
more
concerned
about
is
just
the
pure
performance.
A
That's
what
I
can
interpret
from
the
research
that
I've
seen
so
far,
not
so
much.
There
are
some
things
about
being,
if,
like
the
efficiency
as
a
separate
aspect,
but
there's
a
very
big
focus
on
just
slow
things
and
loading
times
and
and
not
so
much
about
clicking
and
about
managing
views,
just
how
slow
it
is
and
sometimes
not
showing
all
of
the
changes
and
you
have
to
click
to
load
them
and
re-collapse
them.
A
So
the
things
that
are
related
to
just
the
back-end
side
of
back-ends
I
mean
in
terms
of
not
the
the
ui
itself.
A
Then
many
people,
I
was
surprised,
were
talking,
didn't
link
to
this
issue,
but
they
were
all
talking
along
the
lines
of
what
that
issues
wants
to
solve.
The
display
change
that
may
threat
outdated
inline.
A
lot
of
people
were
saying.
A
I
see
a
comment,
it's
changed,
but
I
don't
see
the
comment
in
the
changes
tab
because
it
was
outdated.
So
I
have
to
go
back
and
forth
and
many
people
at
least
two
or
three
said
hey.
I
have
to
keep
a
tab
open
on
the
changes,
tab
and
the
tab
open
on
the
overview
tab
on
separate
browser
tabs
just
to
know
hey.
This
comment
was
made
on
that
line
and
I
don't
know
what
changed
so
I
can
go
back
and
forth.
A
So
this
was
a
very
interesting
and
it
it's
in
line
with
what
we're
prioritizing
in
this
milestone
some
people
mentioning
that
they
want
that
request,
attention
or
waiting
for
so
that
they
can
mark
the
ends
of
review
and,
like
passing
the
token,
between
reviewers
and
authors,
the
need
for
always
up-to-date,
merge,
request,
page
information
without
having
to
refresh
the
dimensions
were
specific
about
the
pipelines,
for
example,
that
they're
not
always
up
to
date
and
they
have
to
refresh
and
they're
not
as
fast
and
yeah.
A
But
there
are
a
couple
specific
mentions
there,
but
in
general
it's
just
like
it's
not
up
to
date.
I
make
a
change.
I
have
to
refresh
it,
or
things
are
not
appearing
as
I
as
in
real
time
as
I
thought
it
would
be.
The
squash
commit
message,
arbitrary
behavior,
which
we're
changing
this
milestone.
I
think
the
I.
B
A
The
mr
is
already
in:
if
not,
it
should
be
soon
it's
already
in
okay,
so
yeah
and
a
lot
of
people
disliking
that
behavior,
and
so
that's
another
encouragement
for
us
to
to
pursue
that
and
of
course,
performance
performance
performance
was
in
a
lot
of
the
comments.
Any
questions.
B
Not
mural
right,
it's
not
mirror
it's
the
other
one
that
we
have,
that
I
don't
remember
yeah.
Are
you
putting
it
all
in
dovetail
right?
Is
that
the
next.
A
B
A
I'll
I'll
try
to
if
we
have
time
tomorrow,
to
discuss
this
with
sanjiang.
My
idea
so
far
is
to
import
all
of
the
data
to
dovetail
both
the
internal
and
the
external
survey
into
the
same
project,
so
that
we
can
then
relate
both
the
surveys
and
analyze
them
and
extract
the
insights,
but
but
yeah.
This
was
just
my
understanding
looking
through
the
responses
today,
because
I
had
to
triage
all
of
them
and
see
who
what
were
spam
and
what
was
not
spam.
So,
while
doing
that,
I
was
taking
notes.
A
A
So
they're
not
very
concerned
about
the
number
of
commits
it
could
have
a
hundred
commits
they're,
always
reviewing
the
latest
version,
but
yeah
and
praise
we
had.
There
are
other
praises
there
in
general
people
really
enjoying
the
experience.
So
not
everything
is
bad.
They're,
saying
they're
liking.
What
we're
doing
some
people
even
say
like
there's,
nothing
that
I
can
like
suggest
or
change.
I
think
it's
really
good.
There
are
some
things
here
and
there
and
specific
praise
for
multi-line
comments.
A
Mark
is
viewed
suggestions
in
general
and
the
recent
edition
of
reviewers
and
related
to
these
recent
features
that
we've
introduced.
It
was
interesting
that
some
respondents
were
asking
for
them
at
the
same
time.
So
not
the
same
people
that
were
praising,
of
course,
but
other
respondents
were
saying.
I
would
like
multi-line
comments.
I
would
like
to
mark
files
as
viewed
or
I'd
like
reviewers,
maybe
they're,
not
in
the
latest
version.
I
didn't
check
comments,
questions.
B
Thank
you.
I
think
you,
you
did
an
awesome
job,
putting
the
survey
together
and
then
I
don't
know
how
we
drove
to
nearly
250
responses,
but
that's,
but
it
feels
pretty
good
because
I
know
a
lot
of
groups.
It
takes
a
long
time
to
get
there,
so
I
feel
like
whatever
we
did
worked.
That's
why
I
was
sort
of
curious
about
her
stuff
but
yeah.
I
appreciate
it.
Thank
you.
A
Yeah
yeah
also
thank
you
to
you
for
re-sharing
on
social
media.
I
know
that
marcel.
A
He
also
shared
it
and
that
drove
a
bit
up
the
number
of
responses,
but
I
think
what
did
what
sealed
the
deal
was
that
a
certain
point
I
think
the
gitlab
twitter
account
saw
that
we
were
talking
about
this
and
they
retweeted
one
of
our
tweets
and
so
that
exploded.
I
think
the
not
only
the
number
of
humans,
but
the
number
of
bots.
A
B
Kai
the
next
two
are
sort
of
fyis.
The
first
one
is
there's
a
meeting
next
week
to
talk
with
the
compliance
folks
about.
B
Yet
another
sort
of
approval
concept
in
merge
requests-
and
I
know
it
looks
like
it
was
discussed
months
ago
and
I'm
not
sure
there
was
a
great
resolution,
then
and
and
now
they're
sort
of
even
further
down
this
path
and
I'm
even
more
worried
about
the
concept
they're,
introducing
and
so
just
trying
to
get
on
the
same
page
with
them
and
make
sure
that
we
understand
what
they're
doing
and
agree
that
it's
the
right
path
to
go
so
that
we
don't
introduce
another
confusing
concept
into
something
that
sort
of
muddies
two
other
concepts
that
we
already
have
and
like
impact
the
experience-
and
I
think
this
also
comes
from
a
place
of
knowing
that,
like
ultimately,
is
users
run
into
issues
or
if
they
run
into
issues
with
this
we'll
end
up
being
the
first
group
that
has
to
sort
of
like
triage
and
understand
everything
in
order
to
get
it
back
to
the
right
groups
as
how
that's
historically
worked.
B
B
This
is
an
ideal
case
of
where
the
ownership
page
stuff
that
we,
the
pedro
and
I
are
working
on,
would
would
come
in
handy
where
we're
saying
you
know
this
is
one
of
those
I
would
say
top
level
things
we're
like.
Oh,
you
want
to
introduce
a
new
approval
concept
like
here's
who
you
need
to
talk
to
and
like
who
needs
to
approve
this
and
buy
in
before
you
even
like
get
down
as
far
as
they
are
in
the
path,
and
so
I
think
I
definitely
think
they
should.
B
We
should
try
and
figure
that
out,
and
I
believe
yes
pedro
to
your
question-
I
pinged
daniel
and
mike
in
my
thread
on
the
epic
and
asked
if
they
wanted
to
also
come
to
the
meeting,
so
I
haven't,
neither
one
of
them
has
responded,
but
I
did
I
did
ping
them.
I
think
it's
twofold.
I
think
some
of
this
is
approval
rules
in
terms
of
back
in
technology,
and
some
of
this
is
merge
request.
A
So
you
were
mentioning
the
ownership
of
the
merge
request,
experience.
A
A
We
would
also
need
to,
or
the
source
code
group
would
also
be
encouraged,
to
set
up
their
own
ownership
model
in
a
way
right.
B
I
think
that's
why
it
is
crossing
both
those
bridges
right
because
they're
deciding
to
solution
this
in
approval
rules
that
sort
of
makes
it
a
source
code
piece
of
interest
and
a
merge
request
like
a
code
review
piece
of
interest
if
they
hadn't
solutioned
this
yet
and
had.
Instead,
if
we
had
sort
of
this
ownership
model
in
place
and
had
said
if
this
is
what
you're
trying
to
do
come
and
talk
to
us,
we
they
might
not
use
approval
rules.
B
I
think
you
have
said
that
you
said
this
in
a
comment
previously,
I
look
at
it
and
I
I
don't
know
why
this
is
an
approval
rule
right,
like
I
think
you,
and
I
would
both
agree-
that
what
they're
trying
to
accomplish
is
not
an
approval.
Rule
thing:
it's
a
it's
a
merge
check,
because
it
is
an
external
system
that
is
validating
that
something
can
be
merged.
B
It
is
not
a
user
action
right
is
sort
of
the
difference,
and
so
at
that
point,
if
that's
what
we
had
said
then
source
code,
then
it
wouldn't
be
an
approval.
Rule
thing
and
source
code
wouldn't
need
to
necessarily
be
aware
of,
what's
going
on
because
we're
now
in
a
muddy
in
a
much
like
cloudier
phase
of
this,
I
think
that's
why
source
code
should
be
more
informed
here,
but
we
should
have
started
with
the
merge
request.
Experience
right
like
that,
then
that's.
I
think
the
piece
that
we
need
to
keep
in.
A
B
B
And
I
don't
know
what
will
come
out
of
the
discussion
with
them,
but
I
don't
know
if
we
can
pump
the
brakes
on
it
or
if
we're
going
to
end
up
with
this
and
and
then
spend
a
lot
of
time
trying
to
rework
ourselves
back
out
of
it
but
the
faster.
We
can
get
ahead
of
this
and
have
stronger
opinions.
I
think
the
better.
A
A
And
I
had
a
lot
of
discussion
with
who
was
in
with
matt,
I
think
and
austin
about
to
me
like.
If
we're
calling
an
api
and
we're
blocking
the
merge,
why
don't
we
use
pipelines
for
this?
A
So
it
would
be
a
job
in
a
pipeline
and
if
the
job
fails,
but
then
he
explained
to
me
that
these
trying
to
distance
themselves
from
the
pipeline
because
they
want
compliance
jobs
to
be
separate
from
yeah
from
from
the
rest
of
the
other
code
quality
jobs
which,
to
certain
extent
you
can
also
have
compliance
things
there.
You
could
have
a
job
failing
because
it
doesn't
meet
the
security
compliance
or
something
like
that.
A
It's
not
compliant
with
the
security
practices,
but
he
told
me
that
they
wanted
to
be
separate
because
they
have
some
organizations
that
have
tools
for
compliance
that
are
external
to
gitlab
and
those
tools.
Those
compliance
tools
would
then
speak
with
git
lab
to
allow
or
disallow
something
to
be
merged.
A
B
Yeah,
that
is
the
impression
that
I
got
and
I
think
that
that
conversation
I
linked
it
down
below
in
the
previous
discussion.
That's
where
you
had
that
with
austin
before
and
matt.
I
think
they
went
ahead,
anyways
and
and
are
doing
this
as
an
approval.
It's
like
a
sort
of
the
way
it
works
based
on
the
screenshots.
B
Is
that,
like
in
a
merge
request,
you
can
now
define
an
approval
rule
and
instead
of
defining
an
approval
rule
that
approval
rule
actually
gets
like
an
api
endpoint
of
a
third-party
system
and
that
third-party
system
is
there
is
then
responsible
for
passing
or
failing
that
approval
rule.
Somehow
somehow
it's
going
to
get
notified
and
somehow
it's
going
to
pass
or
approve
it
yeah,
and
that
is
that
is
where
they
are
on
that
and
it
shows
up
based
on
all
the
ui
stuff.
It
shows
up
inside
of
approval
rules.
B
It
has
its
own
term,
but
it
is
inside
of
that
approval
rules
widget
it.
I-
and
you
know
I
don't
know
how
it
it
talks
to
that
thing.
I
don't
know
how
often
it
will
talk
to
that
thing.
I
don't
know
what
happens
if
that
service
is
down
or
it
doesn't
respond
in
a
way
that
we
expect
it
to
respond.
Or
you
know
I
would
have
a
bunch
of
questions
once
we
see
that.
But
you
know
the
first
question
is
sort
of:
is
that
even
the
right
place
for
that
kind
of
experience
versus?
B
Should
the
merge
button
just
not
be
able
to
turn
blue?
If
that
check
comes
back,
and
you
know,
I
think
that
gets
into
what
we're
talking
about
and
sort
of
the
next
one
that
I
have
on
the
internet,
which
is
like
better
defining
the
terminology
and
understanding
sort
of
like
the
user
experiences
of
those
things,
because,
in
my
mind,
approval
rules
are
a
user
actionable
thing
like
I,
as
a
user
can
see
that
it
is
an
approval
rule
and
requires
me
to
go,
find
a
person
in
that
list
to
approve
it
and
like.
B
I
know
how
to
solve
that,
and
I
think
this
is
one
of
those
things
where
like.
If
that
comes
back
as
a
red
x,
I
as
a
developer,
sit
there
and
go
cool.
How
do
I
fix
this
and
who
do
I
talk
to
because
there's
no
picture
here
and
there's
no
person
here
and
there's
nothing
that
tells
me
anything
about
what
failed
it
just
is
now
a
red
x.
A
A
Yeah,
the
one
I
I
might
share
this
again
in
the
in
the
call,
but
the
way
that
I
think
what
we're
lacking
now
is
just
we
don't
have,
as
you
said,
the
not
only
the
the
correct
shared
terminology,
but
we
also
don't
have
a
good
model
for
what
they're
trying
to
do
and,
for
example,
in
azure
devops.
What
they
have
is
for
they
do
it
at
the
branch
level.
But
you
can
imagine
that
this
could
also
be
at
the
project
level.
A
A
Succeeding
or
not-
and
you
can
have
policies
here
for
the
cicd
things,
and
then
you
have
status
checks,
which
is
another
thing
to
require
other
services
to
post
successful
status,
to
complete
pull
requests,
and
I
think
this
is
what
they're
after
and
what
we're
trying
to
do
is
separate
this
from
the
approval
rules,
which
here
they
call
automatically
include
reviewers
and
you
can
make
them
required
blah
blah
blah.
There
are
a
lot
of
things
here,
so
this
is,
I
think,
what
we're
missing
is
this
separate
part
which
separates
it
from
approvals?
A
So
it's
it's
not
an
approval.
It's
another
external
service
that
posts
a
result,
but
I'll
share
it
there
in
the
call.
B
Yeah
yeah,
I
would
agree,
I
think
it's
we're
missing
a
piece
and-
and
we
just
need
to
be
careful
about
moving
quickly
with
thing
with
a
boring
solution
in
the
merge
request,
so
we're
up
at
time.
The
last
one
is
the
better
to
find
terminology.
Third,
I
think
everyone
on
this
call
has
chimed
in
or
potentially
chimed
in,
I
would
say,
keep
looking.
I
honestly,
I
threw
it
out
there
as
a
way
to
sort
of
spark
the
conversation,
because
I
it
has
come
up.
B
What
would
it
take
to
build
like
a
generic
merge,
widget
extension
and
then
his
response
back
to
me
was
like
well?
What
exactly
are
you
talking
about,
and
I
had
to
specify
with
phil
like
these
things
here,
not
this
one
down
here
and
I
was
like
okay.
This
is
it's
clearly
a
recurring
theme
for
the
group
that
we
don't,
and
I
don't
know
if
we
need
to
do
it
externally
internally.
B
B
C
Yeah,
I
think
it's
great.
I
I
had
nothing
to
chime
in
with
at
the
moment,
but
I
will
say
that
before
this
research
started,
I
was
like
100
sure
it
was.
The
merge
request.
Widget,
like
the
whole
thing,
was
just
the
merge
request,
widget
and
then,
when
we
started
talking
about,
I
was
like
wait.
Are
there
widgets
in
the
widget?
Are
they
all
just
separate
widgets?
What
is
happening
so?
Yes,
I
100
agree
with
the
need
to
like
align
on
it
at
least
internally.
D
It
it
will
end
up
going
externally,
because
this
is
actually
a
problem.
I've
noticed
in
the
documentation
that
we
provide
a
step
by
step
of
okay
you'll,
go
to
the
the
merge
request
page
and
then
you
scroll
to
the
thing
that
has
no
name.
This
totally
does
not
work
for
users.
So
yes,
I'm
gonna
steal
whatever
you
choose.
B
Perfect,
well,
I
think
that's
it
pedro!
You
can
look
at
the
next,
the
weekly
sync
one,
there's
two
openmrs
that
I
think
you're
tagged
as
a
reviewer
on.
If
you
get
a
chance,
I
know
lots
of
other
things
going
on,
but
I
was
going
to
remind
people
tomorrow
on
that
one
as
well.
B
Awesome
well
thanks:
everyone
enjoy
the
rest
of
your
day,
thanks
for
all
the
research
and
stuff
and
yeah
we'll
keep
keep
moving.