►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Good Governance Practices for CNCF Projects - Dawn Foster, VMware
Too many maintainers think they don’t need governance ... until something goes wrong. Undefined or inadequate governance results in a lack of transparency that causes confusion over how decisions are made, unrealistic expectations, and unresolved disagreements. The CNCF helps projects adopt good governance practices with a focus on fair and transparent governance from sandbox to incubating to graduated. This talk will cover * Why governance is important * Selecting an appropriate governance model * Templates with patterns that work well to bootstrap CNCF projects * The role of mission, values, and scope in setting expectations * Defining roles, responsibilities, processes, and procedures within your governance model * Contributor ladders to help people move into leadership positions * The governance pros and cons of contributing a project to the CNCF The audience will get practical advice about creating fair and neutral governance structures and processes for open source projects.
A
I'll
also
cover
how
corporate
ownership
can
impact
your
project
and
whether
contributing
your
project
to
the
cncf
might
or
might
not
be
a
better
choice
for
your
project
than
keeping
it
internally.
Then
I'll
conclude
with
links
to
some
resources
and
a
few
final
thoughts,
but
first
I'll
start
by
telling
you
just
a
teeny
bit
about
me.
A
I'm
also
on
the
steering
committee
for
the
linux
foundation's
to-do
group.
I'm
a
board
member
at
open
uk
I'm
a
governing
board
member
and
maintainer
for
the
linux
foundation's
chaos,
metrics
project,
and
I
have
a
phd
that
I
got
by
researching
how
people
collaborate
within
the
linux
kernel.
So
you
can
call
me,
dr
dawn.
A
I
spend
a
fair
amount
of
time
as
part
of
my
work
as
co-chair
within
the
cncf
contributor
strategy,
technical
advisory
group,
so
tag
contributor
strategy,
especially
as
part
of
the
governance
working
group,
where
we
put
together
guidance
and
templates
for
cncf
projects.
So
quite
a
bit
of
the
work
that
we've
done
collectively
as
a
part
of
that
group
is
the
foundation
for
this
presentation
and
you'll
see
loads
of
links,
just
sort
of
sprinkled
throughout
the
presentation
to
some
of
our
resources.
A
Now
a
lot
of
people
like
to
hate
on
governance.
It's
just
it's
just
paperwork!
It's
busy
work!
It's
politicking!
That
gets
in
the
way
of
doing
the
real
work
on
the
project,
but
this
isn't
true
of
good
governance,
which
is
really
about
getting
your
ducks
in
a
row.
Just
like
the
slide
to
generate
alignment
and
get
all
of
the
various
people
within
your
community
actually
collaborating
together.
A
A
Now
governance
helps
outline
the
expectations
around
roles
and
responsibilities
along
with
the
decision-making
processes.
So
it's
important
to
have
these
in
place.
Early
governance
can
be
found
in
all
open
source
projects
in
one
form
or
another,
to
specify
the
processes
for
how
people
work
together
within
the
project.
A
This
doesn't
mean
that
you
need
to
specify
everything
up
front
and
I
would
discourage
you
from
over
engineering.
Your
governance
processes
before
you
need
them
a
project
with
only
a
few
people
will
not
need
elaborate
elections
to
select
your
maintainers
or
leaders,
but
you
should
probably
define
a
few
basic
roles:
the
process
for
contributing
to
your
project
and
how
decisions
about
those
contributions
are
made.
A
The
goal
should
be
to
make
the
processes
for
participation
as
obvious
as
possible,
even
for
people
who
are
brand
new
to
the
community
having
clear
rules
about
how
collaboration
occurs
and
how
decisions
are
made.
Helps
community
members
make
contributions
that
are
likely
to
be
accepted
and
embraced
by
the
project.
A
Now
I
suspect
that
some
of
you
are
still
thinking
that
you
really
don't
need
governance.
You
don't
need
to
spend
that
time
documenting
it.
But
if
you
think
about
this
from
the
perspective
of
the
brand
new
user,
the
brand
new
contributor
it's
much
more
difficult
to
participate
in
a
community.
If
you
don't
know
anything
about
the
role
you
might
play,
the
expectations,
the
key
players
or
the
rules
for
participating,
explicit,
documented
governance
gives
new
and
existing
contributors
a
clear
path
to
help
guide
them
through
your
project.
A
A
What
happens
when
a
decision
seems
unfair
or
technically
questionable,
and
it's
not
clear
who
made
that
decision
or
where
to
escalate
it?
This
leaves
community
members
frustrated
and
can
cause
people
to
lose
respect
for
the
project
and
also
lose
respect
for
the
people
who
are
running
the
project
which
can
lead
to
projects
becoming
unviable.
If
that
dynamic
continues
and
people
aren't
interested
in
participating.
A
Now,
the
good
news
is
that
tag,
contributor
strategy
and
other
cncf
groups
are
here
to
help
you.
We
have
loads
of
resources
for
you
to
use
to
make
it
easier
to
get
started
with
leadership,
selection
and
other
governance
documentation,
including
several
governance
templates,
that
any
project
can
use.
A
A
However,
we
do
not
recommend
waiting
until
you
get
close
to
graduating,
having
clearly
documented
governance
model
from
the
start,
even
before
you
apply
to
sandbox
with
something
really
simple
will
make
your
application
even
stronger.
As
you
move
through
sandbox
and
into
incubating
for
the
incubating
stage,
the
cncf
requires
that
the
project
have
a
healthy
number
of
committers,
as
defined
as
someone
who
can
accept
contributions
and
do
some
or
all
of
the
project.
A
While
a
governance,
dot,
md
and
owner's
files
aren't
explicitly
required
at
the
incubating
stage.
You
will
find
it
very
difficult
during
the
due
diligence
process
to
prove
that
you
have
a
healthy
number
of
committers
without
a
documented
governance
model.
So
we
really
might
recommend
that
you
have
it
way
before
you
start
the
process
to
become
an
incubating
project.
A
The
other
governance
templates
are
really
useful
in
certain
situations
for
larger
projects.
A
small
project,
as
I
said
before,
does
not
need
elections,
but
when
you
start
to
get
a
lot
of
contributions
from
people
working
at
a
wide
variety
of
organizations,
an
elected
steering
committee
or
technical
oversight
committees
can
really
help.
You
ensure
that
the
project
is
governed
in
a
neutral
way
that
doesn't
bias
the
project
toward
a
single
company.
A
We
also
have
a
subprojects
template,
which
is
a
little
bit
niche
and
is
only
used
in
cases
where
you
have
a
larger
umbrella
project
with
smaller
subprojects
underneath
that
operate
mostly
independently.
It
takes
some
ideas
from
the
prometheus
governance
and
has
been
used
by
conveyor
which
is
currently
applying
to
the
cncf.
A
I
mentioned
earlier
that
governance
is
all
about
alignment
and
getting
all
of
the
various
people
within
your
community.
Collaborating
together
and
setting
clear
expectations
helps
facilitate
that
alignment.
One
way
you
can
set
expectations
is
by
being
clear
about
the
mission,
values
and
scope
for
the
project.
To
avoid
misunderstandings.
A
You
should
also
plan
for
your
mission,
scope
and
values
to
evolve
over
time
as
your
project
grows
and
changes,
and
the
link
on
the
slide
talks
more
about
each
of
these
pieces
with
examples
from
cncf
projects
to
get
you
started
now.
In
most
open
source
projects,
there
isn't
anything
labeled
as
a
mission
statement,
but
there's
usually
something
that
talks
about
the
purpose.
The
advantages
and
the
key
features
for
your
project.
A
A
This
can
avoid
situations
where
some
new
user
or
contributor
starts
using
your
project
under
the
assumption
that
they
can
contribute
some
feature,
that's
key
to
their
business
or
their
that
they
absolutely
need,
and
then
they
realize
it's
going
to
be
out
of
scope,
possibly
for
very
good
architectural
reasons
or
whatever.
But
you
could
have
saved
them
some
time
by
documenting
your
scope
to
help
set
those
expectations.
A
A
I've
included
a
few
examples
that
are
commonly
used
in
open
source
projects,
but
these
are
not
a
repeat,
not
a
one-size-fits-all
approach.
They
do
need
to
be
customized
to
reflect
how
you
work
within
your
project,
and
they
should
be
realistic
and
achievable
if
you
can't
actually
live
up
to
the
values
or
principles
documented
for
your
project,
you're
setting
yourselves
up
for
misunderstandings
and
disappointed
community
members
and
contributors
I
mentioned
a
few
times
earlier.
A
A
This
includes
details
about
any
contributor,
license
agreements
or
developer
certificate
of
origin
processes
that
you
might
have,
and
if
you
have
strong
preferences
about
things
like
coding,
style,
testing,
documentation
or
other
requirements,
this
is
a
good
opportunity
to
make
sure
that
new
contributors
know
these
up
front
to
make
it
easier
for
them
to
participate
and
reduce
work
or
reduce.
Rework
you
want
to
make
sure
that
your
contributors
know
what
to
expect
and
how
to
navigate
the
project
when
they're
making
their
contributions.
A
The
communication
process
should
be
clearly
defined,
so
people
know
where
and
how
to
communicate
with
the
project.
Maybe
you
prefer
mailing
list
discussions
or
slack
messages
or
issues
for
feature
requests.
Maybe
you
prefer?
Maybe
you
have
separate
communication
channels
for
users
and
developers
make
sure
that
everyone
understands
how
people
within
the
community
can
be
within
the
project
communicate
with
each
other
to
avoid
a
frustrating
experience
both
for
new
and
the
existing
contributors,
not
strictly
governance.
Related
security
is
kind
of
a
related
topic,
and
I
wanted
to
mention
that
tag.
A
You
should
be
using
some
automated
tools,
like
dependable,
for
example,
to
help
keep
up
on
top
of
potential
security
issues.
The
project
should
have
a
security.md
file,
along
with
possibly
other
documentation
with
details
about
the
process
for
reporting
and
then
responding
to
security
concerns
at
a
minimum.
You'll
want
to
have
a
way
for
people
to
privately
report
security
issues
and
have
a
few
people
who
are
designated
to
handle
those
issues.
A
Project
leadership
is
one
of
the
key
elements
of
good
governance,
so
you
have
some
kind
of
documentation
about
your
leadership
for
small
projects.
You
might
just
need
a
list
of
maintainers
that
indicates
which
people
are
responsible
for
various
areas
within
your
project
and
how
new
maintainers
are
selected.
A
Defining
the
roles
and
responsibilities
for
contributors,
reviewers
and
maintainers
is
probably
enough
as
a
first
step
which
can
help
with
recruiting
people
into
these
roles,
and
I
talked
about
the
contributor
ladder
earlier
and
it's
important
to
make
sure
that
people
understand
how
they
can
climb
this
ladder
and
gain
responsibility
within
your
project
for
bigger
projects.
You'll
want
to
have
more
details
about
the
specific
responsibilities
for
each
leadership
role.
A
Along
with
how
people
can
move
into
various
different
types
of
leadership
positions,
you
might
have
committees,
working
groups,
special
interest
groups
or
other
groups
that
will
need
leaders
and
again
having
having
this
all
documented,
can
really
help.
You
recruit
new
leaders
as
you
grow
the
project
and
need
more
people
to
share
the
workload,
because
you
will
need
more
people
to
share
that
workload.
A
Most
of
the
bigger
projects
like
kubernetes
k-native
have
an
election
process,
at
least
for
the
the
top
levels
of
leadership
like
the
steering
committee
or
technical
oversight
committees
at
lower
levels
of
leadership.
Most
projects
have
a
process
where
existing
leaders
get
to
select
new
leaders.
So,
for
example,
new
maintainers
are
often
nominated
by
existing
maintainers
and
approved
after
a
certain
percentage
or
number
of
maintainers
agree.
A
There
are
a
bunch
of
different
options
for
selecting
leaders,
so
I'm
not
going
to
try
to
cover
all
of
them
here,
but
this
link
at
the
bottom
there's
an
entire
document
devoted
to
these
various
options.
So
you
can
visit
that
link
and
and
get
more
and
also,
I
should
mention
the
slides
are
already
up
on
sketch.
So
if
you
need
the
links
there
they're
already
there,
your
project
governance
should
be
designed
to
keep
diversity,
equity
and
inclusion
top
of
mind.
Building
a
diverse
community
where
all
people
feel
welcome
and
included,
does
not
just
happen.
A
It
requires
putting
work
and
thought
into
it
and
when
you're
starting
a
project
and
thinking
about
governance,
this
is
the
perfect
time
to
do
that.
Providing
an
environment
where
everyone,
including
people
from
marginalized
populations,
feel
safe,
is
the
first
step
toward
building
a
diverse
community
around
your
project.
A
A
The
kubernetes
contributor
experience
special
interest
group
is
a
great
place
to
see
examples
for
how
to
implement
programs
for
things
like
shadowing
and
mentoring,
projects
that
make
a
concerted
effort
to
actually
bring
new
people
in
from
a
variety
of
backgrounds
and
have
programs
in
place
to
help
them
grow
into
leadership.
Positions
are
more
likely
to
benefit
from
increased
innovation
and
have
a
healthier
community.
A
Now.
Diversity
and
inclusion
can
also
be
difficult
to
measure,
but
we've
defined
a
bunch
of
metrics.
You
see
the
link
here
within
the
chaos
projects,
diversity
and
inclusion
working
group.
So
you
can
have
a
look
at
that
for
ideas
about
how
you
can
measure
various
aspects
of
your
project
so
that
you
can
improve
your
projects,
diversity,
equity
and
inclusion.
A
One
of
the
reasons
that
kubernetes
has
been
so
successful
is
because
it
was
contributed
to
the
cncf,
putting
kubernetes
into
a
neutral
foundation,
provided
a
level
playing
field
where
people
from
a
whole
bunch
of
different
companies
could
work
together
as
equals
to
create
something
that
benefits
all
of
us,
the
entire
ecosystem
at
vmware.
We
believe
that
contributing
open
source
projects
to
neutral
foundations
is
important,
and
it's
something
that
we
do
regularly
for
projects
once
they
start
to
get
a
bit
of
traction
from
people
outside
of
our
company.
A
Now,
the
challenge
with
contributing
projects
to
the
cncf
is
that
you
also
give
up
some
of
your
control.
Existing
maintainers
will
usually
keep
their
positions.
However,
as
we
talked
about
earlier,
the
cncf
will
want
to
make
sure
that
it's
easy
for
people
from
other
companies
to
participate
and
move
into
leadership
positions.
So
as
the
contributing
company,
you
should
expect
for
some
leadership
positions
to
transition
to
people
from
other
companies,
at
least
over
the
longer
term.
A
A
It
is
not
an
exit
strategy
and
we
need
to
be
prepared
to
provide
staff
and
other
support
over
both
the
short
term
and
the
long
term
for
this
project,
just
like
we
would,
if
we
weren't
contributing
it
to
the
cncf,
the
cncf
will
expect
you
to
do
that.
Expect
you
to
do
the
hard
work
of
building
a
community
growing
your
contributor
base,
getting
adopters
and
all
of
the
other
hard
work
that
comes
with
building
a
healthy
and
successful
open
source
project.
A
A
Governance
is
one
of
those
things
that
is,
it's
never
finished
right,
so
we
work
in
a
space
with
constant
change,
technologies,
change,
strategies,
change
the
whole
way.
We
work
changes,
everything
changes
and
our
governance
needs
to
evolve
right
along
with
these
changes
in
particular,
open
source
projects,
as
they
become
more
mature
and
grow.
What
they
need
from
governance
will
change
pretty
dramatically
the
governance
processes
you
need
when
you
have
a
single
or
only
a
couple
of
maintainers,
is
likely
to
be
insufficient
if
the
project
grows
dramatically.
A
Before
I
wrap
up
this
talk,
let
me
leave
you
with
a
few
resources
that
you
might
find
useful,
so
you've
seen
the
links
from
the
contributor
strategy
tag,
sprinkled
throughout
the
presentation.
The
open
source
way
guidebook
has
an
entire
chapter
on
governance,
along
with
loads
of
other
details
about
open
source
projects.
The
to
do
group
has
a
bunch
of
guides
about
creating
and
managing
open
source
projects,
and
these
are
all
great
starting
points.
A
Now.
I've
talked
a
lot
about
tag
contributor
strategy
today
and
here's
where
you
can
find
us
to
get
help
for
your
project
or
to
volunteer
to
help
us
to
build
new
resources,
we're
pretty
active
on
slack
and
that's
a
good
way
to
reach
all
of
us.
The
mailing
list
is
relatively
low
volume
and
it's
a
great
way
to
get
notified
about
meetings
and
other
tag
activities.
A
As
I
mentioned
earlier,
you
can
drop
into
our
meetings
to
get
advice
or
to
join
us,
and
I
encourage
cncf
maintainers
to
participate
in
our
maintainer
circle
meetings.
If
you
need
a
resource
that
doesn't
exist,
there's
a
good
chance
that
someone
else
needs
it
too.
So
we
encourage
you
to
join
us
and
help
us
build
new
resources.
A
Now,
we've
only
been
around
for
a
little
over
two
years
and
we
have
loads
of
ideas
on
our
backlog,
but
only
so
many
people
to
work
on
them.
Anyone
can
drop
into
our
meetings
if
you'd
like
to
join
us
and
build
something
together
or
just
to.
Let
us
know
what
you
need
tag.
Conservator
strategy
is
more
than
a
place
to
develop
resources,
we're
creating
a
cross-project
community
of
maintainers
that
can
connect
exchange
ideas
and
support
each
other.
A
There
are
so
many
aspects
of
good
governance
for
open
source
projects,
and
I
only
had
time
to
talk
in
detail
about
some
pieces
of
them,
but
taking
a
step
back
and
looking
at
the
big
picture.
What
I
have
here
on
the
slide
is
the
common
theme
that
drives
why.
I
think
that
governance
as
a
whole
is
so
important.
A
Governance
provides
a
framework
for
setting
expectations
for
roles
responsibilities
and
how
people
within
your
project
should
behave
by
clearly
documenting
these
expectations.
You
can
reduce
uncertainty
and
make
it
easier
for
people
to
know
how
to
participate
in
your
project.
The
more
you
can
do
to
help
everyone
participate
in
meaningful
ways.
The
more
welcome
they'll
feel
within
your
open
source
community
with
that.
Thank
you
for
coming
to
my
talk
and
we
can
open
it
up
for
questions.
B
Hi
hi,
I
love
this
talk
because
I
am
a
technical
writer
and
basically
the
summary
of
this
talk
was:
you
need
to
write
documentation
on
dot
dot
dot.
So
my
question
for
you
from
a
maintenance
perspective
and
for
somebody
who
has
quite
a
bit
of
experience
in
open
source
is
what
have
you
seen
go
wrong
as
a
result
of
people?
Not
writing
their
governance
down.
A
A
C
A
So
for
vmware
in
particular,
it's
a
pretty
easy
sell
for
us
to
get
people
involved
in
the
cncf
cloud
native
projects
like
kubernetes,
because
we're
building
entire
product
lines
on
top
of
these
technologies.
So
we
can
make
a
case
that
it's
strategic
and
it's
important
for
vmware
for
us
to
be
there
for
other
projects.
It's
always
harder
to
make
that
case,
but
you
know
generally
the
the
case
that
it's
the
right
thing
to
do.
It's
charity.
It's
a
it's
a
good
thing
for
the
community.
Those
generally
don't
fly
with
executives.
A
B
C
A
No,
we
we
do
talk
about
that.
A
lot
within
the
contributor
strategy,
sig
for
sure
we
actually
have
another
working
group.
That's
called
the
contributor
growth
working
group
that
tends
to
dive
more
deeply
into
that
particular
topic.
So
if
you're,
you
know,
if
you're
part
of
a
cncf
project
and
your
your
challenge
is
trying
to
get
people
in
involved
in
your
project,
you
can
come
hang
out
with
us
and
chat
with
us.
You
can
talk
to
us
on
slack.
You
can
drop
into
one
of
our
meetings.
D
Hi,
thank
you
for
the
talk
I
wanted
to
ask.
If,
once
a
project
is
part
of
cncf,
is
there
a
framework
that
cncf
kind
of
holds
the
projects
accountable?
If
that
they
are
sticking
to
the
contributor
guidelines
or
being
more
inclusive?
Is
there
a
framework
around
that
that
the
cncf
implements
in
terms
of
licenses
as
well
in
terms
of
people
who,
in
terms
of
giving
up,
control
and
letting
other
people
join
the
project.
A
A
However,
there
are
things
like
like
annual
reports
that
projects
report
out
on
and
how
they're
doing,
and
so
the
cncf
sees
those
and
then
there's
also
the
process
of
moving
from
sandbox
to
incubating
to
graduated,
which
is
another
another
sort
of
checkpoint.
So
I
would
say
the
cncf
has
checkpoints
for
projects
and
we
provide
guidance
and
help
and
and
information,
but
we
do
kind
of
leave
it
up
to
the
individual
projects
to
to
build
their
own,
build
their
own
communities,
get
their
own
adopters
and
and
put
together
things
like
governance,
documentation.