►
From YouTube: SIG Apps & CLI Mentoring Meeting for 20221205
Description
SIG Apps & CLI Mentoring Meeting for 20221205
A
Hello,
everyone
and
welcome
to
the
living
mentorship
so
hard.
This
is
the
5th
of
December
and
we
have
members
of
sick,
controverts
and
he's
here
to
speak
about
Premiership
in
general
and
with
respect
to
the
previous
segment
during
cohort
that
has
been
going
on
for
a
few
months
now,
I'm
over
till
born.
B
I'm.
Also
a
member
of
the
community
steering
committee
and
have
have
you
know,
sort
of
sick
Intruder
experience
is
sort
of
charged
with
sort
of
helping
manage
all
this.
The
fun
fun
processes
of
this
stuff,
and
so
things
like
reviews
and
the
sort
of
our
automation.
Some
of
the
other
things
around
it
sort
of
fall
right
in
its
wheelhouse
out
of
curiosity,
how
many
people?
If
anyone
was
here
in
2019
by
chance.
B
So
one
thing
that
I
just
want
to
get
out
here:
it's
like
my
number
one
resource
that
I
give
to
people
on
reviewing
is
Tim.
Hawkins
actually
did
a
talk
back
at
the
contributor
Summit
in
2019,
essentially
how
to
be
a
badass
code.
Reviewer
I
just
dropped
a
link
in
chat
for
those
that
are
like
I
tell
anyone
and
everyone
it
doesn't
matter
if
they're
working
on
kubernetes
other
things
that
that
is
an
excellent
talk
to
watch
I.
Tell
people
here
internally
at
Google
should
that
they
should
they
should
watch
it.
D
B
D
B
B
D
B
Okay,
I
was
gonna,
say
like
that,
in
terms
of
getting
your
your
PR
reviewed,
I
highly
recommend,
basically
just
popping
over
the
owner's
files
and
chasing
down
some
of
the
other
people
in
there.
If
your
you
know,
reviewers
aren't
necessarily
reviewing
your
PRS
and
for
you,
as
reviewers,
we
actually
have
a
published
set
of
GitHub
filter.
Well,
Gmail
filters.
If
you
use
Gmail
one
sec,
Kates
dot.
Let
me
pull
the
link.
B
One
big
thing
is
like
if
you
as
a
reviewer,
once
you
are
added
to
a
file
like
into
an
onus
file
and
all
that
is
helping,
you
know,
manage
expectations
and
giving
people
a
much
better
experience.
So,
if
you're
assigned
to
a
PR-
and
you
know
you
don't-
have
the
bandwidth
to
review
it
at
least
comment
on
the
issue
and
potentially
tag
in
someone
else
from
the
from
the
various
like
owners
files,
especially
like,
if
you
happen
to
know
that
they
might
be,
you
know,
active
in
slack
or
elsewhere,
just
to
help.
B
You
know
make
sure
that
you
are.
You
know
again
it's
like
managing
expectations,
if,
if
you
know
you're
too
busy
to
review
it,
it's
you
know
nice
of
you
to
to
potentially
tag
someone
in
that
can
I,
don't
know,
works
out,
don't
know
what
the
you're
talking
about,
but
you
should
get
over
that
honestly.
That
just
comes
with
time.
B
I
encourage
everyone
to
review
PRS,
even
if
you
aren't
necessarily
assigned
the
other
thing
that
can
be
super.
Super
handy
is
like
I
I've
popped
on
calls
with
other
people
to
you
know,
will
collectively
review
a
PR
which
can
also
help
with
you
know,
sort
of
building
that
confidence,
or
you
know
just
be
like
bouncing
off
that
idea
off
someone
else.
It's
like
hey.
Does
this
comment,
make
sense
for
here
or
not
foreign,
and
that
can
sort
of
like
help.
At
least
you
know
build
up
a
little
bit
that
expertise.
B
Sorry,
some
other,
like
General
things.
That's
like
perfectly
fine
to
push
back
on
is
making
sure,
like
you
know
telling
people
hey.
Can
you
break
like,
especially
when
it
comes
like
extra
extra
large
PRS
like
hey?
Can
you
break
this
up
into?
You
know
multiple
logical
commits,
so
it
just
makes
it
a
lot
like
it's.
Okay,
as
a
reviewer
to
push
back
on
a
PR
to
be
like
hey
can.
B
So
if
you
can
commit
your
code
change
as,
as
you
know,
one
PR
in
the
generated
code
is
another
one
that
makes
it
a
lot
easier
and
it's
again
perfectly
fine
for
you
to
push
back
on
someone
else
be
like
hey.
Can
you
please
please
do
the
same
so
I've
kind
of
been
been
ranting
here
about
some
of
the
the
bigger
things
that
I've
seen
that
can
be
useful,
but
does
anyone
else
have
have
any
other
challenges
that
they've
you
know
sort
of
stumbled
across.
B
E
Tests
mining
test
is
probably
the
first
one
that
always
catches
my
attention,
a
very
good.
Unfortunately,
we
don't
have
a
automatic
way
to
verify
that,
but
I've
been
doing
that
very
frequently
manually.
It's
pulling
down
the
pr
run
the
test,
the
unit
test
if
they
are
added
against
a
not
fixed
code,
to
ensure
that
it
actually
fails
before
applying
the
fix
I've
caught
a
couple
of
PRS,
where
they
were
explicitly
not
failing
without
the
fix,
which
basically
means
that
test
is
not
checking
what
the
bug
is
claiming
is
fixing
the
fix
was
correct.
E
The
test
was
missing,
the
failure
and
I
did
call
it
out
a
couple
of
times
asking.
This
is
fine.
Your
test
is
also
reasonable
because
it
was
touching
some
use
case,
but
it
is
not
failing
before
you're
fixed
and
people
did
did
provided
additional
unit
test
covering
that
particular
cases.
So
that's
definitely
one
of
the
things
given
the
recent
changes
because
way
in
the
back,
I,
don't
know
like
2017
2018.
Would
we
what
we've
been
used
to
do?
E
We've
been
splitting
the
API
and,
for
example,
controller
changes
or
other
pieces
of
the
code
into
separate
PRS?
The
recent
guidelines
are
basically
to
squash
everything
or
put
together
everything
in
a
single
PR,
which
makes
the
super
large
PRS
even
larger,
but
even
still
like,
like
Bob
mentioned,
asking
to
have
API
changes
in
one
comment.
Generated
changes
in
the
second
comment:
controller
changes
in
the
third
comment
or
whatever
other
area
you're
touching.
E
E
The
generated
the
generated
changes
can
be
mostly
ignored
because
we
have
all
the
tooling
around
it
that
are
ensuring
that
the
generator
changes
are
working
as
they
should
be,
and
most
of
them
than
that
they
are
being
also
hidden
by
default
by
GitHub,
because
we've
added
the
rules
to
not
to
show
them.
So
you
really
have
to
be
hard-coded
person
like
Jordan
or
or
I,
don't
know
maybe
Tim
who
are
actually
looking
through
those
generated
files.
E
B
B
B
So,
like
hey,
you
know
or
like
I'm,
you
know
going
back
to
the
whole
managing
expectations
thing
if
you're
rushing
to
get
like
a
cap
in
or
get
some
PRS
in,
just
dropping
a
one-liner
and
saying,
like
hey,
I'm,
really
busy
right
now,
but
I
can
get
to
reviewing
your
PR
after
you
know.
This
next
deadline,
just
is
really
nice
for
people
and
just
helps
both
like
the
well
it.
B
It
helps
you
as
a
reviewer
in
terms
of
managing
your
actual
bandwidth
as
well,
as
you
know,
just
being
a
nice
thing
for
the
person
at
some
of
their
PR
and
might
be.
You
know,
waiting
on
the
review
and
waiting
like
you
know,
the
the
waiting
is
something
we're
all
very
familiar
with
just
to
sort
of
get
an
idea
of
when
they
might
be
able
to
get
back
to
it.
Another
kind
of
random
thing:
are
you
all
familiar
with
a
gubernator.
B
B
B
B
E
Slack
or
very
frequently-
and
that
goes
back
also
to
the
recommendation
that
Bob
was
mentioning
what
I
will
do
is
I'll
ask
them.
Oh
if
you
just
ping
me
on
slack
in
in
a
week,
if
you
don't
see
me
responding,
because
whatever
the
GitHub
notifications
that
I'm
asked
and
I'm
not
able
to
go
through
or
since
I
know
that
I
looked
through
PR
everything
looks
mostly
okay
and
there's
only
some
couple
nits
that
I
do
want
to
get
fixed
before
merging
DPR,
oh
I'll.
F
G
Yeah
one
thing
I
was
thinking
about
was
the
drive
to
have
more
tests
and
like
having
people
add
to
something
not
necessarily
be
pertained,
specifically
to
their
until
they're
changed.
What
they're
trying
to
do
in
their
PR,
and
so
that's
the
only
place
where
I
could
even
see
it
really
being
used
for
you
like
code
change
and
the
tests
that
you're
adding
that
pertain
specifically
to
your
code
change
and
then,
if.
B
B
Thank
you
again
as
reviewers
too
again,
it's
it's
perfectly
fine
for
you
to
push
back
on.
People
are
submitting
stuff
to
do
to
do
that
sort
of
thing
it
just
will
make
it
easy
on
on
everyone
and
Beyond,
making
a
review
easier.
Can
you
imagine
like
going
back
and
and
like
trying
to
like
get
blame
and
and
figure
out,
try
and
chasing
down
where
something
might
have
happened,
it'll
just
make
it
easier.
B
B
B
One
thing
that
I
have
seen
people
fall
in
a
pattern
to
is
like
you
know,
they
might
have
reviewed
something,
and
you
know
they
made
a
comment
and
after
discussion
you
know
the
the
person's
proposed
change
or
someone
might
have
a
you
know,
change
your
opinion
are
explaining
it
better
one
like
it's.
It's
perfectly
fine
then,
just
like
oh
I'm,
sorry
I
understand
now,
but
if
you
didn't
understand
it,
it's
likely.
Someone
else
probably
wouldn't
understand
it
too.
So
it
might
mean
that
they're,
you
know
it's
worthwhile
for
them
to.
B
You
know,
put
in
some
more
comments
or
something
that
explains
some
of
that
logic.
Again,
you're
thinking
about
doing
a
favor
to
the
next
person.
That's
going
to
be
looking
at
this
help
setting
you
know
it,
it
might
be
you
in
you
know
a
year
and
you've
completely
forgotten
about
the
you
know
what
the
the
time
you
spent
looking
at
this
before
so
little
things
like
that
that
can
help
you
potentially
in
the
future,
for
reviewing
that
stuff.
D
Yeah
I
guess
I
have
some
above.
It's
not
like
some
important
thing
about.
Sometimes
it
happens
like
I.
Think
in
kubernetes.
It's
not
that
often
as
another
like
project
that
when
you
are
doing
a
review-
and
you
suggest
something-
and
maybe
sometimes
it's
a
like
a
long
review.
You
have
multiple
comments
and
some
people
like
sometimes
they
don't
go
through
all
the
reviews
and
Skip
some
of
the
parts
of
the
review
and
then
just
ask
for
review
again
and
then
it's
like
it
gives
more
more
iterations
for
this
process
and
yeah.
D
B
B
It
is
I
mean
when
that
happens.
It's
also
okay,
for
you
to
you
know,
push
back
like
hey.
Can
you
address?
You
know
X,
Y
and
Z
before
tagging
me
into
review
again,
if
it
seems
you
know
out
of
line
or
like
they're
they're
doing
it
too
much
or
you
know,
they're
making
lots
of
commits
for
like
every
tiny
little
change.
B
One
one
big
thing
you
know
having
those
multiple
commits
for
the
different
you
know,
fixes
or
or
you
know,
respond
to
the
feedback
might
be
useful
during
the
pr
review
process,
but
you
definitely
want
to
tell
them
to
like
rebase
it
and
squash
them
up
into
the
various.
You
know,
logical
layers,
that
that
make
sense
ahead
of
time.
D
A
E
E
E
Literally,
what
Victory
is
I'm
going
to
open
it?
This
dnpr
and
two
windows
or
oh
I,
had
these.
These
are
my
comments
from
the
last
time.
Let
me
check
if
all
of
them
has
been
addressed,
and
it's
not
that
this
still,
this
still
holds
just
like
Bob,
said,
don't
be
afraid
to
push
back.
If
something
went
out
earlier,
business.