►
From YouTube: Code Review Weekly Workshop - Feb 24, 2023
Description
In this session we discuss some topics pertaining to code review.
00:00 - Testing MR diffs on target branch vs. MR branch
07:00 - Is it usual for UX designers to create MR's?
13:30 - Handling community MR's that need to wait for something else
21:47 - Viewing full-stack perspective of a change
39:41 - On over-communicating and mentoring, while not offending
53:20 - "Assume they are Super-Smart"
A
All
right:
well,
thanks
for
hopping
on
the
code
review,
weekly
Workshop,
we're
gonna
talk
about
some
code
review
stuff
and
let
me
share
my
screen.
I
had
something
come
up,
we
had
a
couple
of
Mrs
that
were
back
to
back
touching
this
component.
This
toggle
component,
one
was
kind
of
refactoring
all
together
with
the
disabled
state
was
but
then
the
other
one
is
adding
this
like
description
thing
here.
So
you
see,
on
the
left
hand,
side
doesn't
have
the
enabled
disable
dark
mode
description
prop.
A
A
So
this
obviously
like
brings
up
I
think
lots
of
interesting
takeaways
of
how
Mrs
can
conflict
with
each
other
without
actually
having
hard
mortgage
conflicts
catching
that
is
really
really
hard.
But
it
can
go
a
long
way
just
when
you're
testing,
something
it's.
It's
very
small
effort
to
just
see
if
you
can
apply
the
diff
on
top
of
Master
and
Main
instead
of
just
checking
out
the
branch,
because
then,
then
you
have
a
higher
chance
of
these
things
coming
up
when,
if
and
when
they
do
come
up.
A
B
A
Yeah,
you
can
bring
up
another
great
question
and
that
is
that
no
visual
testing
might
have.
But
the
issue
is
that
this
is
a
new
thing,
so
we
don't
have
previous
visual
testing
for
it
and
so
we'd
be
really
dependent
on
do.
We
have
a
visual
snapshot
of
the
new
thing
on
the
disabled
state
which
we
didn't,
because
it's
like
visual
testing
is
expensive,
so
you
don't
want
to
do
it
for
all
the
permutations,
but
in
the
main
gitlab
project.
A
A
C
C
A
But
the
I
think
the
color.
There
are
a
set
of
CSS
effects
that
are
just
really
hard
to
test
and
you're
not
gonna,
be
able
like
CSS.
This
one
makes
it
a
little
challenging
as
it's
really
easy
to
change
it's
very
hard
to
test,
and
you
can
end
up
where
the
effect
is.
Everything
looks
broken,
but
it
still
works.
But
it's
because
some
CSS
issues
so
reviewing
CSS
and
testing
it
is,
can
be
a
little
bit
of
a
chore.
A
A
C
A
And
it,
and
so
I
there's
some
previous
conversation
that
and
I
even
asked
to
I
think
in
something,
but
this
got
ux
reviewed
by
Pedro,
so
I
think
I
think
we
are
kind
of
moving
towards
some
sort
of
Direction
here,
but
I
think
it's
here.
You
see
that
I
do
kind
of
raise
a
ux
question
or
ux
issue,
and
it's
worth
also
taking
away
of
like
hey.
This
is
a
ux
designer,
they're
kind
of
like
the
dris
for
this
stuff.
D
A
It's
a
good
question:
I
would
say
it's
Not,
Unusual
and
so
I
guess
it
is
usual.
When
I,
when
I
resolved
the
negatives
there
yeah
I
would
say
that
it
it
happens
commonly
and
from
Front
End
perspective.
It's
actually
like
our
desired
outcome.
I
would
like
to
make
the
front
end
so
easy
to
contribute
to
that
ux
when
they
have
an
idea
they
could
just
implement
it
like.
That
would
be
the
the
ideal
so
yeah,
that's
a
good
question
and
I
think
part
of
that
is
everyone
can
contribute.
So
we
really
want.
D
B
Oh
yeah,
but
those
people,
that's
part
some
people
they
do
it
regularly,
but
I
think
it's
always
a
part
of
the
issue.
I
I
have
actually
I
mean
I've
done
front
end,
work,
I,
don't
like
it,
but
I've
done
it
and
if
I
see
something
that's
small
enough
and
easy
enough,
you
know
it
just
kind
of
like
there's
a
label
that
I
saw
at
one
of
my
team,
member
or
teammates
using
called
like
stuff
that
should
just
work
and
sometimes
I'll,
throw
that
on
Mr.
B
A
B
60
thread
Mr
then,
like
maybe
your
assess
initial
assessment
wasn't
right
and
you
should
have
made
an
issue
but
yeah
I
feel
like
it's
fine
I
mean
I,
make
docs
Mrs
too,
and
I've
seen
people
from
other
teams
like
support
team
members,
they'll
make
like
code
change,
Mrs
and
I
feel
like
those
are
always
really
welcome.
You
know
they
know,
you
know
they
know,
they
know
development,
they
know
Ruby
and
they
have
sometimes
I
feel
like
a
closer
tie
to
like
the
customer
experience
than
we
do.
D
Yeah,
don't
get
me
wrong,
I'm,
not
trying
to
like
deny
anyone
the
ability
to
create
a
mask.
It's
not
about
that.
It's
more
like
understanding
like
how
different
roles
are
like
what
are
the
the
scope
of
things
that
a
different
role
can
do
like
I
was
under
the
impression
that
the
ux
would
not
commit
any
code
yeah.
E
E
D
A
A
Writing
abilities
is
a
plus
for
those
roles,
but
I
don't
know
if
I
want
to
clarify
that
I,
don't
think
we
expect
non-engineers
to
write
code,
but
we
highly
encourage
and
are
there
to
collaborate,
and
all
of
that
is
great,
and
so
it
does
go
a
long
way
when
you
can
and
do,
but
it's
not
a
expectation
I,
but
because
of
our
culture.
We
have
some
people
that
just
do
want
to
go
the
extra
mile
and
do
things
like
that.
So
it's
people
want
to
learn.
A
D
D
A
B
This
is
a
database
review
and
I
kind
of
like
went
down
this.
You
know
for
database
reviews,
there's
a
pipeline
job
that
you
pretty
much
need
to
run
before,
like
it
can
be
sent
to
a
maintainer
that
does
a
bunch
of
checks
and
runs
the
migrations
and
it
prints
a
nice
little
message
with
timings
and
things
like
that.
B
This
one
didn't
run
and
I'm
like
not
sure
why
we
I
think.
Four
days
later,
the
the
author
ping
me
and
I'm
like
oh,
it
didn't
finish
so
I
kind
of
went
to
the
database
team
to
ask
if
they
could
help
look
at
why
and
they
said,
there's
some
migrations
that
this
Mr
needs
to
be
completed,
but
they're
not
done
they're
background
migrations,
so
I
went
and
checked.
Both
of
them
are
like
10
and
15
percent.
B
I
don't
know
when
they'll
be
done,
but
now
I
have
this
Mr.
That's
in
this,
like
very
strange
state
where,
like
I'm,
the
reviewer,
the
author
can't
check
the
status
of
their
background.
Migrations
do
I,
just
set
a
calendar
reminder,
but
I
mean
I
left
them.
A
note
and
I
was
like
well
I'm,
not
really
sure
what
the
process
is
here
but
I
mean
I,
asked
in
the
Mr
coach
Channel
and
got
like
no
answers
so
I'm
like
okay,
I.
A
B
B
There
are
some
migrations
that
they
do
in
stages
where
it's
like
you,
this
thing
happens
and
then
it
you
can
like
build
on
top
of
it,
but
it
has
to
like
the
first
thing
has
to
finish.
I
also
have
no
experience
with
writing
those,
but
maybe
I'll
just
set
a
calendar
reminder
in
like
two
weeks
to
go
check.
It.
A
A
So
I
kind
of
just
brought
up
the
suggestion
of
like
we
should
probably
enable
this
because
that's
kind
of
what
we
do
with
feature
Flags
before
we
just
remove
it
and
so
because
they're
on
The
Wider
Community
contributing
to
it
and
not
as
ingrained
with
our
process,
and
they
can't
just
manage
the
feature
flag
enabling
and
stuff
I
kind
of
had
to
do
that.
But
then
I
also
set
a
time
of
like
okay,
we're
gonna
wait
like
a
couple
of
days
for
for
this
and
yeah
I.
A
Think
I
just
left
it
assigned
to
me
like
so
that's
but
that'll
that'll
run
into
geez.
If
you
have
an
MR
assigned
to
you
and
you
use
the
number
system
to
like
measure
your
capacity
you'll
be
one
less
capacity
for
a
while,
but
yeah
I
I
just
left
it
assigned
to
me,
because
I
always
try
to
clean
out
all
those
Mrs
that
I'm
assigned
as
a
reviewer
regularly
so
yeah.
Those
are
interesting
cases.
B
A
D
B
B
B
We
want
to
Market
as
finalized,
but
yeah
I
kind
of
felt
like
it
was
really
difficult,
I
guess
for
Community
contributors
they
have
no
window
to
look
at
the
bashed
background
migration
list
and
I
only
just
learned
that
we
could
do
it
through
chat,
Ops,
I
guess
commands
so
I.
Don't
do
database
work
most
of
the
time
I
like
I.
Don't
do
migrations
very
often
so
I
hadn't
run
into
this
and
I'm,
not
sure.
If
you
do
in
your
in
your
role.
D
B
Because,
like
oh
I'm,
working
in
elasticsearch,
which
is
like
that's
what
backs
a
lot
of
the
the
search
calls?
And
so
while
we
do
work
on
the
database,
but
it's
mostly
we're
just
using
it
for
non-elastic
calls
I
mean,
but
we
still,
you
know
we
can
still
impact
it
by
not
using
indexes
and
not
like
pre-loading
data
and
things
like
that.
B
B
A
B
A
A
Maybe
somewhat
maybe
somewhat
related
the
we
were
talking
about
like
people's
roles
and
but
often
Crossing
that
and
finding
this
very
open
collaborative
space,
something
that
kind
of
I
I
see
come
up.
Often
between
our
back
end
and
front
end
split
is
sometimes
a
front-end
engineer
finds
a
very
front-end
solution
to
something
that
maybe
was
a
very
simple.
A
We
should
add
a
database
field
for
this,
and
it's
not
that
scary,
like
maybe
the
front
Ender,
is
just
adding
some
local
storage
field
for
something
as
opposed
because
our
frontenders
I
I,
think
enlarge
are
were
not
regularly.
Looking
for
the
full
stack
solution
to
a
problem
and
we'll
Jesse
is
the
tools
that
we're
most
familiar
with,
so
those
are
interesting
sometimes
to
to
as
a
maintainer
to
review
and
to
almost
kind
of
go
back
to
the
very
top
of
challenging
our
assumptions
of
I
see.
A
A
For
these
edge
cases,
whatever
it
is
sometimes
that
just
spins
up
in
follow-ups,
but
even
though
I
think
our
specific
roles
like
I,
could
I
guess
I
get
paid
to
write
the
the
bugs
on
the
front
end
and
don't
get
paid
for
the
bugs
I
write
on
the
back
end.
The
users
are
well
served
if
we
all
kind
of
continue
to
promote
the
full
stack
perspective,
because
I
think
that
just
allows
us
to
use
the
best
tool
for
the
best
job,
and
this
does
come
up
in
code
review.
A
So
I
would
just
encourage
everyone
to
as
you
review
code,
if
it's
upfront
in
solution
that
it
seems
maybe
more
fit
to
be
a
back-end
solution
like
yeah,
definitely
bring
it
up,
bring
it
as
a
question
to
be
consider
this.
Why
didn't
we
go
this
way
and
maybe
there's
reasons
for
it
and
maybe
no,
we
just
didn't
consider
it,
and
this
is
why
we
have
code
review
so.
D
D
Double
up,
but
it
like
the
back
end
should
read
the
validation
right.
It's
it's
that's
usually,
although
the
like
the
the
original
validation,
let's
say
down
by
the
front
end
like
there
is
no
need
to
pass
in
a
request
that
will
obviously
fail
is
basically
the
validation
that
we
should
do
on
the
front.
C
D
So
I
I
was
just
wondering
because
you
said
that
we
sometimes
come
up
with
different
solutions
in
the
front
end
that
maybe
should
be
in
the
back
end.
Isn't
there
like
a
kind
of
like
an
outline
of
what
type
problems
we
can
keep
in
the
front
end,
but
what
we
should
definitely
push
to
the
back
ends.
Yeah.
A
These
truths
we're
getting
from
the
back
end,
aren't
normalized.
We
need
to
address
the
single
source
of
Truth
problem,
for
how
do
we
calculate
X
and
very
much
we'll
just
calculate
it
right
there
in
the
front
end
when
it's
in
reality?
It's
like
okay?
No,
maybe
we
need
to
really
untangle
some
of
the
stuff
in
the
back
and
obviously,
depending
on
like
the
urgency
and
how
much
of
a
bug
like
something's
fixed.
A
It's
a
it's
a
thing
but
I
see
single
sorts
of
Truth
problems
come
up
a
lot
and
so
like
even
doing
a
level
of
soft
permission.
Checking
on
the
front
end
can
be
a
thing
and
I
think
for
the
most
part,
our
front
Enders
that
the
more
they've
contributed
to
gitlab.
They
see
I
think
the
kind
of
class
of
problems
that
are
better
solved
here
and
and
elsewhere,
but
I
think
the
biggest
question
I
I
I
think
is
worth
just
prompting,
for
this
is
just
what's
the
single
source
of
Truth
for
X.
A
B
I
I
totally
I
mean
we
would
I
just
ran
into
this
problem
in
the
search
thing
like
when
you
do,
searches,
there's
params
that
are
in
the
URL
and
the
the
back
end
will
completely
ignore.
What's
in
some
of
the
prams,
depending
on
many
rules,
regulations
and
kind
of
things
that
happen
and
what
we
were
seeing
is
that
the
front
end
wasn't
kind
of
like
mimicking
exactly
what
like
the
back
end,
was
doing
because
the
front
end
was
like
looking
at
the
URL
params
and
the
back
ends
like
you
sent
epics,
but
that's
not
allowed.
B
So
it's
going
to
be
blobs,
but
we
don't
update
the
URL
there's
no
way
for
us
to
like
manipulate.
What's
in
the
browser,
Emily
that
I
know
without
redirects,
which
is
like
you
know.
So
it's
very
strange
you
know
and
I
started
digging
into
it,
and
I
was
trying
to
explain
to
the
person.
I
was
like
comparing
with
I'm
like
there's
too
many
rules
like
the
back
end.
B
A
B
A
A
A
A
A
We
ran
into
here
that,
rather
than
just
capturing
all
those
conditions
throughout
the
front
end
and
when
they
didn't
totally
belong
in
the
back
end
because
it
was
about
like
because
it
was
presentational
state
having
like
a
single
source
of
Truth
For
What
transforms
the
backend
model
into
the
very
easily
consumable
single
source
of
Truth.
For
the
presentation
model
was
really
helpful.
What
what
encouraged
me
of
like?
Okay,
this
this
is
helpful,
be
it
backenders
were
able
to
make
changes
here
without
touching
any
view,
components
and
it,
and
that
was
really
powerful.
A
I
say
this,
because
this
is
the
other
option
for
some
of
that
single
sorts
of
truth
questions
is
like
okay,
we
can't
touch
the
back
end,
because
maybe
it's
an
API,
that's
hardened.
We
just
can't
change
that
somehow,
then
creating
some
sort
of
intermediary
model,
either
on
the
front
end
or
the
back,
and
then
this
is
the
single
source
of
Truth
for
what
we
wish.
The
model
kind
of
was
like
at
this
state.
That
kind
of
thing
can
be
super
helpful,
too
yeah.
A
A
So
there's
some
like
responses
from
the
back
end
and
then
there's
also
like
the
initialization
data
and
all
of
it
is
just
remapping
it
into
a
model,
that's
very
friendly
to
the
to
the
components
and
that
way
view
components
can
be
very
just
presentationally,
dumb
I
don't
have
to
do
all
these
calculations
and
because,
when
components
are
complicated,
that's
that's
the
most
complicated
I
think
front-end
code
that
we
get
now
view.
X
might
be
the
most
complicated
friendly
code
that
we
get.
C
A
A
B
B
A
B
B
A
C
A
B
A
Yeah,
this
is
interesting
and
it's
interesting
even
considered
yeah.
This
is
all
I
think
Uncharted
decision
tree
territory
of
like
because
we
even
have
those
like
backend
rails
components
and
that
actually
might
be
more
in
some
ways
that
might
be
more
appropriate
than
using
a
presenter
like
this
presents
label
as
label
rails
is
weird
rails
is
weird
I.
B
A
A
It
has
a
real
one
of
one
of
the
ones
that
stuck
around
me.
The
most
was
there's
the
the
very
new
front-end
Engineers
asking
the
senior
front
Engineers,
something
like
asking
something
like:
oh
hey,
I'm
having
trouble
at
you
know
vertically.
Aligning
this.
You
know
this
image
on
the
container.
Can
you
help
me
out,
and
the
senior
engineer
says:
oh
yeah,
it's
just
vertical
line
Center
and
if
you
need
to
do
a
horizontal
line,
it's
like
horizontal
line.
So
it's
like.
A
Oh
thanks,
it's
great,
but
the
other
person
says
that
was
cool.
That's
not
that
or
like
that's
not
how
it
is
it's
like
I
know,
but
everyone
has
to
learn.
The
hard
way
of
CSS
is
since
the
introduction
of
flexbox
is
like
solved
all
alignment
problems,
but
before
then
was
vertically
aligning
was
so
gnarly
all
right,
cool
yeah.
Well,
we're
we
don't
have
a
whole
lot
of
time
for
code
review.
A
A
C
A
A
I
did
really
want
to
ask
all
of
your
thoughts
on
this
communication
topic,
especially
when
you
communicating
with
people
from
The
Wider
community
and
really
curious
to
know.
If,
if
anyone
has
ever
had
a
situation
where
maybe
the
communication
didn't
go
super
well,
because
you
assumed
that
the
contributor
didn't
know
something,
so
he
kind
of
over
explained
it,
and
so
then
they
felt
like.
Oh,
what
do
you
mean?
A
You
don't
think
I
know
this
and
have
have
have
you
all
ever
ran
into
that
which
can
happen
on
occasion
when
we
do
so
much
async
communication
and
I'd
love
to
hear
your
thoughts
on
how
do
you
communicate,
especially
maybe
Mrs
from
The
Wider
community?
That
requires
some
level
of
oh
here's,
a
suggested
and
I.
Don't
know
how
much
context
and
how
much
explanation
I
should
have
without
I.
Don't
know
what
are
your
thoughts
on
that.
C
A
It's
tough,
it
has
happened.
Yeah
best,
tough
I
feel
like
I
know
that
I
don't
have
an
example
off
top
of
my
head,
but
I
know
that
I've
come
across
where
I
think
I
I
left
the
comment.
I
don't
think
I
was
being
I,
don't
think
it
came
across
like
I
was
being
patronizing,
but
I
think
a
community
contributor
could
have
taken
it
that
way
because
they
did
respond
with
something
like
oh
yeah,
I
know
about
this,
but
knowing
about
this,
that's
why
I
did
this
whatever
and
that's
cool.
It
was
like.
A
E
E
Yes,
I
think
like
asking
clarifying
questions,
but
also
like
rephrasing
like
what
they
their
solution.
They
wrote
and
making
sure
I
I
also
understand
what
they
wanted
to
do.
That's
yeah
good
practice
here,
but
I
also
guess
yeah.
Some
people
might
just
get
defensive
anyway,
you
can.
You
can
never
fix
all
the
problems
or
like
address
all
the
patients.
A
Right
and
that's
that's
definitely
effective.
You
can't
expect
to
please
everybody
and
some
people
are
just
gonna,
take
things
the
wrong
way
or
whatever
I
like
your
example,
though,
of
trying
to
meet
where
the
contributor
is
coming
from,
but
then
also
sounded
like
you're
able
to
use
problem,
specific
information
about
these
specific
classes
or
whatever
that
were
being
reused,
and
this
is
why
that
more
tangible
reason
of
like
why
were
we
want
to
go
a
different
route?
A
I
think
that
that
carries
a
lot
more
weight
than
whenever
it's
like?
Oh,
some,
very
vague
fuzzy
like
you
know,
and
some
what
am
I
trying
to
say,
I'm,
trying
to
say
that
sometimes
as
Engineers
we
can.
We
can
be
really
realistic
of
like
this.
This
isn't
functional
enough
or
like
or
whatever
it
is,
and
it's
not
not
saying
that
the
CSS
isn't
like
that,
but
just
like
whatever
it
is,
we
can
get
and
then
I
can
get
the
hyper
hyper
fixated
on.
A
Like
oh
there's,
there's
another
way
to
do
it
there's
a
better
way,
but
there's
not
really
a
tangible
reason
to
do
it
that
way
here,
and
so
that's
always
something
to
sift
through
on
on
my
end,
but
finding
a
tangible
reason
for
it.
This
is
already
being
reused
elsewhere
like
this,
so
we
got
into
it
this
way
that
that
goes
a
long
way,
but.
E
A
Yeah
it's
to
bring
that
up,
I'll
bring
up
I
do
over
communicate
so
much
so.
I
use
those
like
code
review
labels,
the
conventional
comments,
all
the
time
to
just
leave
non-blocking
thoughts
and
non-blocking
preferences,
I
just
I'm
just
over
communicating
because
we
don't
get
to
communicate
a
whole
lot.
We
have
this
asynchronous
cycle,
so
that's
great.
A
D
Higher
level
because
you
don't
know
how
much
they
know,
but
if
it's
someone
from
gitlab,
then
that
changes
things
dramatically,
I
think
because
you
don't
want
to
be
like.
Oh
yeah
have
a
look
at
this
link
and
this
link,
and
then
it's
sorry,
maybe
not
dramatically,
but
I
think
we
should
probably
be
a
little
bit
more
careful
about
like
giving
them
really
like,
like
very
simple,
like
basically
kindergarten
programming
advice,
because
that
might
just
say
they
might
think
that.
Oh,
you
think
they're
a
little
of
me.
You.
A
Know
what
I
mean
I
know,
that's
what
I'm
thinking
in
my
head,
it's
like
I
can
I
can
I
know
that
if
someone
wrote
me
a
comment,
I'm
trying
to
think
of
I,
don't
know
if
someone
said
hey,
we
could
do
this.
Recursively
recursion
is
like.
Where
function
can
actually
reference
another
function
itself,
you
want
to
make
sure
you
always
have
a
terminating
like
they
just
are
teaching
recursion
to
me.
D
A
But
I
get
I
get
though
like
I
get
the
the
like
I
I,
don't
think
I
would
feel
bad
I
think
I
would
just
realize
I.
Think
I
would
feel
maybe
misunderstood,
but
that's
not
me
like,
like
I
get,
are
communicate,
there's
so
much
static.
That
goes
on
in
the
asynchronous
communication
that
I
Get
Where
We
Are
over
Community
I
have
no
problem
with
over
communication.
B
E
B
B
Yeah
I
guess
I
link
to
people's
things
all
the
time,
but
not
to
this,
mostly
to
our
guidelines:
I,
don't
I've,
not
yeah
I,
also,
unfortunately,
we're
trying
to
get
more
folks
to
like
contribute
to
search
but
having
it
interact
with
an
additional
technology,
a
stack
outside
of
like
the
normal
things
that
you
can
get
running
in
GDK.
It
does
I
feel
like
help.
C
B
On
it
so
yeah
well,
I'm
glad
it
was
not
so
bad
yeah
I'm
trying
I
want
to
push
some
of
our
reviews.
Out
of
our
team.
More
often
I
feel
like
sometimes
our
team
tends
to
hold
the
reviews,
especially
within
the
back
end
code
on
within
our
team
and
I.
Don't
know
how
I
feel
like
sometimes
that
I
like
sharing
the
not
like
sharing
knowledge
about
like
our
future
with
other
folks,
but
there's
definitely
yeah
a
lot.
A
Wider
Community
isn't
able
to
contribute
if
things
aren't
maintainable,
so
we
I
highly
recommend
just
everybody
really
treat
The
Wider
Community
as
primary
audience,
because
that
that
helps
everybody
out,
and
that
just
goes
with
our
values
too,
of
like
very
low
context,
changes
going
a
long
way
yeah
on
this
topic,
I'd
love
to
hear
on
the
topic
of
potential
over
communication
that
hurts
people's
feelings.
I
would
love
to
hear
what
you
all
think
would
be
like
what
would
be
taking
it
too
far
and.
A
D
I
think
we
should
probably
assume
that
people
that
are
here
and
let's
say,
got
into
a
mid
like
we
don't
have
any
Juniors.
If
we
did,
it
would
be
a
slightly
different
story
but
like
when
we
already
like
at
the
middle
level,
we
can
assume
a
certain
level
of
Knowledge
from
people,
and
so
we
should
probably
not
like
explain
things
something
unless
they
ask
specifically
like
hey.
D
Also,
first,
you
have
to
get
the
freshest
master,
so
you
do
git
rebate.
So
to
me
it
was
like
a
spare
like
we
like
it.
Didn't
it
didn't
add
anything
to
to
it,
because
it
just
made
me
feel
a
little
bit
like.
Oh
okay,
that's
fine
I
knew
you
have
to
do
this,
but
that's
all
right.
It's
just
something
very
basic.
We
should
probably,
unless
specifically
ask
like
probably
try
not
to
go.
Go
there.
That's
that's
what
I
usually
do.
A
E
E
Even
if
it's
about
a
super
basic
thing,
you
assume
they're
super
smart,
but
just
haven't
seen
that
yet
so
like
have
that
mindset,
even
though
they're
quite
like
the
asking
a
super,
simple
question
and
like
the
first
consume,
I
was
like:
how
can
they
not
know
that
so
yeah
just
assumed
they're
super
smart
and
they
will
get
it.
They
just
need
information,
but
what
I
also
try
to
do
is
like
not
just
yet
like
pushing
that
basic
information
that
people
that
maybe
link
a
resource
and
then
ask.
B
A
Yeah
yeah
I
I,
that's
a
really
really
great
rule.
I
love
that
and
I
think
that
that's
really
I
think
that
should
apply
to
how
we
talked
to
the
wider
community
of
assuming
everyone's
really
smart,
very
capable
software
engineers,
so
that
first
round
of
review
will
make
suggestions,
but
then
yeah,
if
they
have
questions
or
need,
need
help
with
anything.
That's
great!
That's
just
the
one
little
gap
of
knowledge,
we'll
we'll
focus
on
I
love.
That
idea.
D
I
mean
people
miss
things
all
the
time
I
think
like.
If
you
see
something
that
is
like.
Oh,
this
is
a
bit.
This
is
a
bit
weird
like
then
it's
it's,
maybe
it's
because
they
had
a
bad
day
or
like
they
just
missed
it
like
it
happens
all
the
time,
so
I
never
like
I,
never
think
less
of
people
when
they
send
me
something
slightly
easily
unless
it's
like
really,
but
that
never
happens
it
just
yeah.
With
with
this
level,
it
never
happens
really.
A
A
A
A
lot
which
I
do
think,
goes
a
long
way
of
help,
setting
the
tone
of
a
comment
because
often
I'm
just
leaving
a
suggestion,
but
I
won't
ask
questions
and
I
just
leave
a
suggestion
and
I
love
it
when
it
gets
rejected
because,
like
yes,
I
was
just
trying
to
leave
a
suggestion,
not
saying
you
have
to
do
it.
This
way.
B
Yeah
I
feel
I
feel
like
I
want
suggestion
to
be
like
a
conversation
starter
and
not
necessarily,
unless
it's
like
you
know,
I
I've
tried
to
start
using
issues
when
it's
like.
Oh,
this
is
an
issue
type
of
conventional
comment
like
you
need
to
fix
this
because
it's
violating
some
like
gitlab
rule
versus
like,
and
this
might
be
done
better.
B
A
No,
this
is
just
a
to-do
like
we,
this
violated
something
or
we
have
a
yes
lent
thing
where
DS
we're
disabling
here
or
rubal
cob,
whatever
I'll
leave
to
Do's
I'll
I'll.
Do
that
as
a
comment,
because
it's
like
this
is
an
issue.
I
can't
merge
it
without
this
and
it's
just
something
we
gotta
polish
up
or
do
whatever
so
I'll
leave
to
do
comments
that
can
be
helpful
too
yeah.
It's
we're
we're
at
time.
Sorry
I
know!
Casa!
You
had
a
a
last
question
here.
A
A
But
even
when
we
just
have
the
data
that
initializes
the
app
we've,
we
had
a
large
security
issue
because,
rather
than
rendering
just
a
slice
of
the
project
model,
we
actually
accidentally
sent
the
whole
project
model
down
in
the
Hamel
and
I
could
say
this
because
the
issue
is
public
now
but
and
we
resolved
it
and
put
in
Gates
to
prevent
that
but
yeah
it's
something
that
we
have
to
keep
an
eye
on.
That's
a
good
question.