►
From YouTube: Code Review Weekly Workshop - Aug 12, 2022
Description
In this session we discuss a sundry of topics pertaining to reviewing code at GitLab.
A
It's
too
late
now,
so
I'm
going
to
share
my
screen,
so
we
can
go
through
the
agenda
I'll
be
looking
at
the
same
thing.
So
thanks
for
joining
the
first
code
review
weekly
workshop,
the
intent
of
this
is
knowledge
sharing
what
we
learn
and
gather
during
code
review,
because
a
lot
of
that,
I
think
we
learn
on
the
job
of
code
review,
but
maybe
we
could
be
more
intentional
with
broadcasting
some
some
things
that
we've
learned.
A
I
don't
anticipate
these
to
generate
a
lot
of
discussion
and
I
might
prompt
discussion
to
happen
more
asynchronously,
because
I
want
people
to
feel
really
comfortable
to
bring
things
up
and
not
feel
like
they're
going
to
be
challenged,
and
so
anything
you
want
to
bring
up.
You
don't
have
to
prepare
it.
Please
don't
prepare
something
special,
because
you'll
just
make
others
feel
like
they
have
to
do
that.
A
A
Someone
is
driving
the
rest
of
the
the
mob
are
navigating
and
it's
just
a
lot
of
fun,
but
this
will
be
a
little
different
because
we're
going
to
appear
on
code
reviews,
so
there's
a
little
bit
of
a
challenge
here
where
we're
a
mixed
bag
of
bacon
engineers
front
engineers.
So
the
goal
is
not
to
get
too
technical
because
I
know
back
in
engineers
can't
write
front
end
code.
I'm
sorry
back
in
engineers,
I'm
getting
a
hard
time
front.
A
A
Why
did
we
leave
a
comment?
What
kind
of
comments
is
this
and
all
of
those
decisions
we
make?
We
make
code
review
and
so
we'll
see
what
happens
yeah
all
right.
So
there's
a
couple
of
things
on
the
show
and
tell
agenda
feel
free
to
add
something.
Last
minute
if
you
want
to,
but
I
was
gonna
kick
this
off,
not
pointing
to
the
specific
code
review
I'll,
do
that
on
point
b,
but
I
was
gonna
just
share
my
personal
code
review
process
that
has
helped
me
out
tremendously.
A
A
I
find
that
multitasking
is
a
multitasking,
is
a
trap
for
me,
because
I
will
never
finish
my
original
task,
so
I
have
to
instead
try
to
really
really
focus
so
whenever
I
start
doing
code
reviews,
I'm
shifting
to
code
review
mode.
It
is
really
difficult
for
me-
and
maybe
you
find
this
find
this
helpful.
It's
really
difficult
for
me
to
be
doing
my
own
work
and
then
on
the
side,
doing
a
code
review
or
something
like
that,
and
I
just
won't
get
in
end
up
getting
anything
done.
A
A
So
then
I
also
just
have
bookmarked
a
list
of
the
dmrs.
I
need
to
review
and
I
open
that
up
so
then.
The
other
thing
I
wanted
to
share-
and
this
was
really
helpful
for
me-
and
I
I
have
a
feeling
it
might
be
helpful
for
others
as
well-
I've
I've
recently
gotten
really
disciplined
with
starting
a
timer
when
I
do
code
reviews
now.
A
This
looks
like
a
ridiculous
amount
of
time
to
take
on
a
code
review
and
by
ridiculous
I
mean
ridiculously
small,
but
I
use
like
15
minutes
to
10
minute
increments,
just
to
measure
how
long
something
has
take
taken.
So
if
I
find
myself
having
to
reset
this
like
two
to
three
times
on
one
code
review,
that's
a
really
good
signal
to
me.
I
need
to
try
to
wrap
this
up
and
push
this
on,
because
something
isn't.
A
A
B
A
A
Okay,
once
I
start
the
timer,
that's
when
I'm
actually
starting
on
things
and
I'll
read
the
context,
but
I
also
when
I
say,
read
the
context,
I'm
like
reading
the
description
and
the
other
comments
before
I
jump
into
the
code,
just
so
that
that
context
is
near
the
front
of
my
brain,
but
then
I'll
review
the
code
locally.
I
actually
hardly
ever
review
the
code
on
the
mr
diffs.
I
use
that
to
just
leave
the
comments
but
I'll
curl,
the
diff
from
the
url
and
then
I'll
apply
it
onto
my
master
branch
locally.
A
A
A
A
And
then
I'll
do
just
a
high
level
where
I'm
looking
at
the
test
coverage
of
based
on
all
the
files
we
changed.
I
would
expect
to
see
some
sort
of
like
similarity
with
all
the
unit
tests
that
would
have
changed
and
then
the
line
for
line
read
through
is
where
okay,
I'm
gonna,
I'm
gonna
go
through
every
line
and
there's
might
be
some
gotchas
where
we're
calling
undesirable
patterns
and
methods
with
apollo
libraries
or
other
other
things
like
that.
A
A
C
I
do
have
a
sword
I'd
like
to
share.
First
of
all,
thanks
a
lot
for
sharing
the
snippet
under
three
that
will
probably
save
me
at
least
half
an
hour
in
my
future
days.
I
was
not
aware
of
that,
but
what
I
want
to
do
to
share
is,
I
am
doing
a
very,
very
similar
thing,
but
your
number
seven,
the
manual
testing,
is
actually
my
number
one.
Like
the
very
first
thing
I
do
once
I
have
this
running,
and
this
is
something
that
I
consider
to
be
kind
of
optim.
C
I
personally
would
probably
recommend
because
many
times
I
would
find
issues
in
there
that
will
obviously
affect
the
code
and
it
turns
out
that
a
lot
of
times
we
then
ended
up
changing
code
and
I
maybe
asked
somebody
to
publish
before
so
that
is
something
if
there
is,
if
there
is
a
user
facing
issue,
I
want
to
know
early,
so
I
can.
I
can
adapt
and
maybe
save
some
time
on
the
revenue,
because
maybe
I'll
be
telling
telling
a
person
we
not
gonna
need
just
methods
and
no
need
to
polish.
It.
A
A
I
would
classify
it
as
like
white
box
quality
assurance
where
we're
looking
at
the
code
and
then
we're
test,
then
we're
testing
something,
and
I
find
so
often
I
can
see
a
line
of
code
or
I
can
see
a
pattern,
and
I
can
I
get
a
gut
feeling
that
oh,
this
is
going
to
cause
this
issue
and
so
for
me
often
it
is
from
the
code
where
I
can
easily
predict.
This
is
what
I
need
to
test.
So
that's
why
I
do
put
this
at
the
end,
but
yeah.
A
D
I'll
start
racing
in
handy,
because
there
are
many
of
us
so
like
whether
you
always
do
this
manual
testing.
I
don't
usually
like
most
of
the
times
I
do,
but
like
often
it
seems
like
the
change
might
be
so
small
and
like
there
is
so
much
to
do
to
set
up
the
environment
which
just
like
go
visit,
you
don't
see
like
anticipate
issues
and
like
most
likely,
they
won't
have
happen.
So
I
was
wondering
how
people
treat
that,
but
you
usually
check
out
the
branch
and
see
what's
happening
or
you
just
like
merging.
A
E
C
A
I,
and
I
think
I
think
we
do
need
to
use
a
level
discretion
because
gosh
so
much
can
go
wrong,
that
you
could
spend
your
whole
life
just
testing
a
small,
mr,
because
there's
so
much
context
that
so
another
reason
like
I
add
this
at
the
end
here
is
usually
I
have
some
specific
things.
I'm
concerned
about.
It's
not
like
I'm
looking
for
it's
not
there
is
the
there
is
the
like
the
happy.
A
I'll
have
a
note
of
things
of
like
I'm
concerned
about
this,
and
so
then
I
can
see
through
the
mr
description
if
someone
did
test
that
path,
but
if
not
there's
nothing
wrong
with
me,
bringing
it
back
to
the
author
of
hey,
just
a
question:
I'm
a
little
concerned
about
this.
We
tested
this
thing
out
under
this
context.
A
Could
you
share
a
screenshot
about
it,
so
I
don't
necessarily
have
to
be
the
one
manually
testing
things,
but
if
I
get
a
feeling
that
like
oh
what
about
this-
let's
not
just
stuff
that
feeling
we
can
add
it
as
a
comment.
Even
a
non-blocking
comment
based
on
based
on
how
it
is-
and
I
think
that's
well
received
what
do
you?
What
do
you
think
laina.
D
I
don't
know
I
want
to
hear
I
want
to
hear
your
thoughts.
I
have
another
scene
so,
like
the
item
number
eight,
you
say
that,
if
necessary,
convert
notes
to
actionable
comments,
so
does
it
mean?
Sometimes
we
just
like
discard
the
comments
that
you
see
like
not
very
important
and
like
not
necessary
because
myself,
if
I
write
a
comment
and
like
I
will
feel
bad.
If
I
don't
leave
this
comment
because
I
say
maybe
it's
not
that
critical,
but
I
will
I
don't
feel
comfortable
comfortable
this.
B
A
I'm
just
thinking
out
loud
I'll
I'll
say
that
a
lot
too
I'm
just
thinking
out
loud,
and
I
think
that,
given
our
values
like
we
want
to
lean
towards
that
level
of
transparency
of
thinking
out
loud.
So
I
I
interpreted
that
to
mean
yes
comments.
Don't
necessarily
have
to
be
actionable.
It's
a
description
of
how
I
want
to
word
the
comments,
but
if
it's
a
non-blocking
thought
I
leave
a
lot
of
those
so
yeah.
This
isn't
that's
a
good
point.
A
Cool
thanks:
well,
I'm
gonna,
I'm
gonna
move
on
to
other
parts
of
our
agenda,
thanks
for
letting
me
share
that,
and
maybe
now
is
past
so
much
time.
That
natalya
will
be
here
to
present
her
point,
but
if
not,
you
all
will
have
to
put
up
with
me
a
little
longer.
I'm
sorry
so
I
wanted
to
share
something.
I
came
across
in
an
mr
from
a
community
contributor.
A
Commit
changes
button
and
it
shows
a
nice
little
loader
now
before
it
didn't
do
that
so
now
it
actually
will
disable
and
show
a
cool
loader.
So
this
thing
works
and
I
actually
like
j
corey.
So
this
doesn't
bother
me
I'm
joking,
but
what
did
stick
out
to
me
was
all
of
these
utility
classes
that
we're
throwing
into
here.
A
A
Putting
these
one
off
here
just
is
not
the
best
maintainable
way,
because,
as
we
change,
what
our
loaders
need
to
do,
we'll
obviously
miss
this
and
there'll
be
some
consistency
issues
or,
if
there's
a
bug
that
we
need
to
fix
with
our
original
implementation.
So,
even
though
this
is
all
working,
this
isn't
the
single
source
of
truth
for
this
kind
of
thing.
So
what
I
recommended
was.
A
Adding
a
hidden
button,
but
using
our
single
source
of
truth
function
to
render
a
button
that's
hidden
by
default,
but
has
the
certain
state
of
where
it's
loading
and
disabled
and
that's
what
the
javascript
will
do,
or
we'll
just
toggle
that
on
and
off
so
we're
having
duplicate
calls
to
this.
But
that's
way
better
than
duplicating
our
encapsulated
logic.
Is
my
thinking
or
not.
So
the
main
point
is
it's
like
hey,
while
we're
looking
at
code
and
understanding,
maintainability,
try
to
identify
and
respect
and
find
ways
to
uphold
single
source
of
truths
or
concepts.
D
I
I
have,
I
have
a
question
so
why
not
just
pull
on
your
reviews
often
leaves
the
likes.
The
patch
to
apply
is
so
I
use
don't
like
the
community
can
contribute
contributors,
because
I
just
don't
want
to
go
back
and
forth.
Sometimes
they
misunderstand
like
what
I
want
from
them
and
they
might
not
have
also
like
internal
knowledge.
A
Yeah,
I
I
end
up
finding
leaving
lots
of
patches
mainly
as
like
a
communication
tool,
because
I
feel,
like
code,
speaks
louder
than
words
so
because
I
review
locally.
Actually
it's
really
easy
for
me
to
create
patches,
I'm
like
looking
at
it
and
I'm
like
this
is
what
it
could
look
like
and
I
generate
the
patch
and
I
paste
it
and
that's
that
workflow
works
really
nicely
for
me,
because
I
don't
have
to
think
of.
I
don't
have
to
try
to
decode
into
grammar
a
change
I'm
suggesting
and
this
interest
really.
A
This
interest
is
a
sticky
situation
where,
with
community
contributors,
this
is
expected,
like
there's
there's
a
little
bit
of
like
mentoring
and
handholding.
That
happens
and
other,
mr
is
like
how
much
has
been
patch
derived
that
maybe
it's
worth
having
another
set
of
eyes,
because
maybe
now
I've
ended
up
contributing
technically
contributing
most
of
it.
But
I
I
my
main
intent
with
patches.
A
A
A
A
So
those
are
always
really
interesting
situations
to
bring
up,
but
the
specifically
the
one
that
she
brought
up
was
this
v
model
is
a
view
directive
that
tells
view
to
magically
keep
this
thing
in
sync
and
will
write
to
this
property
in
the
component
and
we'll
read
it.
The
child
component
will
end
up
reading
from
this
property
too,
but
this
is
actually
not
a
property
or
a
data.
It's
actually
computed
and
that's
a.
A
A
We
need
to
fix
this,
and
so
this
is
the
where
that
nested
property
of
the
computed
object
it's
coming
from,
and
the
v
model
will
keep
writing
to
this
and
we'll
try
to
write
to
the
computed,
and
that
can
cause
view
issues.
So,
what's
tough
is
we
have
linters
for
like
this?
I
think
if
you
just
try
to
throw
a
computed
in
there,
we
have
linters
for
that,
but
for
something
nested
like
it
looks
like
our
linter
doesn't
quite
catch
it,
and
that
also
highlights,
like
the
the
robots
need,
human
oversight.
D
Yeah,
sorry,
so
with
this
kind
of
situation,
like
you
know,
often
like
sometimes
this
is
errors
that
it's
not
not
related
to
the
mr
directly
and
I
often
get
the
pushback
kind
of
like.
I
didn't
touch
that
I
didn't
introduce
that
I
don't
want
to
break
it,
something
something
something
like
that
and-
and
I
I
understand
this
so
if
the
person
comes
to
fix
the
css
cause,
they
don't
want
like
to
fix
the
computed
issues.
Points
for
instance,
because
it's
more,
you
need
to
give
it
more
thought.
D
So
you
go
on
with
creating
is
a
follow-up
who
is
responsible
for
this
follow-up
so
because
I
often
feel
like
you
can
say,
if
it's
my
mr,
I
have
to
fix
it
like.
On
the
other
hand,
if
I
don't
fix
it,
it
will
hang
around
somewhere
and
it
will
be
outdated
in
two
years
the
bot
looking
view
so
how
people
approach
this.
A
A
I
I
make
that
trade-off
decision
of.
Is
it
worth
holding
this
up?
Should
I
push
this
forward,
and
can
I
create
this,
mr
to
fix
this
thing
myself
really
quickly?
That's
one
option
too.
I
think
what
natalya
did
here
also
helps
uphold
a
value
that
we
we
want
to
keep
things
tidy
and
and
so,
rather
than.
A
A
A
Good
yeah,
we
just
we
just
finished
talking
about
it
and
yeah
the
main
takeaway
and
if
you
want
to
chime
in
any
other
takeaways
was
even
though
this
is
this
just
happened.
The
mr
was
changing
not
directly
this.
It
happened
to
touch
it,
we
want
to
keep
things
tidy,
and
so
that's
that's
the.
I
think
that's
a
good
value
to
and
culture
to
continue
to
promote
across
the
code
base,
because
we're
not
going
to
get
to
our
44
000
issue,
backlog.
G
I
think
you
put
it
perfectly
one
addition.
Also
to
this
is
we
shouldn't
hesitate
to
block
a
mars
over
this.
Yes,
if
it's
severity,
one
probably
it's
not
a
good
reason
to
block,
but
in
all
other
cases,
even
though
this
mr
didn't
change
the
logic
in
the
unchanged
lines.
I
still
blocked
it
over
this
and
I
believe
it
was
a
good
idea
because
again,
44
000
issues
and
our
code
base
is
huge,
and
I
believe
this
in
things
out
for
the
follow-up.
G
F
C
I
highly
agree
with
the
with
the
issues
about
these
follow-ups
that
the
target
just
pointed
out.
I
was
wondering
how
do
in
that
context?
How
do
we
treat
documentation
like
if
I
would
be,
or
somebody
would
be
working
on
an
issue
and
we'll
be
finding
out
the
docks,
are
actually
not
adequate?
What
would
you
take?
Would
it
be
acceptable
to
update
docs
in
a
follow-up,
or
would
you
want
to
have
this,
maybe
not
in
the
same
animal
but
basically
having
them
in
sync,.
A
A
A
A
A
E
I
guess
that's
just
a
preference
because
I
feel
like
it
does.
It
could
get
forgotten
or
at
least
having
the
writer
be
able
to
have
the
context
of
the
code
like
they
may
not
be
developers,
but
they
still
provide
a
lot
of
good
feedback
when
everything
is
in
the
same
context,
it
makes
things
easier
to
review.
E
I
also
will
say:
I've
never
had
a
documentation
review
like
hold
up
an
mr,
like
it
has
never
really
blocked
anything
from
merging.
I
try
to
get
them
involved
early.
If
I
go
to
review
something
and
I
see
that
they
haven't
been
involved
I'll,
just
sometimes
just
ping
the
person
and
be
like
hey.
Can
you
also
look
at
this
from
doc?
Because
I
want
to
move
the
mr
along
too,
and
I
don't
want
to
have
to
be
waiting
as
though,
like
a
merger.
A
C
C
F
A
C
B
A
B
B
E
E
But
if
I
find,
if
I'm
looking
at
a
code
review
and
immediately
upon
looking
at
it,
I'm
like
oh
look
at
this
right
now
like
to
me:
that's
a
maybe
a
flag
that
it
could
be
too
big.
I'm
like!
Oh,
I
need
to
come
back
to
this
later.
If
there's
30
files
changed
or
maybe
it
from
the
back
end,
it
does
have
a
database
change
and
if
there's
like
three
or
four
reviewers
on
it
at
once,
like
you
know,
depending
on
what
it
is,
there's
no
hard
there's
no
hard
and
fast
rules.
F
E
A
B
D
B
A
The
there's
somewhere
in
our
docs,
I
I
would
it
is
really
hard
to
break
things
up
when
you
were
breaking
it
up
horizontally.
Slicing
like
we're
gonna,
we're
going
to
add
the
tests
in
one
spot,
we'll
do
the
apollo
code
and
one
mr
we'll
do
the
presentation
code
and
one,
mr
then
one
mmr,
we'll
put
it
all
together
and
that
more
ends
up
being
humongous,
because
yeah
you
happen
to
touch
everything.
A
A
A
So
for
me,
as
a
contributor,
it's
really
helpful.
If
I
know
this
is
gonna,
be
non-trivial,
I'm
just
gonna
do
all
the
changes.
I
think
I
need
to
do
as
messy
as
I
need
to
do
them,
and
one,
mr
for
me
to
get
a
sense
of
the
blast
radius
and
then
also
just
going
through
and
reviewing
my
code
myself
and
what
terry
said
that's
feeling
of
like
this
is
a
lot
and
the
feeling
I'm
anticipating
others
to
feel
when
they
look
at
it.
A
A
If,
if
mr
is
hard
to
review,
that's
kind
of
the
good
signal,
it's
it's
too
big
if
it's
hard
to
review,
but
you
also
have
to
think
about.
Mrs
are
also
chunks
that
we
revert,
and
so,
if
the
mr
is
doing
too
much
and
there's
an
issue
with
it,
would
I
be
okay
with
reverting
all
of
this
like
so
when
we
can't
split
things
up
as
small
as
possible?
That's
that's
another
motivator.
A
As
a
maintainer,
I'm
interested
in
of
hey
there's
a
really
really
risky
part
to
what
we're
doing
here
and
then
there's
a
lot
of
other
stuff.
Can
we
move
this
risky
part
to
its
own
thing
so
that
if
we
had
to
revert
to
that,
we
can
just
revert
that
one
chunk
and
you
can
revert
individual
commits
and
figure
that
out.
But
that's
that's
another
thought
for
slicing
things.
D
All
right
yeah,
I
I
I've
seen
this
a
couple
of
times
when
people
try
to
sneak
in
some
like
little
unrelated
scenes.
So
it's
kind
of
a
separate
feature,
but
maybe
is
it
like
just
takes
too
much
time
and
like
to
create
to
separate
them
out
for
for
this,
and
they
just
think
like.
Okay
I'll
add
it
here
like
it's
not
in
school
but
like
there
is
no
sense
like
to
create
separate
demand
and
go
through
a
new
round
of
reviews.
A
A
A
You
want
your
chain
of
branches
to
point
to
each
other
and
it
is
totally
good
and
acceptable
for
part
three.
So
part,
three
branch
is
going
to
point
to
part
two
and
get
that
review.
Did
it
maintain
a
review
like
just
say,
have
it
to
do?
We
can't
merge
this
till
part.
Two
is
merged
and
I
need
to
I
need
to.
I
usually
leave
a
to
do
comment
of
when
this
is
merged.
Then
I
need
to
rebase
and
retarget
this,
but
that's
one
way
of
like
yeah.
A
Makes
sense
it's
tough
to
manage
and
everybody
that
I
don't
think,
there's
one
right
way
to
do
it.
Lots
of
people
do
different
ways.
I
would
not
recommend
doing
any
kind
of
like
feature
branch
way
of
like
we're
going
to
have
a
bunch
of
mr's
at
all
merging
into
this
large
feature
branch
that
we
then
all
merge
at
once.
A
A
A
The
so
I
had
both
of
these
being
reviewed
at
the
same
time-
and
I
know
like
I,
I
then
left
comment
comments.
I
added
questions
to
ux
for
myself,
but
I
left
a
comment
of
like
hey
when
the
parent
and
mars
merge
we
gotta
rebase
and
retarget
this
one,
so
this
one
you
know
ended
up
pointing
to
master
bed
originally
appointed
to
the
part,
one
branch
that
this
one
was
pointing
to
and
so
anytime
I
made
a
change
here.
I
did
have
to
do
this.
A
E
Sense,
I
do
a
similar
flow
where
you
have
them
kind
of
a
few
like
linked
to
each
other,
and
then
you
can
set
them
up
as
blocking
I
mean,
there's
not
there's
sometimes
cases
where
the
one
that's
at
the
top,
like
that's
pointing
to
master.
There
will
be
changes
that
have
to
be
cascaded
down
to
the
mrs.
That
would
depend
on
it.
But
if
it's
small
enough,
then
it's
not
that
big
of
a
problem
like
the
mrs
that
you're
training
shouldn't
be
so
like.
E
Hopefully
I
don't
know,
I
feel,
like
I
still
think
front
end.
Cody
I'll
have
a
lot
more
to
deal
with,
sometimes,
but
hopefully
the
changes
that
you
make
at
the
top
level.
If
they're
small
enough,
it
shouldn't
be
that
bad
to
cascade
them
down,
and
I
have
a
complicated
relationship
with
well,
but
eventually
we
do
get
along.
A
I
think
you
brought
up
a
good
point
too,
if,
when
you
do
split
things
up,
anticipate
knowing
where
to
draw
the
iteration
boundaries,
anticipate
how
those
different
parts
may
change
and
if,
if
your
parts
are
so
so
connected
with
each
other,
that
if
this
thing
changed,
this
thing's
like,
maybe
those
should
actually
be
next
to
each
other.
And
maybe
it's
more
about
like
the
implementation.
Details
is
what
we
want
to
flesh
out
in
another
iteration
or
something
what's
up.
Sam.
F
A
So
I
put
it
to
do
comment
and
it
is
not
targeting
part
one.
Oh
no,
I'm
sorry,
it's
not
targeting
master.
So
the
worst
thing
that
happens
is
someone
merges
it
into
part
one,
and
I
think
that's
happened,
and
that
was
like
you
messed
up.
You
messed
up
my
perfect
workflow,
but
these
are
just
not.
These
are
non-productive
branches,
so
I'll
just
force
push
and
go
back
to
the
state.
We
were
at,
that's
not
a
big
deal.
A
I
guess
it
closed
technically
closed
this,
mr,
if
it's
merged
and
I'll
have
to
create
a
new,
mr
for
all
of
that,
but
that
to-do
comment.
I
I
think
that's
only
happened
once
and
after
that
I
started
adding
this
to
your
comment
and
making
it
really
clear,
like
hey
we're,
not
merging
this.
Yet
this
is
just
this
next
iteration
waiting
for
this
to
be
merged
and.
F
F
E
F
E
Try
to
leave
a
few
notes
too,
at
the
top.
That's
like
this
doesn't
draft
like
don't
merge
or
but
I'll
leave
it
in
draft,
because
I
think,
as
a
maintainer,
if
I
see
something
a
draft,
my
instinct
is
to
say
hey.
This
is
still
in
draft
mode
like
let
me
know
when
you
want
to
merge
it
like.
I
don't
want
to
change
it,
because
I
feel
like
it's
a
mistake
and
they
can
fix
it
or
they
did
it
on
purpose
yeah.
I
don't
want
to
merge
it.
A
A
D
No,
you
can
I,
I
cannot
run
it
locally,
so
you
can.
Maybe
you
can
try
it,
but
like
the
main,
so
this
is
the
major
upgrade.
Obviously
like
one
of
the
dependencies
in
gitlab
and
I
usually
get
like
very
scared
when
I
get
this
designed
like
major
upgrades,
so
they
so,
but
maybe
here
we
can
share
as
a
responsibility.
So
there
are
many
phones.
D
So
this
is
upgrade
of
eslint
plug-in
and
the
pipeline
is
going
fine.
I've
seen
that
the
like
eslint
job
is
doing
fine
so
like
at
this
point
like.
I
might
feel
the
urge
to
to
merge
this
and
I'm
wondering
how
I
should
approach
it.
So
I
check
check
it
out,
see
that
the
lean
job
is
person
right,
but
maybe
there
are
some
new
features
that
are
added
and
that
we
want
to
introduce-
maybe
not
in
scope
or
dsmr.
But
later
I.
A
D
A
A
Yeah
the
other
thing
about
the
pipelines
to
be
aware
of,
but
I
don't
think
that
this
would
be
the
case
would
because
we
also
have
to
be
concerned
about
the
foss
pipeline
too.
But
since
this
is
just
static,
linting
like
it
should
include
all
the
foss
code.
So
I
I
don't
think
that's
an
issue.
These
are
my.
These
are
the
scariest.
Mrs
to
me,
these
are
the
absolute
scary
similars,
the
like
package
upgrade
where
there's
no
code
changes,
but
so
much
could
go
wrong.
D
No,
I
was
wondering
like
if
no
failure
so
currently
like
gitlab
is
in
a
good
state
like
to
be
upgraded
to
this
version.
Let's
say
plugin,
so
I'm
wondering
some
sometimes
like
major
versions
introduce
new
features.
How
do
we
track
them
like
and
introduce
it's
like
something
you
was
added.
When
do
we
add
it
to
get
one.
D
A
Yeah
I
mean
you
could
but
yeah,
I
usually
let
gitlab
dependency
bot
just
do
its
thing,
but
some
these
these
package
bumps
are
definitely
known
to
cause
user
facing
issues
so
they're.
Really,
we
can't
just
totally
trust,
get
lab
dependency
bond
and
it
does
sometimes
take
understanding,
what's
actually
changed
between
the
version
numbers
and
their
change,
log
and
stuff
so
yeah
these
these.
Thankfully,
this
is
just
a
dev
dependency,
so
I
think
the
worst
that
can
happen.
It
sounds
like
that's.
A
You
identify
that
really
well
and
I
think
that's
a
approach
and
there's
not
really
anything
more
to
do
here.
I
get
so
scared.
It
feels
like.
Oh
we're,
updating,
yaml
and
you
know
maybe
there's
a
new
bug
in
this
version
that
we
don't
know
about
or
whatever
and
those
those
things
concern
me
thanks
for
bringing
this
up.
This
is
a
great.
This
is
a
great
example
yeah.
I
think
here
it's
just
a
matter
of
pipeline
passing
because
it's
a
debt
dependency.
E
I
do
go
and
try
to
read
through
the
what
what
changed
as
best
as
I
can,
because
it
can
be
hard
to
digest
that
information,
but
at
least
to
be
like
making
sure
there's
no
breaking
changes
that
are
called
out.
That,
like
concern
me
and
if
I
don't
see
any
then
I
put
a
note
and
be
like
well,
I
looked
so
I
didn't
see
any
breaking
that
were
concerning
or
known
issues,
and
then
you
know
you
kind
of
did
your
best.
A
G
C
D
A
A
Yup
yup
all
right,
hey
thanks!
Everybody
thanks
for
kicking
off
our
weekly
workshop,
I'm
looking
forward
to
next
time,
maybe
next
time
we
can
dedicate
more
time
to
doing
pairing
on
code
review,
elena
thanks
so
much
for
bringing
this
one
up.
This
is
this
was,
I
think,
insightful
still,
so
you
all
have
a
great
rest
of
the
day.
Adios.