►
Description
Speaker: Guinevere Saenger
A
A
See
so
when
we're
talking
about
making
contributions
by
pull
request,
we
are
specifically
talking
about
mostly
technical
or
document
contributions
and
as
with
as
I've
mentioned
before,
there
is
a
very
specific
kind
of
workflow
and
there
is
a
really
really
useful
graphic
for
this.
Many
of
you
will
be
familiar
with
this
workflow,
and
many
of
you
will
not
be
familiar
with
this
workflow
when
you
are
working
on
any
kind
of
kubernetes
repository.
Your
first
step
is
to
fork
the
repository
to
your
very
own.
A
Private
github
account
I
mean
not
private,
but
like
you
to
your
personal
github
account,
then
you
will
clone
it
to
your
local
laptop.
You
will
make
changes
on
your
local
machine
that
is
step
3
you're,
going
to
check
out
your
gonna,
make
changes
on
a
branch
you're
going
to
make
commits
on
that
branch
and
you're
going
to
push
to
your
and
then
you're,
going
to
and
you're
going
to
make
changes
to
your
working
directory.
A
While
this
is
going
on,
we
highly
recommend
using
whoopsies
using
git
fetch
and
get
rebase,
rather
than
get
pull
to
keep
your
master
branch
updated.
And
then
you,
once
you
have
made
all
your
changes.
You
can
commit
to
your
feature,
branch,
push
that
feature
branch
again
to
your
fork
of
the
repo
and
then
you
will
open
a
pull
request
from
your
personal
Fork
of
the
project
back
to
kubernetes.
A
In
this
example
we're
using
the
kubernetes
core
repository,
but
it
is
the
same
thing
on
all
the
repositories
so
in
this
next
part
of
the
exercise,
if
you
see
someone
trying
to
open
a
pull
request
from
something
that
is
not
their
own
fork,
you
should
say
something,
and
you
should
say
you
might
want
to
close
this
pull
request,
because
this
is
not
going
to
work.
We
do
have
safeguards
in
place.
A
I
am
actually
personally
not
sure
what
would
happen
if
you
tried
to
actually
open
a
pull
request
up
to
the
goober
org
I
have
no
idea
what
would
happen.
I
have
never
dared
to
try
it.
I
am
terrified
of
what
would
happen
so
I,
don't
know.
Some
of
you
might
be
more
adventurous
or
more
lucky
and
learn
things
in
the
meantime.
You
heard
it
from
me
fork
and
clone
open
a
pull
request
from
your
fork.
A
We
talked
about
the
main
types
of
pull
requests.
Let's
recap
it
again:
we
can
fix
bugs.
We
can
write
a
feature
and
then
there
is
a
special
kind
of
pull
request.
That's
called
a
kubernetes
enhancement
proposal.
This
is
a
very
long,
in-depth
document
about
a
feature
that
you,
your
company,
your
cig
or
your
friends,
want
to
implement
and
you
are
going
to
have
to
follow
the
steps
from
the
kubernetes
enhancement
proposal.
This
lives
in
it
nope
I'm,
not
using
this
right.
A
This
lives
in
here
here
we
are
okay.
I
have
this
is
an
example
of
a
bug
fixed.
You
can
tell
by
looking
at
the
stack
of
labels
on
the
right,
and
you
can
see
the
description
you
can
see
the
cigs
and
the
kind
that
got
added
and
failed
a
couple
tests.
Somebody
self-assigned
actually
look
at
that.
You
can
just
hit
slash
assigned
and
then
now
you're
assigned
as
a
reviewer.
You
see
some
LG
TM
and
approved
commands,
and
then
what
happens
is
one
for
the
robot
sees
that
all
the
labels
that
are
necessary
are
there.
A
For
a
feature,
you
will
see
that
the
list
of
labels
looks
a
little
bit
different,
it'll,
say
kind
feature.
It
will
be
a
lot
less
read
there
for
some
reason.
We
needed
to
add
the
okay
to
test
label
who
who
can
think
about
why
we
needed
to
add
the
okay
to
test
label
anyone?
Yes,
that's
right,
exactly
that's
why
that's
there
I'm
sorry
that
was
a
bit
loud.
The
size
label
gets
put
on
automatically.
A
That's
really
just
to
give
your
reviewers
an
idea
of
what
kind
of
work
they're.
Looking
at
and
again
you'll
see
several
multiple
baud
commands
and
labels
being
added.
And
finally,
when
the
PR
is
approved,
we
still
have
to
pass
tests.
Sometimes
our
tests
are
flaky.
That's
not
really
a
whole
lot
to
worry
about
just
hit
retest
and
then
merge
happens
automatically.
There
is
no
button
that
you
can
hit
that
says
merge.
This
is
a
good
thing,
because
people
like
me
would
probably
accidentally
fat-finger
that
button
and
it
would
be
bad.
A
A
A
A
On
this
repo,
there
is
no
approve
button
on
some
repos.
There
is
an
approved
button
because,
for
example,
for
a
cap
it
doesn't
make
sense
to
have
an
approve
button
right.
It
doesn't
make
it.
Doesn't
it's
not
really
practical
for
one
person
to
be
like
yeah.
This
looks
fine.
To
me,
I
mean
there
is
a
there's,
a
process
here
right.
It's
a
committee
process.
Let's
look
at
the
other
repo
here.
Well,
this
is
not
an
open
PR.
Let's
go
look
at
an
open
one,
provided
my
internet
is
working.
A
This
is
an
automated,
cherry-pick.
Let's
look
at
this
one,
so
I'm
going
to
go
to
files
changed
review
changes,
and
here
we
see
we
have
comment,
approve
and
request
changes,
so
I'm
so
glad
you
asked
us,
because
this
is
actually
super
confusing
on
some
repositories,
not
all
of
them.
If
you
hit
approve
here
that
will
be
equal
to
a
/l
GTM
on
other
repositories,
nothing
will
happen.
It
depends
on
how
the
automation
is
enabled
I
actually
wrote
feature
for
test
infra.
That
does
exactly
this.
A
A
A
To
get
approval
for
your
pull
request,
you
open
a
pull
request.
You
add
all
the
labels,
you
wait
for
BOTS
approval.
You
wait
for
the
Sigurd
eco
donors
to
approve
that
this
is
an
okay
thing
that
we
want
in
the
code
base,
and
then
we
ask
reviewers
to
look
at
the
actual
code
and
see
if
it
looks
good
to
them.
If
you
get
Elgin,
if
you
get
approve
an
LG
TM
and
your
tests
pass,
our
automation
called
tied
merges
the
PR
into
the
master
branch.
A
A
Finding
a
reviewer
can
be
difficult.
I
want
to
beg
everyone
in
this
room
to
be
patient,
but
also
to
stay
on
top
of
your
pull
request
and
not
get
discouraged.
If
no
one
looks
at
it,
if
no
one
has
looked
at
your
pull
request
for
a
couple
days,
go
look
into
the
communication
channels
that
NOAA
talked
about
go,
look
at
the
owners
files
and
find
out
who
is
a
code
owner
for
your
changes,
hunt
them
down
tag
them
on
github
ask
for
lightly.
Hey
I
opened
a
pull
request.
What
do
people
think?
A
Where
can
I
get
some
feedback
on
this?
Just
be
loud,
raise
your
hand,
be
polite,
be
kind,
sometimes
there's
so
much
noise
that
we
don't
notice.
I
swear
I
just
found
an
issue
filed
this
morning
that
had
deceived
me
twice.
It
was
from
October
I,
didn't
notice,
because
I
have
so
many
notifications,
so
it
depends
following
up.
That's
on
you,
please
be
as
courteous
as
you
expect
everyone
else
to
be.
If
you,
if
somebody
is
on
your
PR
and
gives
you
a
code
review,
please
work
on
it
and
get
back
to
them.
A
A
That's
on
you
most
rebase
--is
are
gonna,
be
pretty
easy
and
you
can
look
for
the
get
documentation
to
help
you
out
there
and
every
once
in
a
while,
of
course,
you'll
have
some
horrible
merge,
conflicts
and
I
am
so
sorry
same
thing
with
test
failures.
I
already
mentioned
that
you
can
tell
the
bots
to
retest
your
pull
request,
but
sometimes
there's
like
a
linting
error
or
you
fail
to
read
the
go
vet
thing
before
you
submitted
your
pull
request,
so
you
might
want
to
do
that.
First,
Tim,
we'll
talk
a
little
bit
about
that.
A
A
Yes,
you
can
and
I
believe
that
my
friend
Tim
is
going
to
talk
about
that
after
the
polar
quest
exercise.
So
this
exercise
is
again
really
only
there
to
introduce
you
to
the
kubernetes
automation
and
how
to
get
reviews
you
I'm
going
to
whoo
I'm,
so
glad
I
put
this
like
I
know
that
most
of
you
signed
the
CLA,
but
the
CL
is
only
good
for
the
username
that
you
signed
the
CLA
under
so
every
once
in
a
while.
A
Some
people
will
change
their
good
config
and
change
their
user
name,
and
if
you
do
that,
then
the
body's
gonna
be
like
I'm.
Sorry,
I,
don't
trust
you
so
before
you
do
anything
just
run
good,
config
username
in
your
terminal
and
verify
that
that's
the
one
you
use
to
sign
a
CLA.
If
you
have
high
confidence
that
that's
what
you
did,
if
you
only
have
one
kid
one
github
address:
that's
that's
fine!
But
every
once
in
a
while,
we
run
into
issues
with
this
yeah
I.
A
A
A
And
look
at
the
owners
file,
there
is
a
long
list
of
approvers.
Some
of
those
people
are
at
your
table.
Go
look.
Every
every
table
should
look
at
these
owners
files
and
find
out
which
one
of
them
is
a
reviewer
and
which
one
of
them
is
an
approver.
If
I
have
misspelled
some
user
names,
I
am
really
really
sorry,
but
each
table
should
have
at
least
one
approver,
and
at
least
one
reviewer
I
tried
to
go
for
two
and
three.
A
Cool
so
once
you
have
figured
out
who
that
is:
okay,
yeah
I
totally
did
this
over
lunch.
So
if
you're
all
mad
with
who
you
wound
up
being
it's
totally
all
my
fault,
you
can
come
yell
at
me
later
so
again
for
the
pull
request,
pick
two
people
at
your
table
and
they
can
be
ones
that
are
maybe
not
in
the
owners
file
and
see
what
happens,
but
it
really
ultimately,
ultimately
just
picked
two
people
who
are
comfortable
opening
a
pull
request.
This
can
be
a
good
way
ago.
A
A
good
thing
to
do
is
add
a
file
in
which
you're
introducing
yourself
and
then
open
a
pull
request,
saying
like
new
file
for
contributor
awesome
and
and
then
your
table
will
review
those.
Let's
have
maybe
two
pull
requests
per
table
and
your
table
will
review
those
everyone
can
comment.
Everyone
can
look
at
the
code
and
suggest
changes
and
by
code
I
mean
you
know
your
markdown
files,
but
only
the
reviewers
and
approvers
can
actually
interact
with
the
bot
to
add
the
necessary
label.
A
A
A
All
right,
so
we
are
we're
getting
close
to
the
top
of
the
hour,
which
means
it's
time
for
local
test
and
build
of
kubernetes
kubernetes.
However,
some
of
you
have
asked
me
this
question
before
they're,
like
so
I
gathered
all
the
labels,
I
get
green
I
get
a
green
checkmark,
so
my
pull
request:
why
is
it
not
merging?
That
is
because
we
have
a
merge
pool
and
there
okay
there's
another
put
tool
called
tide
which
basically
checks
for
all
the
things
that
that
are
necessary
on
your
pull
request.
A
It
goes
into
a
merge
pool
and
it
will
wait
to
merge
your
pull
requests
because
on
some
of
our
repos,
the
the
commit
chain
works
so
quickly.
There's
so
many
commits
to
master
all
the
time
that
by
the
time,
your
pull
request
is
ready
and
reviewed
and
passed
tests.
Your
tests
are
already
out
of
date,
so
what
ty
does
it
gathers?
All
the
pull
requests
runs
the
tests
one
more
time
before
merging,
and
so,
if
currently,
your
pull
request
has
all
the
Green
Arrow's.
A
That's
that
just
means
you
sit
tight
and
wait
until
tide
comes
around
and
merges
your
pull
request.
This
is
also
a
relatively
new
tool
to
work
in
this
way
tides
been
around
for
a
while,
but
but
this
is
kind
of
the
first
time
that
I've
seen
it
in
action,
which
is
fabulous,
and
this
is
one
of
those
things
you
get
used
to
it.
Lots
of
changes,
lots
of
updates.