►
From YouTube: Taking the Helm: Becoming a Maintainer - Bridget Kromhout & Matt Butcher, Karena Angell, Matt Farina
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Taking the Helm: Becoming a Maintainer - Bridget Kromhout & Matt Butcher, Microsoft; Karena Angell, Red Hat; Matt Farina, Rancher Labs
As a graduated CNCF project, Helm is well-known as the package manager for Kubernetes. Despite being established for years, Helm continues to require ongoing work in the realm of growing the maintainer community. Join long-time and new Helm maintainers as we discuss scaling an open source project, illustrated by specifics from Helm’s journey. We’ll talk about where new contributors can make the most impact and how to navigate when the waters get choppy. Learn about where the Helm project is headed and how you can help steer it!
A
C
A
So
it's
about
coming
up
on
its
sixth
anniversary
here
soon
and
the
idea
was
to
make
it
provide
a
way
that
made
it
easy
to
get
started
with
kubernetes
by
installing
packages
off
the
shelf
and
then,
as
you
got
comfortable
with
that
particular
workflow,
we
wanted
to
make
it
easy
for
you
to
be
able
to
compose
your
own
packages.
So
packages
in
helm
are
called
charts.
A
A
So
we
will
talk
a
little
bit
in
this
session
about
the
community,
which
means
you
know
the
the
group
of
people
who
are
all
collectively
working
on
it,
whether
that's
filing
issues
or
opening
prs
or
even
doing
maintainer
things
like
reviewing
code
and
signing
off
on
security
things
and
here
and
there
we'll
talk
about
charts,
repos
and
github
actions
and
other
tooling.
That
has
come
around
over
the
last
six
years
of
our
development.
C
B
Yes,
so
helm
was
originally
started.
We
had
the
package
manager,
but
you
end
up
needing
and
desiring
more
than
that
and
over
time,
more
sub
projects
and
documentation,
and
things
have
come
to
life
from
the
helm
community
from
the
helm
project
to
support
those
who
are
creating
packages
and
working
with
helm.
And
so,
if
you
go
over
to
the
helm.org
on
github
you'll
see
quite
a
few
repos
and
they
do
various
things
these
days
we
have
tools
for
performing
things
like
testing
and
to
help
you
test
your
charts.
B
We
have
github
actions,
we
have
just
a
number
of
tools
there
and
contributing
to
the
helm.
Project
can
be
contributing
to
any
of
those
things
and
it
doesn't
all
have
to
be
code
either.
All
of
these
projects
have
documentation
and
we
have
a
site
and
even
translations
of
the
documentation
site,
and
so
there's
lots
of
opportunity
to
contribute
from
code
to
various
toolings
around
the
primary
things
to
docs,
and
so
there's
a
lot
that
people
can
get
involved.
In
now,.
C
When
you
know,
as
perhaps
a
new
user
slash
interested
in
contributing
slash
interested
in
maintaining
helm,
when
you
take
a
look
at
this
karina,
what
do
you
immediately
have
questions
about,
or
what
do
you
immediately
say?
Oh,
that
looks
like
it's
interesting
like
what
stands
out
to
you
when
you
start
looking
at
this
project.
C
B
So,
for
example,
if
in
your
pipeline
you
want
to
test
a
chart
and
you
want
to
use
helm
and
you
want
to
test
these
things,
we
have
a
tool
called
chart,
testing
abbreviated
ct,
and
so,
if
you
go
to
github.com
helm,
slash,
chart
testing,
you
can
find
a
chart
testing
tool,
and
this
goes
above
and
beyond
anything
you'll
find
in
the
core
helm.
You
know
client
as
far
as
linting
and
providing
test
functionality.
B
It
builds
on
that
to
give
you
more
and
so,
for
example,
from
that,
you
can
take
a
chart
with
multiple
different
configurations
passed
in
and
you
can
run
that
in
say.
Maybe
a
kind
cluster
running
right
inside
of
your
ci
system,
and
it
provides
a
simple
way
to
do
that
and
that's
one
of
the
ways
to
get
started
in
your
workflows
and
then,
if
you
wanted
to
say,
use
that
in
a
github
action
right.
A
A
I
could
have
spent
days
or
weeks
even
setting
up
these
actions
and
the
team
that
built
the
actions
for
us
is
the
team
that
has
managed
the
chart
repository
for
years
now
and
when
you
talk
about
expertly
crafted
code,
this
stuff
has
just
been
phenomenal
for
getting
started
very
quickly.
So
if
you're
in
one
of
those
people
who
would
like
to
start
working
on
some
github
actions
to
get
your
workflows
to
get
your
charts
tested
and
some
workflows
set
down,
I
highly
highly
recommend
the
work
by
that
team.
C
A
contribution
we
don't
even
know
to
ask
for,
but
I'm
interested
butcher,
if
you
want
to
give
us
some
insight
into
when
you
were
first
coming
up
with
helm
versus
the
kind
of
questions
people
are
asking
now.
What
what
have
you
seen
in
the
evolution
of
what
people
are
trying
to
do
with
package
management.
A
A
Helm
likewise
had
to
change
and
go
from
moving
fast
and
breaking
things
to
being
stable
and
in
some
ways
the
pressure
on
us,
I
think,
has
been
a
little
bit
higher
than
many
of
the
other
ecosystem
projects,
because
helm
ends
up
getting
used
to
manage
multiple
versions
of
kubernetes
and
multiple
instances.
Of
of
all
these.
You
know
service
meshes
and
things
like
that,
and
so
there's
a
sense
in
which,
if
helm
breaks,
people
lose
their
ability
to
effectively
manage
their
other
systems.
A
So
there's
you,
you
get
this
kind
of
cascading
effect,
in
other
words,
which
is
part
of
the
reason
why
we
have
become
very,
very
risk-averse
as
far
as
taking
prs
and
why
things
sit
in
our
issue,
queue
and
get
reviewed,
lots
and
lots
of
times
and
why
the
security
team
will
flag
issues
and
say:
we've
got
to
review
this
before.
We
merge
it,
because
we're
very
aware
at
this
point
that
if
we
do
things
wrong,
we
costs
and
big
enterprises
and
small
businesses
and
everybody
in
between
frustration,
downtime
and
things
like
that.
A
So
it
really,
our
culture
has
evolved
from
being
very
much
a
cutting
edge,
trying
all
these
new
things
very
very
rapidly
to
one
that's
very
slow
and
methodical.
Some
of
the
new
processes
like
the
hip
process
and
our
longer
review
processes
and
our
bi-annual
security
reviews
are
all
processes
that
feed
into
that
long-term
stability.
C
D
Coming
in
it
was
first
had
to
figure
out
that
the
process
did
change
right,
and
I
know
that
was
communicated,
and
I
missed
that
communication
and
so
and
then
finding
the
hip
process,
and
it's
great
that
it's
documented
it's
on
the
the
repo,
but
then
from
there
when
you
create
the
hip.
What
is
the
process
going
through?
D
B
B
That's
difficult
to
maintain,
and
so
it
leads
to
just
something
that's
hard
to
maintain,
and
we
don't
want
to
do
all
of
that.
Just
like
you'll
see
with
kubernetes.
Now
all
of
these
controllers
and
extensions
and
direction
people
want
to
go
in
they're,
not
part
of
core
kubernetes
they're
part
of
the
ecosystem
and
kubernetes
is
very
focused
on
stability
in
its
api
and
what
it
offers.
B
But
it
gives
you
the
ability
to
extend
it,
and
things
really
have
to
show
themselves
to
be
useful
to
a
mass
majority
of
people
to
to
get
in
now,
and
I
think
helm
is
kind
of
that
same
way.
If
it's
a
core
helm
core
package
management
thing
for
those
people
who
want
to
run
their
workloads,
then
that's
that's
a
great
thing
to
have
in
there.
B
But
if
it's
going
to
be
something
outside
of
that
or
maybe
more
of
a
niche
feature
and
use
case,
then
that's
the
perfect
place
for
an
extension
if
it's
below
helm
or
a
tool
that
sits
above
helm,
that
tries
to
do
this
so
helm's
a
package
manager,
and
if
you
want
to
get
into
configuration
management
that
might
be
a
place
for
helm
file
or
something
else
just
like
you
would
have
terraform
and
chef,
and
that
would
deploy
your
app
packages
or
you
know
your
debian
packages.
Things
like
that.
C
I
think
some
of
the
most
contentious
issues
have
been
the
ones
where
people
say,
but
I
want
helm
to
be
a
floor
wax
and
a
dessert
topping.
Why
can't
home
do
all
of
the
everything's
I
love
helm.
I
only
want
to
live
in
helm
and
you're,
like
that's
going
to
make
how
unmaintainable
for
everyone
else,
and
so
that
I
think
this
is
a
this-
is
a
good
segue
to
how
does
helm
the
project
even
make
those
decisions.
C
C
A
Guiding
sort
of
mission
statement
more
or
less
about
home
that
helm
is
the
package
manager
for
kubernetes.
So
if
it
falls
outside
of
general
package
management,
then
then
it's
unlikely
that
it's
going
to
make
it
inside
in
general.
So
there's
a
certain
sense
in
which
people
will
open
a
pr
to
add
the
floor.
A
You
might
not
want
to
dive
in
and
write
a
five-page
hip
or
a
three-page
hip
or
whatever,
and
that's
why
we
have
things
like
the
helm
developers
call,
which
is
a
great
place
to
kind
of
drop
in
and
get
to
ask
in
real
time,
or
you
know
the
the
the
helm
developers.
Slack
is
another
good
place
to
ask
in
kubernetes.
A
Sorry,
kubernetes
slack,
helm,
dev
channel
is
what
I
am
trying
to
say
there
and
then
the
the
third
option
would
be
to
open
an
issue.
Saying
hey.
I
I'm
thinking
of
this
feature.
Is
this
the
right
kind
of
feature
to
go
in
home
core,
and
should
I
write
a
hip
or
is
this
something
that's
just
out
of
scope
or
would
be
better
as
a
as
a
helm,
plug-in
or
something
like
that?
A
C
I
think
maybe
we
should
also
clarify
that
if
you
want
to
get
a
small
change
into
helm,
you
don't
have
to
write
a
proposal
first,
it's
more
that
if
you
want
to
do
something
that
is
a
significant
departure
from
what
is
already
happening
in
helm
and
might
have
breaking
changes.
You
probably
don't
want
to
spend
a
ton
of
time
writing
some
code
in
order
to
hear
that
it's
not
in
any
way
going
to
be
merged
for
the
next
six
months.
Minimum
farina.
C
B
So
this
kind
of
goes
along
with
how
we
approach
longevity
and
stability.
Lots
of
things
are
changing
in
the
cloud
native
ecosystem
and
we're
kind
of
slow
to
change,
to
bring
a
point
of
stability
in
there
and
so
helm
version
four,
which
is
when
we
can
break
when
we
break
major
apis
when,
when
we
just
start
changing
things
in
ways
that
aren't
backwards
compatible
for
ci
scripts
and
other
things,
that's
a
little
ways
off.
We
have
just
started
to
have
the
conversations
about
hey.
B
A
The
home
three
life
cycle,
like
I
said
before,
is
about
midway
through
the
big
items
still
left
in
home.
Three
are
a
lot
of
these
efforts
to
just
sort
of
solidify
and
fix
little
things
here
and
there
to
make
sure
everything
is,
is
aligned
well
and
hopefully
to
move
the
oci
regis
registry
stuff
from
experimental
and
be
able
to
remove
that
experimental
flag
and
have
that
in
production.
So
those
are
two
two
things
I'd
really
like.
A
A
In
fact,
we
really
got
that
kick
started
last
year,
but
we
still
need
to
keep
keep
things
moving
on
that
we
actually
need
to
do
a
little
bit
of
a
pass
over
the
core
documentation
just
because
documentation
tends
to
get
stagnant
over
time,
and
you
know
here
and
there
like
we'll
stumble
across
paragraph
and
say:
oh,
this
still
refers
to
helm
too
and
somehow
it
slipped
through
the
cracks
and
nobody's
found
that
and
fixed
that
yet
and
then
the
third
one
is.
We
really
need
to
get
stronger
in
the
core
maintainership
of
helm.
A
What's
happened
is
helm
being
a
six-year-old
project
and
an
open
source
project.
It
means
that
naturally,
people
tend
to
cycle
through
people
work
on
this
for
a
while
as
their
day
job,
and
then
you
know
for
a
little
while
on
nights
and
weekends,
and
then
they
have
other
obligations
that
take
over
it.
A
A
2021
in
fact
has
been
to
bring
in
some
new
core
maintainers
and
help
re-divvy
out
the
responsibilities
to
so
that
we
can,
you
know,
be
a
little
more
diligent
on
the
hip
process,
for
example,
instead
of
trying
to
do
that
after
going
through
and
triaging
all
the
issue
queue
and
reviewing
prs
and
things
like
that
when
you're
already
burned
out
and
don't
want
to
do
anything
anymore,
so
those
are
kind
of
the
three.
I
guess
that's
for
now.
Four
big
things
that
would
be
on
my
wish
list.
B
On
my
wish
list
is,
is
again
yeah
bringing
in
more
maintainers
and
having
just
folks
who
are
more
active
in
the
project,
because
I
think
that's
going
to
also
spur
on
more
innovation
around
home,
and
so
I
think,
having
more
people
involved
will
make
it
the
project
stronger.
So
that
way
we
can
have
a
better
helm
version
4
than
we
would
have
with
what
we
have
now,
and
so
that's
kind
of
I
see
the
next
steps.
B
We're
going
to
have
some
more
features
come
in
and
we'll
grow
the
maintainership,
and
then
that
will
spur
on
here
is
how
the
cloud
native
ecosystem's
changing
here's,
how
people
are
using
things
a
little
bit
different.
Here's
some
lessons
learned
about
helm
along
the
way
and
as
we
roll
into,
hopefully
something
like
2022,
we'll
be
able
to
start
really
going
after
a
helm
version
4
with
some
some
great
and
useful
inspiration.
C
And
I
will
add
to
that
that
I
want
to
keep
improving
the
documentation,
but
also
improve
the
workload
distribution.
Get
more
people
reviewing
issues
get
more
people.
Testing
prs,
improve
the
tooling
around
that
to
make
it
easier
for
people
to
continue
to
bring
their
ideas
in,
and
also
just
frankly,
their
energy
and
their
time
and
their
desire
to
improve
it,
because
I
think
that's
that's.
How
we're
going
to
get
better
is
more
community
involvement.
We
have
lots
of
things
that
we
want
and
we're.
D
A
Not
necessarily
what
kind
of
big
changes
can
we
make
in
home
three,
and
I
mean
our
process
tends
to
be
about
halfway
through
the
development
of
one
life
cycle
of
one
version.
We
start
to
think
about
the
next
version,
and-
and
so
it
really
does
make
sense,
to
try,
try
out
some
new
ideas
on
the
helm4
side.
You
know
being
the
advocate
of
the
hip
proposal.
A
So
you
know
if,
if
your
kind
of
mode
of
thinking
is
doing
things
that
way,
that
is
a
great
way
to
do
that
kind
of
stuff,
because
we
have
the
plug-in
system
in
helm
and
because
it's
relatively
integrated
with
the
rest
of
the
the
helm
flow
of
doing
things
a
lot
of
times.
You
can
also,
in
that
pre-helm4
phase
mock
out
the
idea
as
a
plug-in
and
post
that
plug-in
in
the
github
repo,
with
directions
on
hey
grab.
This
run
this
command
and
see
what
happens
and
we're
thinking.
A
A
I've
recently
have
been
been
experimenting,
a
little
bit
about
different
ways
of
doing
storage
and
signing
and
verification
and
retrieval
to
make
it
a
little
more
secure
I'll,
be
doing
all
that
work
as
a
plug-in,
and
if
I
can't
make
it
work,
you
know
I'll,
throw
it
away,
and
if
I
can,
then
I
can
point
people
to
it
and
say:
could
we
do
something
like
this
for
home
four,
because
prs
against
helmet
three
to
show
something
in
home?
Four
are
always
kind
of
a
little
a
little
difficult
a
lot
of
times.
A
By
doing
this
kind
of
thing
in
isolation,
you
can
just
get
really
far
really
fast
because
you
don't
have
to
integrate
with
any
of
those
other
things
that
are
in
there.
You
can,
just
you
know,
show
a
more
pure
representation
of
your
idea.
So
those
are
two
ways
I
can
think
of
that.
That
would
really
help.
You
know,
transform
inner
inspiration
into
something
that
other
people
can
start
a
dialogue
and
start
experimenting
with
farina.
Do
you
have
some
other
ideas?
Besides
those
and.
B
C
Thank
you
so
much
karina
for
helping
us
make
this.
I
hope
a
little
more
approachable.
Do
you
have
any
final
thoughts
or
questions
or
ideas
that
you
want
to
make
sure
that
people
who
are
thinking
about
becoming
a
maintainer
of
a
project
like
this,
perhaps
even
this
one,
any
more
thoughts
for
them.
So.
D
B
But
there's
so
much
out
there
right
now
in
cloud
native
that
if
you
start
going
it
just
becomes
more
and
more
and
more,
and
so
I
would
argue
to
to
try
to
stay
focused
in
that
area.
That
you're
interested
in
and
if
you're
interested
in
helm,
figure
out
how
you
can
contribute
to
helm
and
engage
there
and
maybe
get
a
little
into
sig
apps
or
a
little
industry
gap
delivery.
But
if
you
do
realize,
you'll
get
pulled
in
other
directions,
and
so
I
think
focus
is
an
important
thing
in
the
cloud
native
ecosystem.
D
A
Probably
the
best
place
to
jump
in
is
to
just
take
a
look
at
the
issue.
Queue.
We
always
need
help.
You
know
reproducing
things
with
people,
adding
more
information
to
ones
where
we
can't
quite
figure
out
where
the
problem
is
there.
So,
if
you're
just
trying
to
kind
of
get
footing
there,
that's
always
good
picking
off
bug
fixes
a
lot
of
very
recently.
A
A
lot
of
the
people
who
have
been
invaluable
to
the
community
and
who
are
probably
under
recognized
at
this
point
are
the
people
who
have
gone
through
the
issue,
queue
and
said.
Oh
here's
one.
That's
marked
a
good
first
issue,
which
is
a
label
we'll
often
put
on
on
things
that
we
think
are
relatively
small
entry
points
and
they'll
pick
off.
One
of
those
and
they'll
submit
a
pr,
and
then
they'll
say:
oh,
this
isn't
too
bad
and
then
they'll
pick
off
a
slightly
bigger
one
and
submit
a
pr.
A
I
would
say
that
we
as
helm
core
maintainers,
need
to
get
a
lot
better
about
publicly
recognizing
those
people
more
than
just
lgtming
their
prs,
because
they
save
so
much
work
and
time
for
the
core
maintainers
and
a
lot
of
times.
Even
the
the
easy
ones
to
pick
off
are
often
the
ones
we
won't
do,
because
we
look
at
it
and
go
oh
well.
I
better
take
on
one
that's
more
significant
and
more
substantial
in
my
few
hours
of
time,
so
those
kinds
of
things
can
be
huge
documentation
prs.
A
A
C
I
think
it's
also
important
to
remember
that
if
somebody
takes
a
little
while
to
review
their
your
pr,
it
doesn't
mean
that
they
don't
care.
It
might
mean
that
helm
is
part
of
their
full-time
job,
but
it
is
not
100
of
their
full-time
job,
and
so
they
will
get
to
it
as
soon
as
they
can
but
hey.
This
is
why
we
want
to
grow
the
maintainer
community,
so
we
have
more
people
out
there,
testing
and
reviewing
and
merging
those
pr's.
A
A
Helm
community
is
sort
of
the
hub
for
how
we
organize
anything.
If
you've
got
questions
feel
free
drop
in
that
developer,
call
drop
in
the
kubernetes
slack
at
the
helm,
dev
channel
or
just
drop
into
that
issue.
Queue.
Thank
you
once
again
and
thank
you
very
much
karina
for
joining
us
today.
It
has
been
really
insightful
and
thank
you
for
being
open
and
honest
and
sharing
a
lot
of
that
feedback
it
as
as
core
maintainers.
We
we
like
the
challenge
of
improving
and
we
know
we've
got
work
to
do
so.