►
From YouTube: Helm Contributor Summit 2021 (Part 1)
B
Yes,
sorry,
all
right,
all
right,
I'm
going
to
start
hi
everyone,
I'm
karen,
I'm
the
community
manager
for
helm
and
I'd
like
to
welcome
everyone
to
the
home
contributor
summit.
2021.
We're
really
excited
for
you
all
to
be
here
today.
You
know
home
as
a
project
has
really
grown
over
the
years,
and
we
know
at
the
end
of
the
day
that
it's
the
people
and
the
community
that
help
push
it
forward
and
upwards.
B
So
for
those
of
you
who
are
curious
about
what
it's
like
to
be
a
maintainer
we'll
spend
the
first
half
of
the
day
going
over
the
sorry
for
those
of
you
who
are
interested
in
becoming
a
maintainer
we'll
spend
the
second
half
of
the
day
going
over
at
the
main
structure
and
before
we
get
started,
though
just
a
few
housekeeping
items.
First,
this
event
is
going
to
be
recorded.
B
So,
as
you
can
see,
we
are
recording
and
the
recording
will
be
made
available
on
the
cncf
youtube
channel
later
this
week.
Hopefully
so
you'll
be
able
to
catch
up
on
everything.
If
you
don't
catch
it
the
first
time
and
then
for
q
a
we
will
not
be
using
the
q
a
function
on
bevvy.
Instead,
we
have
a
channel
on
the
cncf
slack,
it's
going
to
be
the
home
contributor
summit,
2021
slack
channel.
B
B
If
anyone
wants
to
speak
just
you
know,
you
can
say
so
in
the
chat
on
bevvy
and
one
of
the
hosts
can
promote
you
to
speaking
and
lastly,
I'd
like
to
just
ask
everyone
to
adhere
to
the
cncf
code
of
conduct,
basically
just
be
respectful
to
our
presenters
and
our
fellow
participants,
and
that
I
will
hand
it
over
to
matt.
You
ready
all
right.
A
All
right,
thank
you
all
for
joining
us
today.
This
is
our
first
ever
helm,
contributor
summit,
we've
done
helm
summits
in
the
past
that
have
been
more
organized
around
the
run
in
and
around
the
community
on
helm
itself,
and
this
time
we
wanted
to
take
the
opportunity
to
talk
more
about
the
whole
process
of
contributing
governance,
and
things
like
that.
A
So
I'm
going
to
kick
off
with
kind
of
a
big
overview
to
just
clear
up
some
of
the
terminology
we
use
about
how
helmets
govern
so
helm
is
a
cncf
project.
Cloud
native
computing
foundation
is
a
non-profit,
that's
part
of
the
linux
foundation
that
basically
serves
as
sort
of
a
central
body
where
we
can
all
donate
open
source
software
and
have
it
sort
of
governed
under
a
central
model.
So
underneath
the
cncf
helm
has
an
organization
and
the
helm.
A
Org
has
many
different
projects,
but
they're
all
tightly
related
to
to
helm
itself
and
so
to
keep
all
of
those
projects
working
well
together
we
have
one
central
org
and
the
helm
community.
Repo
is
where
you
can
find
out
more
about
this
org
underneath
the
org.
There
are
a
whole
bunch
of
different
projects,
one
of
which
is
the
helm
project
and
that's
the
project
that
works
on
the
piece
of
software
that
we
call
helm.
A
But
there
are
several
other
different
projects
in
the
helm,
org
too,
including
documentation,
some
of
the
github
actions
registry
and
repository
tools,
and
several
more
that
you'll
hear
about
throughout
the
day.
But
a
lot
of
the
focus
today
is
going
to
be
on
both
the
helm,
core
project,
the
helm
project
and
the
helm
documentation
project.
We
will,
however,
cover
a
number
of
these
other
things,
so
I
wanted
to
allow
it
a
couple
of
terms
because
you're
going
to
hear
us
talk
about
them
throughout
the
day.
A
So
we
talk
about
project
maintainers,
every
helm,
repository
every
piece
of
the
helm
organization
has
some
people
who
act
as
core
maintainers
and
core
maintainers
are
responsible
for
taking
care
of
that
project.
You'll
hear
us
go
into
more
detail
about
that
over
the
day,
but
a
project
maintainer
is
really
related
to
just
one
of
those
projects.
A
You
might
also
hear
us
talk
about
the
security
team.
The
security
team
is
a
cross
project
team,
so
we've
got
some
core
maintainers
from
many
different
helm
projects
that
we
all
work
together
to
triage
security
issues
when
a
new
thing
comes
in
and
we're
the
ones
who
try
and
roll
out
the
security
updates
when
necessary.
A
You'll
also
hear
us
talk
about
org
maintainers,
so
all
the
projects
are
grouped
together
under
the
big
helm,
org
the
helm,
org
itself
has
some
people
that
are
nominated
from
projects
to
represent
those
projects
to
the
org
itself,
and
we'll
talk
about
that
in
particular
I'll
be
talking
about
that
late.
This
later
on
today,
in
the
second
half
of
today's
presentations
and
then
the
last
term
that
you
may
hear
today
that
that
I
wanted
you
to
be
aware
of
is
emeritus
maintainers.
A
So
in
academia
you
hear
about
a
professor
who
retires,
they
become
an
emeritus
professor,
which
means
they
no
longer
have
teaching
or
committee
responsibilities
at
the
university
right.
We
wanted
to
borrow
that
same
concept
and
when
people
retire
their
maintainer
ships,
whether
they're
project
or
org
maintainers.
We
then
refer
to
them
as
emeritus
maintainers,
just
as
a
as
a
way
of
showing
respect
for
people
who
have
contributed
many
hours
of
work
to
the
project.
A
So
when
I
use
these
terms,
this
is
kind
of
what
we're
all
we
all
use.
The
same
terms
together.
Issues
right
an
issue
is
a
github
issue.
That
is
a
bug
or
a
request
for
help
or
something
like
that.
When
we
talk
about
changing
the
helm,
repo,
we
talk
about
pull
requests
or
prs
prs
are
ways
using
git's
api
to
submit
patches
to
a
project
in
a
sort
of
controlled
way
where
we
can
review
them.
A
So
if
you
head
over
to
github-
and
you
interact
with
pretty
much
any
of
the
open
source
projects,
you'll
see
some
combination
of
issues
and
pull
requests
used.
But
one
thing
that's
more
helm
specific
is
helm,
improvement,
proposals
or
hips.
That's
actually
borrowed
from
python
improvement
of
improvement.
A
C
A
Wanted
to
talk
through
some
of
the
workflows
that
you
connect
that
you'll
hear
a
lot
about
today.
So
github
again
is
our
central
place
of
doing
development
and
there
are
particular
established
workflows
in
github
that
we
use,
and
some
of
them
are
the
way
you've
seen
them
on
other
projects
and
others
are
a
little
different.
So
I
wanted
to
start
out
with
the
documentation
workflow.
A
So
we
have
github.com
helmslash
helmw
and
that's
where
documentation
is.
If
you
want
to
change
the
documentation
that
you
see
on
helm.sh,
you
go
to
this
repo
and
you
file
an
issue
saying:
hey
here's,
a
problem
with
the
documentation.
Somebody
writes
the
text
to
address
that
change.
A
new
pr
is
open
right,
a
pull
request
that
has
just
those
changes,
and
then
we
discuss
those
changes
and
make
sure
that
you
know
it's
organized.
It's
clear.
It's
grammatically
correct.
A
It's
helpful
to
the
end
user
and
you
know
we
on
occasion
we
go
back
and
forth
right
and
and
the
person
who
submits
the
pr
has
to
make
a
couple
changes.
Then
we
review
it
again
and
say:
okay,
everything
looks
good
and
we
approve
it,
then
that
pr
gets
merged
into
the
mainline
repository
and
at
some
point,
that
mainline
gets
republished
and
your
documentation
changes
will
show
up
on
the
site.
So
that's
sort
of
the
typical
workflow
right
start
with
an
issue.
Do
a
little
bit
of
discussion
go
to
a
pull
request.
A
A
very
similar
workflow
exists
for
bugs,
and
I
think
it's
adam
maurice
we'll
be
talking
about
this
in
a
couple
hours
from
now
somebody
files
an
issue
and
says
this
doesn't
seem
to
be
right
about
helm
and
there's
some
discussion.
Well,
how
do
we
reproduce
it?
Can
we
identify
the
cause?
What
are
some
possible
solutions
and
we
discussed
there
in
the
issue
queue?
A
Many
of
you,
I
know,
have
participated
in
this
process,
for
which
I
am
very
thankful
and
at
some
point
someone
says:
okay,
I
will
I
will
try
and
fix
this
and
they
write
some
code
open.
A
pull
request
and
and
and
we
start
to
discuss
that
pull
request,
and
we
say:
okay
are
there
unit
tests
to
make
sure
this
works?
Does
the
code
pass
all
of
our
quality
metrics?
Is
it
functioning
properly?
Are
there
any
security
issues
inadvertently
caused
by
this
particular
change?
A
We
will
cover
the
coding
part
a
little
bit
later
this
morning.
I
believe
martin
hickey
is
going
to
take
care
of
that
and
talk
about
that
in
more
detail.
I'm
just
trying
to
give
a
quick
overview
of
it
now
so
here's
the
last
thing
I
wanted
to
give
a
quick
overview
of-
and
this
is
the
feature
workflow.
So
this
is
slightly
different
and
for
a
reason
we
value
helm
stability
very,
very
highly
right
now
we
know
that
there
are.
A
We
got
five
plus
million
downloads
of
helm
per
month,
and
so
we
know
there
are
a
lot
of
people
relying
on
helm
to
function
properly.
Introducing
a
feature
can
be
dangerous
because
it
might
break
something
inadvertently
or
it
might
modify
the
way
people
do
work
in
an
unexpected
way.
So
we
are
very
careful
when
we
introduce
new
features.
A
That's
why
we
have
helm
improvement
proposals,
which
is
a
written
description
of
what
your
feature
is
going
to
do
and
how
it's
going
to
work.
So
a
hip
is
created
in
the
community
repository
not
in
the
helmhelm
repository
and
can
refer
to
any
of
the
projects
under
helm
and
again.
Matt
fisher
will
go
over
this
in
detail
later.
But
the
idea
is
it's
a
written
explanation
of
the
feature
we
discuss
that
feature
a
little
more
carefully
than
we
discuss,
discuss
a
bug
fix
and
we
say:
okay:
does
it?
Is
it
addressing
the
problem?
A
A
A
successful
hip
will
get
approved
and
then
merged
into
the
community
repository
and
then
oftentimes.
The
pr
will
start
during
the
course
of
the
hip.
But
at
that
point
once
the
hip
is
approved,
then
we
will.
The
maintainers
will
officially
consider
whether
we
are
going
to
merge
the
pr
as
well
and
the
pr.
C
A
Turns
over
to
are
the
mechanics
of
the
code
correct
is
it?
Are
there
unit
tests?
Are
there
functional
tests?
Is
the
hip
properly
implemented
in
this
pr,
and
things
like
that
and
again
we'll
iterate
a
little
bit
back
and
forth,
but
before
the
two
main,
two
or
more
maintainers
approve
of
that
and
it
gets
merged
in
now,
features
don't
go
out
in
every
release.
They
only
go
out
in
minor
or
major
releases,
so
they're
far
less
frequent
in
the
code
base
than
patching
and
security
fixes,
which
will
go
in
every
single
release.
A
So
that
should
give
you
a
big
overview
again
we're
going
to
come
back
later
and
cover
each
of
those
things
in
more
detail.
But
I
wanted
to
give
a
sort
of
bird's
eye
view
of
how
we
look
at
maintaining
health.
So
next
up,
scott
rigby
is
going
to
jump
in
here
and
talk
about
repositories.
I
haven't
talked
really
much
about
those
at
all.
I'm
waiting
to
pass
everything
on
to
him
and
he'll
give
an
introduction
of
that
and
the
changes
in
the
last
year
and
how
we
do
that
kind
of
thing.
A
But
here's
kind
of
an
overview
of
the
rest
of
the
day
after
scott
bridget's
going
to
talk
about
documentation
in
more
detail.
A
documentation
is
an
excellent
place
to
jump
in
and
get
started,
ronan's
going
to
take
it
from
bridget
and
talk
about
the
mechanics
of
the
website.
So
if
you
want
to
improve
the
helm.sh
website
with
css
changes
or
html
changes
or
things
of
that
nature,
ronin
will
kind
of
give
a
high
level
of
overview
on
how
to
change
those
kinds
of
things.
A
After
that,
martin
is
going
to
talk
about
coding
and
coding
guidelines
in
helm
when
you're
ready
to
open
that
first
pr,
the
stuff
that
martin
says
first
code,
pr
against
helmhelm
the
stuff
that
martin
tells
you
about,
will
be
very,
very
important
for
you.
I'm
really
looking
forward
to
that.
One
we'll
have
a
short
break
there,
and
then
we
will
come
back
and
I
will
cover
governance
in
more
detail.
I'll,
go
back
to
that
earlier.
A
Cncf
slide
and
explain
what
each
of
those
things
mean
and
what
the
security
team
actually
does
and
what
core
maintainers
responsibilities
are
and
things
of
that
nature.
Matt
fisher
is
going
to
deep
dive
into
the
helm,
improvement
proposal
process
and
explain
how
to
do
one
of
those.
So
at
that
point
at
which
you're
really
interested
in
starting
some
major
features
or
or
jumping
into
a
hip
proposal
and
helping
people
refine
those
major
feature
changes.
A
I
I
think
we
can
tip
our
hand
now
and
say
there
will
be
some
awards
and
things
like
that
at
the
end.
So
it's
going
to
be
an
exciting
day
here,
I'm
going
to
hand
over
now
to
scott
I'm
going
to
try
and
stop
my
screen
sharing
so
that
he
can
try
starting
his
and
we'll
make
this
first
transition
from
speaker
to
speaker
and
see
how
this
goes.
But
thank
you
all
again
for
being
here
today,
I'd
like
to
introduce
scott
rigby,
one
of
the
core
maintainers
of.
D
Okay,
can
you
hear
me
and
see
me
wow?
Okay?
This
was
going
to
be
a
complete
surprise
for
me
how
it
worked
fantastic,
hi,
everyone.
So,
yes,
I
yeah
scott
rigby.
I
I'm
a
I
work
in
developer
experience
at
weaveworks.
Now
I
am
I've
been
involved
in
the
helm
project.
For
some
years,
I've
worked
yeah,
I'm
one
of
the
core
maintainers.
I
helped
I'm
on
the
the
organization
maintainer
group
which
we'll
be
covered
later.
It
sounds
like
and
and
I've.
D
D
D
Okay,
awesome,
okay,
great
and
then
I'm
gonna
try
screen
sharing
for
the
first
time,
so
bear
with
me
for
a
second
and
just
for
everyone
here.
Please
ask
questions
or
really
just
feel
free
to
interact.
Each
presenter
might
be
different,
but
for
me
it's
very
informal
interactive
here.
I
simply
just
volunteered
to
give
an
overview.
So
here
is
the
screen
share.
D
D
D
D
A
B
B
B
A
A
With
that
schedule
there
I
can
go
so
so
scott
will
come
back
and
and
finish
up
the
introduction
section.
Then
we'll
talk
about
how
things
change
in
helm
and
that
whole
section,
which
will
have
multiple
speakers,
will
cover
sort
of
the
the
day-to-day.
How
you
submit
changes
and
things
like
that.
Then
after
the
break,
we'll
come
back
and
really
take
more
of
the
maintainer
view
of
things
and
talk
about
how
how
things
are
changed
and
how
core
maintainers
interoperate
with
and
what
our
different
processes
are,
and
things
like
that.
So
the.
C
A
Part
will
be
very
practical
about
how
to
get
started
and
the
second
part
will
be
oriented
more
toward
how
core
maintainers
work
and
what
the
inner
mechanisms
are
again
with
an
eye
for
helping
people
who
might
want
to
be
maintainers
to
understand
what
that
involves.
All
right,
scott
looks
like
you're
back,
I'm
gonna
hand
it
back
over
to
you
and
let
you
give
it
a
shot
with
the
screen
share.
D
D
D
Okay,
okay!
Well,
in
that
case
I'll,
in
that
case,
I'll,
stop
sharing
that
doesn't
really
help
you,
okay,
great
well,
so
we
we
only
have
a
few
minutes
now
sorry
about
the
technical
difficulties,
but
what
I'll
do
is
I'll
paste
these
into
I'll
paste
these
into
the
chat?
So
you
I'm
sure
you
know
the
very
first
repo
that
you
want
to
be
looking
at
that
matt
mentioned
is:
is
the
client
and
sdk
and
the
website?
D
I
guess
you're
going
to
go
over
this
matt,
so
I
won't
get
too
into
what's
in
the
community
repo
except.
This
is
where
you
find
things
about
governance,
the
process
or
the
processes
for
everything
related
to
the
project
helm
as
a
project
itself,
and
not
only
to
its
primary
core
client
or
its
other
sub
projects
or
tools
and
okay.
There
I'll
fly
a
little
more
quickly
here
there
are
other
sub-projects,
so
several
several
of
them
are
longer-term
projects
that
are
expected
to
continue.
D
One,
for
example,
is
chart
museum.
That's
that's!
That's
one
that
is
listed
often
because
it's
used
by
many
people
it
is,
it
is
supported.
There
is
also
there
are
also
several
projects
I
just
want
to
mention
you
can
kind
of
not
ignore,
but
just
keep
your
eyes
peeled
for
their
deprecation.
At
some
point
there
is
a
project
called
monocular
which
which
that
is
getting
into
that
category
helm
hub
I'll,
just
paste
it
here.
It
is
something
that
is
going
to
be
deprecated.
D
D
I
don't
want
to
go
over
time
really,
but
thanks
bridget
there
are,
there
are
chart
helper
and
automation
tools,
and
so
just
yeah
there's
there's
three
of
them
and
it
would
be
nicer
if
I
could
show
you,
but
but
the
one
that
you
probably
are
using
the
most.
Now,
if
you
have
any
automation
around
charts
whatsoever,
is
charts
testing.
D
Oh
excuse
me,
I
actually
did
not
type
the
correct
ignore
the
last
link,
but
the
charts
testing
project.
It
is
a
project
written
in,
go
that
that
does
not
use
helm's
sdk.
If
you're
interested
in
contributing
that
could
really
use
some
additional
people,
it
doesn't
use,
helps
sdk.
It
uses
helm's
binary
on
purpose
so
that
we
can
test
multiple
versions,
because
the
point
of
it
is
not
is
not
to
test
helm.
Helm
has
its
own
tests,
but
it's
to
have
it's
for
chart
maintainers
to
test
charts.
D
So
it's
a
very,
very
helpful
project.
It
allows
you,
for
example,
to
to
install
chart
basically
everything
you
can
do
as
a
manual
user
with
the
client
dry
runs,
but
what
it
also
does
is
automate.
It
allows
you
to
put
in
tests
and
automate
those
and
also
integrate
with
other
great
tools
around
testing,
so
it's
very
helpful
for
keeping
things
stable,
there's
a
tool
called
called
chart
releaser
and
that
I'm
just
going
to
briefly
mention
it.
D
It
is
a
it
is
a
different
way
of
hosting
helm
repose
than
than
chart
museum
rather
than
running
in
cluster
and
and
running
as
a
separate
application.
It
really
just
leverages
at
this
point
github
it
could
integrate
with
gitlab
but
uses
github
pages
in
order
to
host
helm
repos,
which
is
exactly
what
the
stable
and
incubator
repos
package
history
is
doing.
Now,
thanks
to
github,
there
are
other
helper
tools.
Those
two
two
are
for
sharp
maintainers
or
excuse
me.
D
Those
two
are
for
people
who
are
using,
let's
say,
end
users
using
charts,
releasers
for
chart
maintainers
and
then
the
helm.
Two
to
three.
I
just
pasted
the
helm2
plug-in
this.
I
don't
know
if
this
is
a
good
category
for
it,
but
I
believe
it's
a
good
helper
tool
for
for
practitioners,
human
operators
as
well
when
they're
upgrading
from
the
former
version
of
helm
held
two
to
the
current
version.
D
Hub3,
so
the
last
thing
I
think
I
should
say,
because
it's
now
9
32-
I
don't
want
to
be
too
too
go
to
over,
is
oh
thanks.
Bridget
is
there
are
several
helm
actions,
and
this
is
important
for
for
knowing
that.
Excuse
me
for
being
able
to
get
up
to
speed
quickly
and
automate
the
above
tools
that
I
mentioned
so
the
the
releaser
that
allows
you
to
post
your
own
home
repos
without
having
to
pay
for
other
tooling
and
the
testing.
D
So
there
are
several
others
that,
for
example,
there's
a
homebrew
tap
that
helps
with
that
helps
with
our
homegroup
packages,
because
we
have
several
other
binaries
that
that
are
not
in
in
the
in
the
homebrew
core
yet
but
but
the
rest
are
are
really
just.
There
are
some
docker
images
you
might
see
in
there
that
some
of
them
are
being
used,
but
others
will
be
made
obsolete
relatively
in
the
not
too
distant
future.
D
I
should
I
say
one
only
because
I'm
not
sure
if
it
is
the,
but
it
is,
it
is
not
the
place
to
put
effort
into
anymore,
but
you
can
still
use
that
that
repository
to
to
for
a
history
of
what
has
happened
with
charts
that
you're
using
around
the
wild
now
that
have
moved
to
separate
repositories,
it's
the
source
code
for
for
for
many.
Many
excuse
me
for
charts
that
install
many
different
cloud
native
applications
up
to
a
certain
point
up,
ultimately
to
last
fall.
D
D
D
E
E
E
E
E
E
A
E
A
E
E
Okay,
sorry
about
that.
Okay,
thank
you
for
your
patience,
everyone!
So
I'm
going
to
go
through
this
section,
which
is
the
how
things
change
in
helm
section.
So
hopefully
everyone
can
see
these
slides,
so
this
is
going
to
be
I'm
going
to
move
pretty
quickly.
There's
three
different
kind
of
subsections
in
this
because
a
lot
of
things
change
in
helm.
E
So
I'm
going
to
take
the
first
segment,
which
is
just
kind
of
like
an
overview
of
the
website.
Some
of
the
tools
that
we
use
for
for
running
and
making
changes
to
that
and
bridget
then,
is
going
to
look
at
the
documentation
section
of
the
website,
which
is
probably
the
area
that
sees
the
most
activity.
We
have
a
lot
of
docs
a
lot
of
different
languages
and
then
martin
will
pick
it
up
to
talk
about
the
coding
processes
around
working
and
contributing
to
the
helm
core.
E
So
without
further
ado,
just
introduce
myself,
I'm
ronan
I've
been
kind
of
doing
things
contributing
to
some
of
the
helm
assets
for
a
few
years.
The
helm
website
really
has
been
around
since
about
2017,
maybe
earlier
maybe
2016
and
it's
as
the
project
has
moved
into
the
cncf.
And
you
know
we
have
a
lot
of
like
extra
resources
through
them
and
there
are.
They
help
us
to
host
run,
maintain
some
of
the
tools
that
we
use
here
and
the.
C
E
So
I
just
want
to
give
a
quick
kind
of
run
through
of
what's
involved
in
that
and
see.
If
anyone
is
kind
of
interested
in
helping,
you
know,
make
edits,
commit
changes
and
code
to
the
to
the
helm,
dub
dub
dub
repo,
so
you
know,
hopefully
most
people
here
are
a
little
bit
familiar
with
this.
This
is
just
like
the
landing
page
explains
the
project,
and
this
is
like
that,
where
you
arrive
at
the
site-
and
this
is
how
most
people,
I
guess
would
have
their
their
gateway
to
helm.
E
E
F
E
Show
you
kind
of
like,
what's
behind
the
website,
all
these
sections,
which
are
kind
of
very
different
in
in
their
purpose
and
their
kind
of
layout.
They
all
work
off
the
same
code
base,
which
is
the
helm,
dub
dub
dub
project,
and
you
know,
as
matt,
was
talking
about
with
our
github
workflow
as
an
open
source
project
in
the
cncf.
E
E
Give
a
look
through
some
of
those
tools
in
a
moment,
and
the
google
site
is
then
pushed
up
to
netlify
through
the
github
workflow,
which
I'll
show
a
little
bit
more
of
in
a
moment,
and
it
really
allows
us
to
keep
things
synced
up
and
deployed
pretty
quickly.
It's
a
nice
light
kind
of
chain
of
things,
so
the
the
main.
C
E
Every
time
there's
a
push
to
the
project.
It
gets
deployed
as
a
feature
branch
that
you
can
kind
of
like
test
and
preview,
your
your
changes
before
they
get
merged
and
allows
you
to
kind
of
test
things
like
design
changes
or
to
see
how
blog
posts
or
even
documentation
changes,
look
before
they're
added
to
the
site.
E
Making
changes
to
the
website
whether
you're
making
changes
to
the
landing
page
to
the
documentation
to
the
blog
everything
goes
through.
Git
commit
and
pull
request
review
process,
so
the
project
maintainers
would
review
pull
requests
before
it's
eligible
for
merging
before
it's
merging.
You
will
see
this
section
down
here,
which
is
the
checks
we
have
a
dco,
which
is
our
commit
signing
process
which
I
think
martin
will
be
discussing
in
a
bit
more
depth
and
the
second
one
you.
C
C
E
E
So
you
can
see
here
in
files
changed
the
version
got
bumped
here,
it's
a
very
small
pull
request,
I'm
going
to
review
and
approve,
and
as
I'm
one
of
the
administrators
on
this
repo
once
I
have
given
approval
to
this,
the
butt
turns
green.
My
checks
are
all
green,
so
I'm
going
to
merge
and
what's
going
to
happen,
is
it's
very
quickly
going
to
build
and
deploy
the
site
to
go
from
from
that
version
to
the
new
one?
E
E
E
Okay,
so
that's
kind
of
like
the
a
quick
example
of
how
it
works.
Bridget
will
get
into
some
of
the
more
details
around
you
know:
making
changes
to
the
docs,
how
versioning
works
or
signing
off
forgetting
how
localization
is
set
up
and
the
readme
really
is
pretty
thorough.
We
have
a
lot
of
good
processes
and
things
defined
within
the
home
project.
You
have
contribution
guides
or
at
checklist
and
so
forth.
E
The
doc
site
really
is
a
great
starting
point
for
any
questions
you
have
and
if
you're
curious
about
about
the
helm
project
and
the
website,
we
try
and
use
issues
like
for
tracking
any
bugs
or
anything
we
want
to
make
as
an
enhancement
or
so
forth,
and
we
have
a
special
label
called
good
first
issue,
which
is
a
nice
starting
point.
If
you're
curious
about
how
can
I
be
of
use
to
this
project?
E
I've
been
looking
at
this
code
base
and
you
know
I'm
trying
to
figure
out
what
small
things
can
I
do
to
sort
of
get
familiar
with
the
tooling.
The
good
first
issue
label
is
a
nice
resource
for
that.
Here's
some
small
like
things
that
are
on
my
list
of
tasks
to
fix
up
and
we
always
welcome
contributions.
If
anyone
wants
to
look
at
this
stuff
and
if
there's
any
questions
around
how
you
interact
with
this
tooling,
you
know:
how
do
you
install
hugo?
How
do
you
kind
of
like
you
know?
E
E
E
C
C
E
C
C
C
C
Okay,
we're
gonna,
try
that
that's
a
little
bit
better,
because
now
I
can
actually
change
to
other
tabs
all
right.
So
if
we
take
a
look
at
the
home
docs
that
we
were
just
on,
oh-
and
I
can
reload
that
and
see
we're
at
353
now
hurry
when
we
take
a
look
at
the
home
docs,
we
actually
have
this
front
page.
That
says
how
it's
organized-
and
it's
probably
a
good
idea
to
take
a
look
through
that,
because
the
various
types
of
docs
are
pretty
different
from
each
other.
C
If
we
take
a
look
at
some
of
these,
like
oh
charts
library
charts,
how
are
those
different
from
charts?
Wait?
Chart
repositories
there's
a
lot
of
chart
stuff
going
on
here,
so
you
can
see
there's
a
lot
of
detail
again
like
it
goes
into
enough
detail
that,
depending
on
what
high-level
concept
you're
trying
to
learn,
the
topic
guides
might
be
useful.
Okay,
the
community
guides
highly
relevant
to
people
who
might
want
to
you
know
actually
contribute
to
something.
This
has
the
developer
guide.
We
are
constantly
updating
our
release
checklist
because
it
turns
out.
C
There
are
a
lot
of
steps
like,
for
example,
updating
that
you
know
three
five,
two
to
three
five:
three:
it
was
on
a
checklist,
but
it
was
step
up
ten
of
eleven.
What
are
you
gonna
do
and
and
then
we'll
talk
a
little
bit
about
the
localizing
two.
The
how-to
guides
are
worth
taking
a
look
at
specifically
because
they
are
in
more
depth.
So
these
are
not
necessarily,
you
know,
simple
topics
but
they're,
pretty
complex
topics
like
say:
developing
your
own
charts.
C
C
Okay,
so
is
where
the
docs
actually
are.
This
is
that
repo
that
ronan
was
in
before
that
he
was
showing
us.
You
know
the
readme
of
and
the
docs
themselves
are
in
content
and
then
they're
language,
specific
and
so
not
every
language
is
going
to
have
every
single
thing
in
it
because
it's
like
some
of
them
are
like,
for
example,
there
are
some
languages,
people
have
actually
translated
blog
posts
for
in
other
languages,
they
have
not,
and
the
the
actual
docs
themselves
again
are
organized
somewhat
like
what
you
saw
earlier,
but
yeah.
C
C
This
we
mentioned
before
is
hugo,
and
if
we
take
a
look
at
there's
front
matter,
that
needs
to
be
on
each
kind
of
page.
So
again,
if
you
try
to
start
instantiating
say
a
new
language,
just
take
a
look
at
what
exists
there
already,
because
it
makes
it
easier
to
scaffold
it,
and
I
do
want
to
talk
a
little
bit
about
that.
That
idea
of
translating
the
docs
into
an
additional
language-
and
we
have
a
recent
example-
that's
pretty
awesome
of
french,
and
so
this
is
all
community.
C
You
know
contributed
stuff
people
come
along
and
they
start
translating.
There
are,
you
know
dire
there,
there's
the
localization
guide,
that
is
the
translation
guide.
That
says
exactly
what
you
should
translate
or
what
you
should
configure
when
you're
translating,
but
there's
like
this
config.toml
that
ronan
mentioned
briefly,
you
have
to
have
a
section
in
there
and
then
you
have
to
have
like
your
at
the
at
the
bare
minimum,
probably
like
the
index
page
and
then
whatever
other
pages
that
you
want
to
translate
can
be
in
a
pull
request.
C
So
in
some
cases
we
may
not
have
reviewers
who
speak
a
language,
so
we'll
just
take
a
look
and
see.
Oh
did
they
do
anything
obvious
like
leave
some
english
in
there?
Maybe
they
don't
want
to
do
that
or
capitalization
could
be
a
problem
because
passer
case
sensitive
that
sort
of
thing.
So,
if
you're
thinking
well,
how
do
I
help
here?
You
can
review
pull
requests
either
if
they're,
in
your
language
or
in
a
different
language.
C
You
know
just
depending
on
what
you
speak
and
then
this
I
you
know,
got
merged
in
and
we
go
and
we
look
at
the
docs
and
we
think
fantastic.
We
have
french
now.
You
know.
Oh
look:
we
have
a
css
issue
that
we
need
to
fix,
but
we
have
french
now
right.
So
one
other
thing
to
note
before
I
pass
it
over
to
talk
for
martin
to
talk
more
about
code
is
there's
an
interesting
corner
case.
C
So
that's
an
interesting
corner
case
that
just
keep
in
mind
like
this
kind
of
thing
is
evolving
all
the
time.
Perhaps
hey
you'll
come
in
with
a
contribution
to
find
an
even
better
way
to
do
that,
but
anyways,
that's
the
docs,
for
the
most
part
are
in
the
depth
of
repo
and
oh
one
other
thing
about
translation.
C
C
You
know
saying:
oh
what
about
this,
what
about
this
and
and
iterating
on
it
and
making
it
better?
And
so,
if
you're
thinking
I
want
to
contribute
to
helm,
but
I'm
not
you
know
a
home
expert
or
I
don't
know
enough
go,
and
so
I
don't
know
if
I
can.
You
probably
can
just
by
contributing
this
sort
of
contribution.
C
So
all
right,
but
I
did
mention
that
a
couple
of
those
things
are
in
the
actual
code
base
because
brennan
and
I
have
been
talking
about
helm,
helm,
dub,
dub
dub,
but
there's
a
lot
going
on
over
in
helm,
helm
as
well.
So
let's
talk
about
actual
code
like
actually
getting
the
pr
is
merged.
We
have
martin
hickey
joining
us
today
to
talk
about
that.
I'm
gonna
stop
sharing
my
screen
and
let
martin
share.