►
From YouTube: Code Review Weekly Workshop - May 05, 2023
Description
In this session we discuss some topics related to code review.
00:00 - Intro
00:20 - Best way to knowledge share hidden rules
06:12 - Diving into sufficiency of specific policy/ability checks
17:50 - A non-blocking follow-up situation
26:50 - "What if author wants to do follow-up themselves?"
35:57 - "By default do we feel like MR's are a battle?"
A
View
weekly
Workshop:
let's
talk
about
some
code
review
topics,
speaking
of
code
review
topics:
does
anybody
have
one
of
those.
B
I
have
a
question:
that's
kind
of
related
to
the
code
reviews
I
keep
doing
with
all
of
the
AI
stuff.
That's
happening.
I
am
continued
to
get
Mrs
where
there's
like
there's
often
for
the
AI
features,
people
will
create
a
license
flag
and
then
also
a
feature
flag.
B
I've,
never
done
that
before
and
I
feel,
like
a
lot
of
other
folks,
haven't
done
that
before
the
names
cannot
be
the
same,
but
it
keeps
like
it's
like
delaying
the
Mr
reviews
because
it
keeps
coming
up
and
every
time
I
have
to
send
it
back
to
them
and
be
like
hey.
These
can't
be
the
same,
there's
even
like
now
pipeline
that
will
fail,
but
I
think
that
often
gets
missed
too,
because
I
have
an
MR
to
look
at
today
where
I
look
at
it
in
the
pipeline
test.
B
That
Dimitri
added
is
failed
because
the
names
are
the
same,
but
is
there
like
a
different
way
that
we
can
like
float
this
kind
of
information
up
like
I?
Don't
know
where
to
blast
it
out,
because
I
feel
like
it's
delaying
these
things,
everyone
wants
to
Mrs
reviewed
in
fast.
You
know
like
there's
a
big
frenzy
and
it
is
delaying
the
review
time
for,
for
that.
A
B
B
B
B
A
B
C
A
B
A
I
mean
so
I
think
yeah.
That
would
be
one
idea.
The
other
idea
is
yeah.
If
you
need
to
just
announce
something
in
the
docs
and
try
to
make
it
a
little
bit
more
public
and
like
a
reminder,
getting
engineering
managers
to
see
it
kind
of
helps,
information
trickle
down
a
bit
more
effectively,
so
I,
sometimes
I'll
talk
to
my
manager
of
like
hey.
A
Can
you
make
sure
everyone
knows
this
and
then
David
will
somehow
because
he's
talking
to
other
engineering
managers,
he'll
talk
to
them
and
that's
One
Way
information
can
get
trickled
down
a
little
more
effectively,
but
now
that
brainstorm
is
if
they
have
to
always
be
named
differently.
Maybe
we
can
address
that
problem
by
consistently
naming
them
like
finding
some
consistency
to
apply
to
each
name
differently
like
what,
if
we
called
feature
flags
have
to
be
called
feature
flag
or
something
like
yeah.
B
A
B
I
might
take
the
route
of
at
least
posting
in
a
few
of
the
development
channels
and
see
if
that
helps,
I
mean
it's
not
that
big
of
a
deal
I
can
look
at
the
migrate.
I
can
look
at
the
field
thing.
It's
just
I
feel
like
it
adds
time
already
that
you
get
a
lot
of
back
and
forth
and
if
I
could
avoid
that.
That
would
allow
me
to
like
get
this
Mrs
merge
faster.
B
On
why
there's
a
long
there's,
a
link
from
the
docs
to
some
other
issue
that
has
some
long
discussion
on
it
that
we
don't
need
to
go
over
here.
But
if
anyone
is
interested,
there's
a
discussion
on
there.
A
Okay,
cool
yeah
thanks
thanks
for
bringing
that
up.
Does
anyone
else,
have
any
other
topics
or
things
to
show.
A
I
actually
think
I
might
so
I'll
show
something.
A
C
D
D
The
admin
mode
feature
is
toggled
on
and
off
via
the
button
on
the
old
nav
bar.
We
are
now
adding
a
toggle
to
the
new
navbar.
So
basically,
when
you're
an
admin,
you
should
be
able
to
see
the
I
think
you
should
be
able
to
see
the
enter
admin
mode
and
then
the
leave
admin
mode.
D
In
the
code,
it's
basically
like
adding
different,
different
links
to
like,
depending
on
the
situation.
If
you
are
in
admin
mode
already
and
then,
if
you're
not
in
admin
world
but
you're
an
admin,
then
you
get
the
oh
enter
admin
mode.
So
the
the
one
tricky
thing
about
SMR
is
that
the
the
person
that
has
written
this
Mr
has
added
these
lines
into
the
the
the
spec
files.
D
So
one
is
in
the
EE
sidebar
helper
spec
and
the
other
one
is
the
non-ee
I
believe
also
Side
by
sidebar
helper
spec
and
he's
added
both
of
these
lines
here.
So
basically,
he's
he's
made
sure
that
the
person
is
authorized
when
they
get
to
when
they
get
to
basically
this
page,
so
so
I
guess.
My
question
was:
is
this
enough
for
us
to?
D
Because
if
you're
not
authorized,
this
is
going
to
throw
an
error,
and
so
because
it
will
say,
you're,
not
you're,
not
an
admin
and-
and
so
I
asked
we've
added
these
checks
in
the
specs.
So
each
spec
is
currently
making
sure
that
we're
dealing
with
an
authorized
user,
but
we
haven't
really
changed
anything
in
the
code
to
to
make
sure
of
that.
If
that
makes
sense,
so
we've
plastered
this
check
here.
D
If
someone
is
in
an
admin
mode,
which
is
probably
the
reason
why
I
think
it's
still
all
right
but
but
yeah
like.
If
you
are
in
admin
mode
and
you're,
not
an
admin,
then
you
will
get
an
error
and
I
said.
Would
this
cause
a
problem
in
like
run
time
in
Spec,
obviously
with
fixed
that
we
make
sure
they're
admins,
but
in
the
runtime
like
what
are
the
odds
that
someone
is
going
to
come
across
this
and
not
be
the
admin
and
then
get
like.
D
And
also
like
for
for
the
case
of
adding
more
specs,
so
basically
the
in
the
spec
we
had
and
do
let
me
know
if
you
have
questions
or
if
I'm
like
not
making.
C
D
Sense
so
both
of
the
specs
are
adding
this
like
authorization,
so
we're
making
sure
that
the
the
person
is
actually
an
admin
and
we're
checking
all
the
links.
Great
then
we're
saying
if
you
are,
if
the
admin
mode
is
enabled
then
and
the
admin
mode
is
on,
and
you
are
the
admin
then
great
and
if
it's
off,
but
you
obviously
still
the
admin.
So
there
is
not
not
a
check
here
in
the
spec.
What
happens
if
you're
not
a
admin,
for
example
yeah.
A
A
And
I,
ideally,
if
you're,
not
an
admin
like
looking
at
the
ifs
like
we
just
wouldn't
show
the
button
and
so
it'd
be
great
to
have
that
check
because
yeah
we
have
three
conditions
here.
A
D
A
D
Yeah,
okay,
I'll
quickly
jump
into
the
code
and
close
this
off.
D
D
D
Oh
yeah,
it's
defined
elsewhere,
I
just
wanted
to
kind
of
jump
in
and
make
sure
that
we
are
in
the
same
kind
of
Panther
link.
Great,
so
header
link
is
basically
calling
this
header
links.
A
D
D
D
Sorry
at
this
point,
current
user
mode
needs
to
be
defined
and
if
we
don't
actually
add
those
lines
to
authorized
users
in
the
spec
it
breaks.
Here
is
what
happens
but,
as
you
said,
if
we
checked,
if
we
check,
let's
say
header
link
admin
modes
like
if
we
checked,
if
the
current
user,
maybe
is
also
a
thing
no,
but
then.
A
I
I
think
I
think
we're
somewhat
guaranteed
for
current
user
mode
to
not
be
knowledge.
So,
if
I
look
at
where
current
user
mode
is
defined,
it
looks
like
there
is
a
concern
that
tries
to
always
initialize
this
thing,
but
current
user
I
think
that's
the
case.
A
I'm
I
would
be
most
concerned
about
if
I'm
not
signed
in
and
the
admin
on
setting
is,
is
on
what
happens
and
are
we
are
we
bombing
up
having
to
set
current
user
mode
makes
sense,
because
in
the
production,
when
the
production
code's
running
I
think
that's
an
assumption
that
this
is
truthy,
so
I
think
yeah.
We
gotta
kind
of
set
that
up
make
sense.
D
Not
the
author
kind
of
said
that
for
anonymous
sessions,
the
admin
menu
is
never
loaded,
and
this
is
obviously
a
a
sidebar
that
is
loaded
for
admin
at
the
moment,
only
so
so
I
kind
of
said
okay,
so
we
probably
need
to
have
a
test
elsewhere
that
this
sidebar
doesn't
show
at
all
to
a
non-admin
user.
Therefore,
we
don't
need
to
have
these
like
waterfall
spec
down
below,
because
at
that
point
we
have
already
checked
that
makes
sense.
A
D
A
Dig
for
them,
I,
think
I,
think
yeah
I
think
we
should
have
them
I,
don't
I,
don't
think
I
know
we
have
them
for
the
the
super
sidebar
yeah
as
I.
Look
at
all
as
I
look
at
this,
and
if
you
go,
if
you
expand
up
the
code
on
like
go,
keep
scrolling
up
just
slightly
a
little
bit.
If
you,
if
you
go
press
it
up
to
expand
the
code
just
a
little
bit
above
line
317
whatever
that
up
arrow
thing,.
B
B
A
A
But
yeah,
that's
that's
that's
that
is
interesting,
but
I
think
it
makes
sense.
The
question
you
brought
up
about
the
spec,
adding
with
the
current
user
mode
I,
have
no
idea
what
that
is,
but
when
I
just
looked
up,
where
is
it
defined,
I
could
see.
Okay,
this
is
kind
of
expected
to
always
be
in
the
environment,
for
these
helpers
and
so
yeah.
That
makes
sense
our
spec
setup
kind
of
has
to
duplicate
some
of
that
stuff.
A
For
bringing
it
up,
yeah,
that's
interesting.
Okay,
I
had
something
small,
so
there's
a
huge
amount
of
priority
placed
on
these
remote
development
features
and
there's
a
lot
of
work.
That's
scheduled
for
it
to
ship
within
16-0
behind
the
feature
flag.
All
of
it
is
that
you
know
unfortunate
pressure
that
happens
sometimes
the
here's.
What
I
originally
ran
into
and
I
wanted
to
share
how
I
approached
it
which
went
really
well.
A
A
What
did
I
leave
my
my
cool
comment?
Oh
here,
we
go
okay,
so
previously
yeah.
Let
me
see
if
I
can.
Oh
I
could
just
look
at
this,
so
when
Enrique
made
this
Mr
to
help,
simplify
and
and
it
did
have
a
it-
was
simple
following
and
reading
it,
but
for
this
table
view
we
basically
have
buttons
to
control
each
of
these
workspaces
based
on
their
state,
sometimes
they're
visible
and
sometimes
they're,
not
and
they're,
going
to
do
things
like
restart
the
workspace
start.
A
The
workspace
stop
the
workspace
terminate
the
workspace,
all
sorts
of
actions.
We
see
that
each
one
has
its
own
component
and
it's
kind
of
doing
its
own
is
redefining
this
common
structure
of
like.
Are
we
visible
and
then
what
happens
when
we
click
on
it
and
I?
I
know
that
when
we
do
this,
sometimes
we're
choosing
to
prefer
very
simple
components
versus
an
abstraction
that's
hard
to
follow.
A
Knowing
that
I
think
we
can
there's
a
better
way
to
do
this,
but
I
wanted
to
highlight
that
to
me,
given
the
priority
of
what
was
going
on
and
other
things
rather
than
coming
up
with
the
patch
and
applying
it
here
or
bringing
putting
it
here
and
suggesting
it
like
that,
because
other
Mrs
were
like
dependent
on
this
Mr
and
stuff,
and
this
is
all
behind
a
feature:
flag,
I
went
ahead
and
left
the
suggestion,
as
non-blocking
and
I
didn't
know
how
Enrique
felt
about
it.
I
was
imagining.
A
Maybe
we'd
have
some
back
and
forth
about
this,
so
I
I
opted
to
create,
rather
than
I'm,
going
to
work
on
creating
a
patch
for
Enrique
I'll,
just
create
a
follow-up
bit
more
to
this
and,
and
that
went
really
well.
Is
it
it
didn't.
Take
me
to
take
me
long,
because
it
would
take
me
about
the
same
amount
of
time
as
me.
A
Creating
a
patch
and
I
just
ping
Enrique
on
it
and
we
can
collaborate
on
it,
but
I
don't
know
if
you
all
ever
find
yourself
when
you're
reviewing
code
picking
upon
yourself
to
do
some
sort
of
follow-up
on
the
code
that
you've
reviewed
but
I
recommend
it.
It's
it's
helpful
and
I
think
it
leaves
positive
feeling
towards
everybody
that
hey
we're.
We're
could
be
working
on
this
thing
together
and
things
aren't
blocked
or
have
that
feeling
of
being
blocked
when
maybe
there's
polishing
improvements
that
could
be
made.
A
B
C
And
I
think
it's
a
fantastic
example,
because
one
one
additional
thing
it
does:
it
does
not
blow
up
the
actual
amount.
So
you
will
be
as
the
auto.
You
will
be
getting
this
good
feeling
to
get
something
done,
which
is
absolutely
good
and,
as
it
seems
to
me,
a
super
valid
iteration,
but
helping
them,
and
not
forgetting
about
follow-ups
and
like
tidying
things
that
we
need
to
do
afterwards.
D
Just
a
question
so
was
this
more
of
you've
mentioned
improve
long-term
maintainability,
so
you
would
be
more
of
a
refactor
rather
than
changing.
The
future
is.
A
Yeah
I
I,
don't
I
I,
have
to
I
run
a
challenge
of
doing
too
much
so
I
have
to
figure
out.
You
know
when
when
should
I
get
involved,
when
should
I
not
for
my
own
sake,
but
at
the
same
time
it's
like
I
hesitate
to
just
create
follow-up
issues
because
some
they
just.
A
A
B
If
the
title
of
the
issue
stays
like
follow
up
from
whatever,
and
then
the
description
has
just
the
link
I
often
will
assign
in
the
follow-up
to
myself
and
make
sure
I
go
back
and
like
fill
it
out
properly,
with
what
should
be
done
and
just
double
check
the
labels
and
whatnot,
but
even
though
I
mean
I
feel
like
if
you
feel
strongly
enough
about
something,
and
it
is
a
I,
don't
often
create
follow-up
Mrs,
yes
for
docs,
maybe
because
the
documentation
stuff
bogs
me
when
stuff's
not
like
quite
right.
Yeah.
A
For
I
think
for
me,
I
I
have
to
take
a
whack
at
it,
so
I
I,
usually
I
my
days,
I
set
a
timer
when
I'm
gonna
do
something
so
that
I
know
how
much
time
has
passed
and
if,
after
taking
a
whack
at
it,
I'm
running
into
obstacles
and
I
can't
figure
it
out.
Then
I
was
like
okay.
I
need
to
create
an
issue.
I
need
to
walk
away
from
this,
but
I
don't
know
for
me.
A
A
B
Mean
anything
that
goes
along
with
gitlab's
values,
though
everything
is
supposed
to
start
with
an
MR,
so
I
think
if
that's
the
easiest
route
to
get
it
done,
but
I
do
like
the
idea
I'm,
so
terrible
about
going
down
rabbit
holes
like
the
timer
idea
is
cool.
Do
you
give
yourself
like?
Is
there
just
like
okay,
I'm
gonna
set
this
thing
to
go
off
in
an
hour,
or
is
it
kind
of
dependent
on
what
you're
working
on
that's.
A
A
good
question,
so
what
works
for
me
and
I
say
this
because
I
have
some
some
levels
of
ADHD
which
come
with
some
time:
blindness.
B
A
That
I'll
easily
spend
three
hours
on
something
and
not
realize
the
I
have
a
timer,
that's
set
for
10
minutes,
and
that
just
helps
me
know.
It's
like
helps
me
tick.
How
many
10
minute
blocks
I've
spent
on
a
thing,
because
I
may
give
myself
an
hour
on
something,
but
I
really
want
to
know.
Do
I
have
30
minutes
left
on
this
or
whatever,
but
often
I
mean
if
I'm
writing
Mr,
like
that,
it's
very
rarely
that
I'm
probably
doing
that
kind
of
refactoring
for
an
hour.
A
D
Just
to
bring
like
another
perspective
so
you've
mentioned
in
that
comment,
let
me
just
create
an
like
another
issue.
What
if
the
author
would
like
to
do
it
themselves?
What
if,
since
they're
touching
the
code-
and
they
know
what's
going
on,
maybe
they
would
prefer
to
do
it
themselves
or
being
asked
like?
D
Would
you
like
to
do
it
or
do
you
know
what
I
mean
because
you're
gonna
refactor
something
that
he's
just
written
and
it
might
feel
a
little
bit
like
like
you,
take
over
and
he's
not
done
a
great
job,
so
to
speak
so
yeah.
C
A
C
Well,
I
can
only
speak
for
myself
as
if
I
really
wouldn't
mind.
That's
definitely
not
no
I'm,
not
sure.
If,
if
we
should
bring
a
lot
of
ego
into
this
I
personally
would
be
absolutely
okay
with
that,
and
I
would
also
take
into
account
this
we're
speaking
about
rather
small
things
as
if
in
like,
if
I
would
be
the
author
I
would
have
already
collaborated
with
the
reviewer
on
this.
So
we
kind
of
all
all
on
the
same
page.
C
We
know
which
kind
of
Direction
this
is
going
to,
and
then
he
or
she
just
like
put
it
put
the
work
in
and
change
the
files,
so
I
would
be
okay
with
that,
where
I
would
definitely
be
hesitant
about
if
there
would
be
a
decision
where,
like
different
opinions,
would
absolutely
be
okay,
if
Paul
would
come
in
and
be
like
yeah.
This
is
great,
but
ux
sucks
like
these
colors
that
I
put
in
there
I
like
them
much
better.
Here
you
go.
C
B
Yeah
I
don't
mind.
Mine
I
feel
like
once
I'm
done
touching
code,
there's
very
much
someone
that's
coming
behind
me
like
a
little
Pac-Man
to
like
turn
it
through,
whatever
they
think
is
best
and
then
I
come
back
and
it's
different
and
I'm
like
okay,
but
I,
don't
know
like
I.
Try
not
to
have
an
ego
when
it
comes
to
code,
stuff,
I,
don't
really
I
mean
my
I.
Don't
know
my
main
goal
is
like:
is
it
working
and
did
I
have
to
do
like
if
I
don't
have
to
do
anything?
C
B
Got
like
one
less
thing
on
my
plate,
so
yeah
I've
worked
on
like
code
bases
with
enough
people
at
once,
just
to
realize,
like
once,
it's
merged,
there's,
no
guarantee,
and
next
time
you
open
the
file.
It's
gonna
look
like
that
anymore.
Yeah.
A
I
I
could
think
of
some
cases
where
I
would
potentially
be
start
to
get
irritated
would
be
if
it's
not
if
the
scope,
maybe
is
clear,
but
is
so
preference
based
and
if
it's
like
someone
is
wanting
to
change
it
to
a
style
that
they
prefer
and
there's
no
maintainability
difference
between
ours
and
I
can
actually
think
of.
Maybe
a
couple
of
maintainability
issues
with
what
they're
trying
to
change
it
to
I
would
be
frustrated
if
this
happened,
if
they
were
like
I'm
gonna
create
an
MR
to
do
this.
A
My
way
they
created
a
mar,
and
they
don't
ping
me
on
it,
like
all
of
that,
would
seem
like
we're
not
being
collaborative
or
transparent,
which
is
funny
because
foreign
they're
literally
collaborating,
but
something
about
it
is
off.
So
that
would
be
irritating
and
one
of
the
reasons
I
I
I
was
intentional
with
the
way
I
worded
this
to
Enrique,
saying
I'll
create
a
follow,
Demar
and
we'll
move
the
discussion
there,
because
I
wasn't
sure
how
Enrique
would
feel
about
it
because
I
also
know.
A
Sometimes
we
highly
prefer
to
simple
components,
and
there
might
be
something
I'm
missing.
So
to
me
it's
like,
rather
than
just
talking
about
all
this
here,
let's
talk
about
it,
Mr
I
could
put
together
the
code
and
we're
still
gonna
be
collaborating
transparently
on
this.
That
I
think
is
a
key
factor
of
keeping
the
people
that
were
involved
in
it
still
in
it,
and.
B
C
I
I
might
have
a
slightly
different
different
check
on
this,
and
you
just
make
maybe
I
guess
the
most
important
Point
very
clear
that
I
as
the
author
and
you
would
open
up
this
Mr
I
would
expect.
I
would
expect
to
be
assigned
as
a
reviewer
kind
of
within
the
process,
because,
like
the
point
that
you
just
made
when
there's
like
something
that
is,
that
is
highly
opinionated
like
you
would
go
in
and
open
up
a
follow-up
refactor
is
refactoring.
C
This
thing
to
something
that
you
like
better
as
the
offer
I
would
see
a
huge
benefit
in
getting
this
discussion
out
of
the
way
of
the
actual
main
Mr,
but
yeah.
The
the
most
important
thing
for
me
would
be
if
you
still
have
a
chance
as
if
in
like,
hey
I
will
maintain
this
for
a
bit
or
I.
Do
I
do
think.
Well,
this
is
about
opinionated
stuff
I'm.
On
the
other
side.
Let's
please
not
do
that
so,
but
moving
this
discussion
away
from
the
main
thread,
probably
a
good
idea.
A
Cool
well
yeah,
thanks
for
letting
me
share
that
thanks
for
the
interesting
discussion
on
it,
I
think
I
think
decisions
that
we
make
can
make
a
big
difference
to
how
people
feel
when
it
comes
to
creating
Mrs.
If
they
feel
like
this
is
going
to
be
so
heavy
and
full
of
friction,
I
don't
want
to
do
this
versus
hey
we're,
collaborating
and
people
want
this
stuff
to
get
merged
and
how
we
decide
to
follow
things
up
can
make
a
big
difference.
D
Yeah
that
person
is
actually
nice,
but
when
they
leave
a
comment,
the
comment
is
a
little
bit
strange,
but
still
fine,
because
you
know
them
in
person
or
you've.
You
know
interacted
with
them,
but
because
we
don't
know
each
other
and
we
don't
almost
never
interact
with
each
other.
You
only
get
the
comment
and
if
the
comment
is
somewhat
like
I've
received
some
comments
in
the
past
that
were
a
little
bit
called
or
a
little
bit
like
and
I
know.
I
should
not
take
it
personally,
but
because
I
don't
really
know
that
person.
D
B
Interact
otherwise
so
yeah,
it
is
hard
and,
as
coming
from
the
side
of
like
I,
tend
to
be
more
like
direct
and
maybe
not
like.
Like
I,
don't
know
what
the
right
like
English
word
is,
but
sometimes
I
worry
that
when
I
make
comment,
I
go
back
and
read
it
and
just
make
sure
before
I
submit
it,
because
it's
not
trying
to
be
rude.
It's
just
like
this
is
a
factual
comment
and
I'm
like
okay.
B
I
need
to
try
to
make
this
nicer
like
how
this
person
can
interpret
it,
because
it
happens
to
me
like
when
I'm,
in
a
person
too,
with
my
husband
and
just
with
General
people,
where
I
make
like
a
statement
because
I'm
like
this
is
a
fact
and
it
doesn't
always
get
received
like
in
the
best
way.
B
So
yeah
I
appreciate
from
the
other
side
hearing
you're
like
working
on
that
side,
but
just
know
that
I
think
for
most
people
like
I'm,
always
trying
to
make
sure
if
I
give
a
comment.
I'm
like
okay
is
this
like
do
I
need
three
pointers:
yeah
I
I
feel
like
gitlab
that
people
do
that
I
hope.
A
Yeah
there's
some
yeah
a
lot
of
people
I
think
put
a
lot
of
I
think
we
have
a
good
blend
of
both
on
the
reader
side,
trying
to
assume
positive
intent
and
on
the
writer's
side,
there's
a
good
amount
of
effort
put
into
how
do
we
communicate
best
asynchronously,
which
is
a
hard
problem,
but
we
have
to
do
I.
Do
think,
love
to
hear
what
you
all
think
on
this
by
default.
A
B
B
You
know
I
I,
don't
know,
I
try
to
combat
things
by
like
leaving
little
notes
where
I
look
at
it
and
like
this
might
be
confusing.
Let
me
like
leave
a
notice.
Why
I
did
that,
because
I
often
will
get
questions
back
because,
like?
Why
did
you
do
this?
And
so
but
yeah
I
have
heard
that
feedback
from
people
I,
don't
I,
don't
personally
feel
that
way
as
a
reviewer.
B
If
I
go
into
Mr
and
I,
see
like
92
things
at
the
top
I'm
just
like
cry
a
little
bit
on
the
inside,
because
then
I
don't
want
to
review
it,
but
I
don't
know
how
often
that
happens.
D
With
something
and-
and
you
have
feeling
that
it's
a
strong
feeling
would
say
that
that
it
should
go
that
way
and
not
the
other
way,
but
then
and
then
you
mention
it
so
I
last
time,
I
had
a
situation
where
someone
added
some
methods
to
a
class
and
made
them
a
majority
of
them
public,
even
though
they
didn't
need
to
be
public.
Only
one
of
them
needed
to
be
public
and
the
rest
could
be
private
and
I.
D
Just
left
a
quick
note
like
can
we
maybe
make
these
private
and
the
the
author
came
back
to
me
saying
like
oh,
but
then
there
are
other
methods
in
that
class
that
are
also
public
and
they're
similar
and
then
maybe
potentially
I
think.
Theoretically,
they
could
be
useful
is
what
he
kind
of
responded
with.
D
But
then
he
kind
of
didn't
really
speak
to
me
because
at
the
end
of
the
day
like
for
maintainability
refactoring,
like
all
of
those
things,
it's
just
better
to
keep
them
private,
but
it
would
be,
and
I
did,
I
did
get
back
to
him
again.
Sometimes
I
drop,
it
I
I
think
like
if
I
don't
feel
that
strongly
about
it.
Maybe
someone
else
is
gonna
pick
it
up
and
mention
it,
and
then
it's
gonna
be
more
like
okay.
D
There
are
two
people
that
are
vouching
for
this
thing,
but
if
I
feel
a
little
bit
strong
about
some
things
like
this,
what
I
just
mentioned,
then
I
I
go
back
to
him
with
like
more
reasons.
Why
I
think
it's?
It
would
just
be
better
to
to
to
do
that.
So
I
didn't
feel
like
it
was
a
battle,
but
I
felt
that
it
would
be
hard
for
me
to
approve
something
that
I
I.
Think
that,
on
like
a
pre
like
Elementary
level
would
be
not
good.
If
that
makes
sense
and
I
didn't
know.
C
What
I
tried
to
do
in
those
situations
or
similars
is
well
when,
when
I
do
review
day
or
in
in
such
a
situation,
this
can
kind
of
go
two
ways
one.
This
would
be
a
rather
an
issue
that
I
feel
opinionated
about.
If
that
is
the
case,
I
don't
really
care
because,
as
a
web
viewer
that
I
I
don't
consider
this
to
be
my
job.
To
leave
this
thing
in
in
a
state
that
I
really
like
I
consider
it
should
be.
C
It
should
be
to
sing
in
the
state
that
works
and
does
apply
to
our
standards.
So
opinionated
I
probably
wouldn't
even
start
a
discussion.
If
there
is
something
regarding
to
our
standards,
then
a
link
to
a
handbook
goes
a
long
way
being
like
hey.
This
shouldn't
be
public,
because
it
does
not
really
apply
that
that
well
to
what
we
have
put
down
here
and
if
we
are
missing
it
then
just
go
ahead
and
open
up
my
Mr
on
this.
So
next
time
you'll
be
you'll
be
covered
on
this.
C
But
what
I'm,
trying
to
say,
I,
really
try
I'm,
really
trying
to
to
avoid
this
discussion.
Just
based
on
on
statements
to
make
I
really
try
to
kind
of
make
my
argument
with
the
with
the
handbooking
blocks
that
we're
having
that.
That
really
makes
makes
it
a
lot
easier.
Then.
B
For
that
specific
one,
not
directly
I've,
actually
gotten
the
same
exact
response
to
the
same
exact
requests
and
Mr
reviews
and
I
end
up
just
letting
it
go,
because
the
argument
like
it
almost
does
feel
like
an
argument.
At
times.
It
feels
like
it's
getting
into
argument
territory
and
I,
don't
I,
don't
I
like
it
really
feels
like
a
personal
preference
at
that
point.
B
For
that
specific
private
public,
it
is
in
the
Ruby
style
guide
like
do
not
make,
but
like
I
link
that
it
doesn't
it
didn't
it
doesn't
matter.
Sometimes
it
doesn't
matter
if
the
person
is
on
the
other
side
that
feels
very
strongly
about
it,
and
so
yeah
I
have
to
fall
back
to
like.
B
A
Would
block
an
MRI
in
that
yeah
I?
If,
if
it's
so
easy
because
to
me
it's
like
this
is
so
easy
to
fix
and
there's
good
evidence.
This
is
the
thing
to
do
and
if,
at
that
point
you're
choosing
not
to
then
what
all
that
you're
really
doing
is
choosing
to
choosing
your
preference
over
some
level
of
efficiency
and
collaboration.
So
yeah.
B
A
Yeah
I,
don't
know
I,
that's
a
good
question
and
I
think
I
find
myself
employing
a
more
direct
tone
like
I'll
start
with
the
question
and
then,
if
I'm,
like
okay,
you're
reasoning,
back
I'm,
not
convinced.
Let's
just
do
this
I'll
change
to
hey,
we
don't
have
a
good
reason
to
leave
the
style
guide
here
and
I.
Think
it's
important
that
we
do
this
and
this
is
an
easy
fix.
A
If
you
want
to
get
another
review
or
maintainer,
that's
fine
like
to
me,
even
if
it's
something
small
like
that,
if
someone's
being
I
don't
know
somewhat
uncollaborative
on
a
thread
is
like
okay,
we're
we're,
not
I'm,
not
the
one
holding
this
up.
If
that
makes
sense,
because
I
I
do
feel
like
as
an
MR
author
I
need
to
be
very
very
open
to
all
the
changes
on
my
M1,
because
I
want
to
be
accommodating
to
other
people
feeling
like
they
can
own
the
code.
None
of
it
is
my
code
as
like.
A
Terry
was
talking
about
I'm,
so
hopefully
I
brought
up
the
example
like
does
anyone
feel
like
merge?
Requests
are
a
battle
I
think
they
turn.
They
could
feel
like
that
when
things
like
that
happen,
but
beforehand,
hopefully
they
just
feel
like
no.
This
is
just
asynchronous
collaboration
and,
as
an
MR
author
I
try
to
be
super,
accepting
of
whatever
other
people's
style
preferences
are,
is
just
like
yeah,
let's
make
this
ours,
let's
not
make
it
mine.
A
Maintainability
sometimes
you'll
get
suggestions
that
violate
one
of
those
principles,
that
kind
of,
and
so
that
opens
up
a
discussion
and
hopefully
then,
at
that
point
we're
discussing
like
we
would
on
a
call
of
how
you
know,
here's,
why
I
did
this
and
I'm
following
this
guide,
and
this
is
where
yeah
looking
for
resources,
including
the
docs,
but
also
auxiliary
resources
like
the
Ruby
style
guide
or
I,
often
quote,
like
Martin,
Fowler
articles
and
stuff
for
like
why
I'm
choosing
some
sort
of
pattern
or
whatever
and
all
of
that
to
create
a
why
I'm
not
eager
to
adopt
a
change
and
I
very,
very
rarely,
will
I
have
the
reviewer
dig
their
heels
after
you
know,
after
that,
back
and
forth
of
of
now.
A
Yes,
it's
those
are
tough
scenarios
that
happen
and
they
do
happen
and
they
can
happen
with
Community
contributors.
It
could
be.
It
could
be
tough
but
trying
to
keep
the
spirit
of
collaboration
up,
but
that
doesn't
mean
you
have
to
back
down.
Like
that's
I.
Think
the
interesting
part
of
it
is:
how
do
you
it's
it's
possible
to
to
keep
the
collaboration
culture
while
standing
firmly
on?
A
Yeah,
that's
tough,
that's
easier.
A
B
Never
well
I've,
never
blocked
anymore.
No
and
no
I
have
asked
multiple
times
for
people
to
split
Mrs
up
and
they
don't.
Okay,.
A
B
A
D
A
Oh
sure,
but,
and
but
part
of
that
is
because
people
feel
a
lot
of
friction
when
it
comes
to
Mrs
like
it
feels.
Okay,
I
can
split
this
up
in
multiple
commits,
but
then
I
have
to
create
a
whole
Mr
and
go
through
a
whole
review
process,
and
so
people
anticipate
a
large
amount
of
friction
with
the
Mrs.
All
right
and
I
think
that's
a
challenge
to
some
of
the
the
ways
we
like
to
iterate.
B
I
almost
want
to
get
those
folks
in
and
just
have
them
like
pair
with
me
on
reviewing
a
large
Mr
and
I
wonder
if
they
would
feel
differently,
but
maybe
they're,
okay
with
large
I,
mean
I,
don't
know
many
people
are
okay
like
when
I
see
a
large
Mr
review.
It
really
makes
me
anxious
and
and
I
worry,
that
I'm
gonna
miss
something.