►
From YouTube: Enhancing Kubernetes: A Journey Through the KEP Process - Stephen Augustus & Jaice Singer DuMars
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Enhancing Kubernetes: A Journey Through the KEP Process - Stephen Augustus, Red Hat & Jaice Singer DuMars, Google
Developing software is hard! It can be even more challenging in a large-scale open source project with multiple companies, potentially competing concerns, timezones to scale; the list goes on. This talk will be a case study in Program, Product, and Project Management for one of the largest, most contributed to, most popular open source projects in the world, Kubernetes. We’re going to provide you with a glimpse into the history of Kubernetes feature development, followed by a deep dive on the evolution of the KEP (Kubernetes Enhancement Proposal), our current process for tracking and delivering project enhancements.
To Learn More: https://sched.co/GrTH
A
B
A
Am
Jason
de
Mars
I
work
at
Google
in
the
cloud
native,
open
source
strategy
and
I'm
a
program
manager
there
in
the
communities?
Community
I
am
co-chair
of
Sagarika
texture
and
I
lead
us
a
project
on
cig
p.m.
I
am
emeritus
leadership
for
the
release,
sig
and
form
a
release.
Leader
and
I
am
on
the
kubernetes
Code
of
Conduct
committee.
A
B
A
About
you,
just
you
know,
mine
is
surviving
lightning
strikes,
because
why
not
we're
having
a
deep
discussion
about
the
fact
that
you
can
actually
be
struck
by
lightning
in
a
car?
So
don't
think
because
you're
in
a
car,
you're
totally
safe,
you
are
not
so
yeah
I
just
want
to
start
with
a
little
bit
about
cap
history
show
of
hands
in
the
room,
because
this
is
always
interesting
who,
in
the
room,
feels
like
they
have
a
pretty
good
handle
on
what
a
kept
is.
A
Alright,
so
yeah,
so
this
idea
came
about
from
a
wonderful
gentleman
who's
sitting
over
here
in
dirtiness
Caleb
Myles
Gilman's.
Who
is
somebody
who
is
seen
the
need
for
the
ability
to
convey
value
and
Trust
across
a
community
like
kubernetes.
That's
growing
quickly
in
a
way
that
preserves
that
history
in
source
control
and
also
is
provide
certain
assurances
that
can
be
documented
programmatically.
B
So
moving
forward
in
this
kind
of
like
spectrum
of
the
history
of
caps,
we
intend
are
actually
well
a
lot
of
the
code
is
already
written
and
ready
to
provide
to
the
community
a
library
for
interacting
with
caps.
So
imagine
if
you
will
a
kept
CLI
tool
that
will
allow
allow
people
who
want
to
propose
enhancements
to
the
project.
B
So
if
we
haven't
defined
caps
before
caps,
our
kubernetes
enhancement
proposals,
so
it
will
allow
people
to
one
propose
new
enhancements
to
the
project
for
approvers
and
reviewers
within
sig's
to
actually
take
a
look
and
decide
whether
that
cap
should
be
accepted
and
rejected
or
withdrawn.
Or
what
have
you
there's?
Essentially
a
library
for
moving
through
that
flow
of
the
of
accepting
enhancement
into
kubernetes?
So
we'll
see
more
on
the
the
States
for
caps
later.
A
So
why
was
this
needed?
Why
is
this
something
that
we
need?
Doesn't
this
just
feel
like
process
for
process
sake,
or
you
know
somebody
trying
to
come
up
with
something?
Well.
Actually
it
turns
out
that
we
had
a
proposal
process
in
place
from
an
early
part
of
the
project
and
those
who
were
interfacing
with
the
proposal
process
found
it
to
be
cumbersome
to
be
not
really
useful
for
capturing
all
the
things
that
were
necessary
to
convey
value
to
people
who
read
it.
A
B
A
B
One
of
the
means
for
doing
that
is
kind
of
introducing
the
the
concept
of
having
metadata
for
all
of
the
caps
right.
So
we
talked
about
the
inconsistency
of
having
a
design
proposal
right.
You
have
at
this
point.
We
have
thirty-one
SIG's
and
you
know
every
segment
lis.
Everything
has
a
different
means
for
for
suggesting
change.
B
A
B
A
B
So
the
anatomy
of
a
kept
as
we
start
to
dive
in
a
little
bit,
so
the
the
kept
stubborn
issue
a
proposed
and
the
template
that
was
proposed.
We
have
this
concept
of
metadata
and
then
motivation
the
summary
and
the
associated
artifacts
with
the
cap,
so
we're
gonna
kind
of
break
down
each
of
each
of
those
pieces
right
there
right
so
the
metadata.
This
is
I,
think
everyone
everyone's
worked
on
kubernetes
and
it
was
used
to
seeing
a
yamo
file
at
this
point.
This
is
very,
very
similar,
so
top-down
we've
got.
A
B
A
Yeah
we'll
get
into
what
those
sections
are
in
a
moment.
So
again
we
talked
about
kept
serving
many
audiences
there's,
there's
a
lot
of
different
stakeholders
and
the
kept
process.
The
the
governance
around
they
kept
process
itself
is
within
Sagarika
texture,
but
again,
sig
PM
is
a
strong
stakeholder,
especially
in
terms
of
the
views
associated
with
multi
release,
value
delivery
and
we'll
talk
about
that
in
a
bit.
But
the
API
review
process
feeds
from
this.
The
the
the
release
process
has
a
strong
tie
to
this
as
well.
A
B
Right
so
starting
off
right
at
the
beginning
of
the
Kappa,
you
kind
of,
if
you're,
proposing
a
change,
you
want
to
understand
why
someone's
proposing
a
change
right
so
so
the
motivation
section
is
essentially
that
right,
what
is
the
need?
What
are
we
trying
to
solve
and
how
can
I
describe
the
significance
of
the
actual
problem
that
we're
trying
to
solve
right?
So
this
is
I
mean
this
is
extremely
important,
because
if
you
imagine
again
we're
talking
thirty
one
SIG's
were
talking.
B
Multiple
working
groups
we're
talking
sub
projects
across
the
entire
project,
people
that
are
living
across
time
zones
like
we
need
an
opportunity
for
people
to
have
a
singular
ingress
point
into
understanding
how
change
is
happening
when
it's
happening?
Who
is
owning
that
change
right?
So
that's
what
the
motivation
section
is
about.
Yes,.
A
Also
think
of
the
motivation
of
a
campus
being
I
have
something
that
I
want
to
accomplish
within
communities
and
I
have
I.
Don't
necessarily
have
the
power
on
my
own
to
do
that
and
so
you're
creating
the
the
motivation
as
a
way
to
also
motivate
the
reader
to
want
to
be
involved
in
what
you
are
delivering.
A
So
if
I've
got
ten
things
that
I'm
working
on
and
I'm
gonna
have
to
bump
one
of
those
things
to
work
on
another
thing,
the
motivation
should
convey
the
significance
and
the
important
all
the
things
that
are
necessary
around
what
you
want
to
accomplish,
so
that
it
draws
other
people
into
the
work
and
draws
a
cig
into
the
work
and
draws
whoever
the
stakeholders
are.
So
the
motivation
becomes
a
key
part
of
conveying
the
value
of
what
you're
doing
and
also
the
urgency
and
the
importance
of
it.
B
Now
we
have,
in
addition
to
the
motivation
and
essentially
summarizing
what
the
what
the
enhancement
proposal
is
about.
We've
got
all
of
these
artifacts
right,
so
common
questions
around
kubernetes
are
well.
If
I'm
developing
some
new
API
are
I'm
developing
an
extension
for
an
API.
How
do
I
actually
do
that
right
if
I
am
an
operator
now
that
you
know
now
that
this
enhancement
has
been
proposed
or
it's
an
analysis
state?
How
do
I
actually
consume
that
and
provide
feedback
right?
So
we
have
the
concept
of
guides
developer
guides
operator
guides
a
teacher's
guide.
B
If
I'm
going
to
tell
you
how
to
do
this
in
future,
how
do
I
do
that
right?
There
needs
to
be
some
finite
set
of
instructions
for
forgiving
that
so
we're
proposing
guides
as
well
as
graduation
criteria.
Graduation
criteria
is
pretty
huge,
so
the
idea
that,
if
anyone
is
familiar
with
the
release
process,
essentially
there
is
a
features,
collation
our
hands,
pins
collation
at
the
beginning,
where
we
essentially
reach
out
to
all
of
the
SIG's
and
say
hey:
what
are
you
working
on?
We
go
through
a
we
go
through
a
list
of
issues
with
it.
B
Mccain
Hansen's
repo
and
then
turn
those
into
a
spreadsheet
and
ping
people
in
the
span
of
a
quarter
essentially
to
keep
that
up
to
date.
So
it's
important
as
we
move
through
these
steps
to
understand.
What's
the
criteria
for
moving
a
feature
or
an
enhancement
from
alpha
to
beta
right?
Is
it
experience,
reports
and
experience
reports
is
on
the
phone
right,
you
know.
Is
it?
Is
it
a
level
of
testing?
What's
you
know
what
are
the
intent
tests?
What
is
the
documentation
for
for
these
proposals
right?
B
So
the
and
and
then
all
the
experience
reports
side,
it's
a
it's!
It's
having
the
ability
to
bring
bring
the
experience
of
an
operator
of
a
teacher
of
a
developer
back
into
the
process
right,
so
the
only
way
we're
going
to
learn
and
accelerate
the
way
that
we
develop
kubernetes
is
being
able
to
actually
monitor
essentially
monetize
on
the
all
of
the
experiences
that
we
have
across
these
53,000
contributors
or
people
who
are
in
the
stock
Channel.
At
this
point,
yes,.
A
Oh
one
more
quick
thing
about
this
is
that
we
want
people
working
on
things
in
kubernetes
to
get
used
to
in
the
habit
of
creating
documents
and
all
these
necessary
artifacts
earlier
and
earlier
in
the
process,
because
one
of
the
things
that's
really
frustrating
is
that,
if
a,
if
a
signal,
this
great
work
on
a
feature
and
they're
getting
ready
to
ship
it
in
the
next
release
and
oh
the
documentation
is
in
ten
or
there's
some
bit
of
provenance.
That
needs
to
be
provided
in
terms
of
the
actual
feature
work
that
was
done.
A
A
So
this
is
a
way
that
we
can
empower
them
to
empower
us
and
yet
another
way
that
we
can
do
as
Caleb
says.
You
know
development
at
the
speed
of
trust
that
there's
all
sorts
of
areas
in
which
Trust
is
conveyed
through
these
activities
and
and
that's
really
really
important
to
the
ethos
of
the
community
as
a
whole.
B
So
let's
talk
a
little
bit
about
the
cap
states
right.
We
have
this.
We
have
this
notion
and
this
kind
of
motto
of
merge,
early
and
iterate,
often
right
and
we're
kind
of
trying
to
bring
that
bring
that
kind
of
more
to
the
forefront
more
and
more
as
people
start
to
touch
caps.
So
there
is
a
draft
status
for
caps,
which
essentially
means
hey.
This
is
this,
is
my
idea
I
think
it
might
be
great?
Maybe
we
should
do
it?
Maybe
we
should
I
just
want
to
get
in
front
of
people
right,
yeah
and.
A
I
think
that
this
is
this
is
a
really
important
point
for
people
in
the
past.
There's
been
a
reluctance
to
merge
a
cap
because
it
feels
like
oh,
my
gosh.
Now,
we've
we've
committed
this
thing
and
that's
really
a
misunderstanding.
Fundamentally
what
the
metadata
is
supposed
to
convey
so
when
it
when
it
kept
us
in
a
draft
state
I
it
it's
completely
uncommitted.
A
It's
really
the
author
saying
I
have
an
idea:
let's,
let's
start,
let's
collect
data
and
get
people
involved
and
start
the
process
of
getting
an
idea
what
this
might
look
like,
but
it's
not
committed.
If
my
cat
wants
to
deliver
a
cap
on
how
to
get
fed
more
every
day,
I'm
gonna
say
go
ahead
cat.
You
know
like
like.
Let's.
A
B
So
I
think
that
it's
a
you
know
also
a
common
misconception
that
you
know
it's
it's
only
members
of
SIG's
that
are
submitting
caps
right.
This
is
think
of
eye-opener
repo
I
want
some
new
change.
How
do
I
do
that
right?
It's
it's
fine,
to
submit
the
motivation
and
and
say
hey
what
do
you
guys
think
of
this
right
so
moving
forward
in
the
process?
We
have
the
idea
of
a
provisional
state
which
we
have.
We
have
taken
a
look
at
the
draft.
We
were
starting
to
firm
up
details.
B
A
A
B
All
right
so
once
we
once
we
get
so
there
are
different
cap
States.
You
know,
there's
a
there's
a
tree
that
we
should
probably
create
at
some
point
a
little
work
flow
diagram,
but
there
are
certain
states
that
caps
can
move
into
that
signify.
Maybe
it's
not
gonna
be
worked
on,
or
maybe
we
can't
work
on
it
so
deferred
is
one
of
them
right.
The
cap
is
the
cap
is
in
place,
but
not
actively
being
worked
on
and
deferred
is
I.
B
Think
it's
kind
of
left
as
an
exercise
to
the
sig
to
decide
what
you
know.
The
level
of
deferment
is
right,
there's
rejected.
This
is
not.
This
is
a
bad
idea,
but
you
know
maybe
the
implementation
is
and
what
it
could
be,
or
maybe
it's
it's
something
that
goes
contrary
to
something
that
another
say
it's
working
on
right
withdrawn!
B
That's
the
author.
Decides
hey
I'm,
really
not
that
interested
in
this
anymore
so
and
then
finally
replaced
so
often
often
we'll
see
we'll
see,
advancements
in
in
objects
and
different
resources
and
different
data
structures
in
kubernetes.
So
an
example
would
be
TP
RS
to
see
our
DS
right.
So
at
that
point,
if
someone
wrote
it
CRD
cap
right,
that's
er,
D
cap
would
potentially
is
superseded.
The
the
TP
R
cap
right.
A
So
we're
gonna
talk
a
bit
about
the
tool
that
is
being
developed
around
this
lifecycle
and
the
tool
has
commands
they
can
be
used
to
programmatically
manage
these
artifacts
and
the
metadata.
The
tool
has
an
init
state,
which
I
think
is
super
cool,
because
it
generates
all
the
things
that
you
need
to
start
out
to
do
that.
Motivation
in
summary
and
have
the
metadata
updated
with
the
draft
state,
the
author
and
all
that
information
and.
B
You
know,
since
since
then,
we've
had
the
opportunity
to
look
at
the
way
people
submit
caps
and
understand
what
their
workflow
is
and
try
to
adapt
the
tool
to
something
that
is
consumable
for
everyone
right.
So
this
the
states
that
are
proposed
within
the
kept
lifecycle
are
essentially
the
the
work
product
of
that.
B
So
after
you
initialize
your
your
your
brand-new
kept,
your
new
shiny
kept
the
the
next.
The
next
goal
is
to
to
actually
propose
it
right.
You've
you've
gone
through
each
of
the
templates
that
have
been
generated
in
the
init
process.
You
understand
what
the
motivation
and
the
summaries
are
and
you've
sort
of
identified
potential
stakeholders
within
the
sig
and
can
basically
place
them
in
the
document
as
reviewers
or
a
bruiser.
Our
improvers
yep.
A
And
so
you've
got
this
proposed
now
I'm,
putting
my
my
signature,
hat
on
and
I'm
gonna
I'm
gonna.
Look
at
this
thing,
and
so
for
me
the
next
thing
is
to
say
as
a
an
official
representative
this
sake,
maybe
it
would.
The
Signet
about
I
had
talked
about
it
and
and
there's
enough
agreement
in
the
sig
that
this
is.
This
is
something
that
should
be
looked
further,
and
this
is
think
of
this
as
an
early
opportunity
to
either
to
possibly
avoid
waste
in
a
sense
that
the
as
a
sig
leader.
A
This
is
a
point
in
the
life
cycle
on
the
Keppler
I
can
say
we
need
to
move
forward
or
we
need
to
pause.
And
so,
if
we
pause,
you
know
we
can
either
change
the
cap
state,
as
you
know,
some
of
the
other
deferred
or
whatnot,
or
we
can
leave
the
P
R
open
for
a
while
and
maybe
have
more
discussion
or
whatever
we
need
to
do
there,
but
essentially
at
the
terminus
of
that
decision.
If
this
is
something
the
sig
montz
to
move
forward,
then
we
accept
it.
A
B
Right
so,
once
once
a
cap
has
essentially
been
approved,
they
some
of
the
next
steps,
are
to
actually
plan.
You
know
plan
the
structure
of
of
the
the
enhancement
right,
so
they,
the
cap
author,
is
going
to
go
through
the
documentation,
actually
work
up
some
documentation,
so
whether
it's
in
the
form
of
these
operator
guides
or
developer
guides
firming
out
what
graduation
criteria
might
look
like
again.
B
This
is
it's
very
much.
It's
very
much
merge
early
right.
So,
as
you
have
ideas,
you
want
to
iterate
on
those
ideas
as
quickly
as
possible.
You
want
to
serve
those
ideas
back
to
community,
so
you
get
more
feedback
on
them
right.
It's
not
yeah
we're
actually
having
a
conversation
to
beginning
of
the
some
beginning
of
summit
about
you
know,
should
I
bother
with
the
cap.
If
I,
you
know,
if
I
work
them
like
shouldn't
I,
do
a
POC
before
I
before
I
propose
a
cup
like.
Why
not
propose
it.
A
B
A
So
one
of
the
key
stakeholders
in
this
process
is
the
release
process,
because
enhancements
are
how
we
talk
about
what
gets
included
in
a
release
is
in
addition
to
bug
fixes
and
what
not.
So
the
part
of
the
idea
is
that
we
want
to
have
the
the
enhancements
repositories
serve
as
a
way
of
keeping
track
of
what
was
delivered
not
or
slipped
in
any
given
release,
and
this
is
a
key
way
that
we
can
do
that
in
the
future.
Right.
B
So
this
goes
back
to
the
spreadsheet.
That
I
was
talking
about
a
little
earlier,
where
it's
it's
a
lot
of
human
work,
essentially
to
collate
all
of
these
things
and
constantly
like
review
and
and
and
update
the
sheets.
So
the
opportunity
to
programmatically
solve
this
and
and
have
that
sort
of
version
control
and
be
able
to
introspect
on
it
across
release
cycles
is
huge
to
the
project
right.
We
learned
from
our
own
our
own
mistakes,
or
you
know
our
own
successes
right.
Yes,.
A
And
future
archaeologists
when
they
want
to
learn
about
this
thing
called
kubernetes
that
happened.
You
know
in
the
mid
teens
of
this
century
is
they're
gonna,
go
back
to
github
and
and
look
at
this
and
see
what
happened
and
they'll
actually
be
able
to
see
what
happened.
So
this
ties
into
something
that
is
a
really
big
deal
for
cig
p.m.
specifically,
which
is
the
idea
that
we
could
forecast
what
is
going
to
be
delivered,
release
over
release
and
have
some
sort
of
aggregate
view
of
what
that
looks
like.
B
Yeah
we're
actually
starting
to
get
questions
about
that
yeah,
so
we're
so
where's
the
road
map
for
kubernetes.
It's
like
yeah
I,
couldn't
tell
you.
Okay,
I
can
read
a
few
enhancements
tracking
sheets,
but
I
couldn't
tell
you.
So
that's
that's
really
to
solve
this
problem,
one
to
introspect
across
the
roadmap
and,
and
you
know,
and
to
to
be
able
to
just
provide
visibility
for
not
just
people
who
are
in
the
project,
but
anyone
right.
This
is
again.
B
A
B
A
D
I'm
one
of
the
founding
members
of
cig
release
and
SiC
p.m.
the
formal
documentation
for
the
release
team,
but
mostly
I'm
a
duty
sits
in
a
chair.
So
if
you
you're
needing
help,
you
can
may
find
me
in
that
chair.
So
I
guess
I'm
here
for
y'all
what
kind
of
questions
woody?
What
do
you
wanna
know
about
our
use,
planning
and
kubernetes
open
source
governance
structure,
yeah.
D
D
So
a
lot
of
that
you
know
we
do
a
lot
of
discussions
in
mailing
lists.
You
know,
fear
you
know
active
participant
there
and
you
know
it's.
It
is
been
more
or
less
the
honor
system
of
so
the
kept
process
is
designed
to
document
consensus
so
that,
as
you
have
a
resolution
in
a
discussion,
whether
weather
occurs
on
a
mailing
list
or
and
slack
on
the
poor
quest
itself,
you
should
update
the
cap
to
reflect
that.
D
Thus
far,
we've
been
booked
said
as
the
implementers
of
the
process
pretty
hands-off
and
depending
on
the
SIG's
to
do
that,
because
this
really
is
a
mechanism
for
a
couple
of
SIG's
scale
themselves
and
the
scale
trust.
So
if
the
SIG's
aren't
making
sure
that's
happening,
then
there's
a
challenge,
but
it
hasn't
been
a
huge
problem.
I,
don't
think
thus
far
well,
but
that's
kind
of
the
the
hands-off
kind
of
tragedy
they're,
giving
people
the
tools
they
need,
and
then
you
know
trusting
them
to
use
them
correctly.
Yeah.
B
I
think,
for
all
intents
and
purposes,
SIG's
have
been
fairly
self-sufficient
in
terms
of
gathering
that
data
and
pushing
it
pushing
it
back
into
whether
it's
an
enhancement
tracking,
you
know
Hanson,
tracking
or
a
design
proposal,
or
what
becomes
a
cap
or
and
applying
the
the
pull
requests
or
the
issue
numbers
or
if
you
we
had
a
conversation
over
here,
people
are
fairly
fairly
good
about
it.
I.
E
D
You
know,
managing
a
large
project
is
difficult.
There
I
mean
like
if
you
wanted
to
say,
use
a
tool
like
JIRA
I
mean
it
becomes
a
question
of
who
pays
for
the
JIRA
where
who
operates
the
Gerry
instance,
and
you
know
challenges
that
you
could
resolve.
But
you
know
if
you've
been
involved
in
community
community
even
like
getting
moving
over
some
of
our
CI
infrastructure
is
an
ongoing
challenge
right.
It's
a
process,
that's
been
going
on
for
years.
It
will
continue
for
months
and
months
and
months
from
now.
D
D
The
workload
across
you
know
all
the
different
SIG's
ever
the
whole
community
community,
so
the
lightweight
nature
of
it
more
or
less,
and
the
strong
coupling
between
source
control
and
the
flat
files
or
how
the
primary
things
also
that
you
could
use
the
RFC
process
to
do
all
the
downstream
things
like
build
a
road
map
for
the
rush
project
and
talk
about
and
generate
really
high
quality
release
notes
for
every
version
of
Russ,
because
you
had
that
source
content.
You
know
six
months
in
advance
because
you
just
you,
you
decided
a
higher
technical
bar.
D
It
was
important.
It's
not
just
code
without
documentation,
there's
no
dent
in
the
general
case,
no
real
idea
about
how
to
use,
and
so
it
really
it
takes
a
you
know:
real
cross-functional
team
to
develop
and
deliver
actual
enhancements
to
people.
So
that
was
the
kind
of
the
takeaways
that
I
you
know
brought
from
the
rest,
our
process.
D
D
So
we're
hoping
to
use
the
cap
process
to
really
allow
a
enhancement
author,
whether
they
developed
outside
of
tree
or
thinking
about
developing
something
outside
of
tree,
to
be
able
to
motivate
the
importance
and
including
their
enhancement
as
part
of
the
kubernetes
project,
and
you
know
it
kind
of
like
a
loose
blessing
from
a
cig.
So
that's
the
idea
of
sponsoring
cap
is
that
a
cig
is
really
going
to
get
invested
in
this
and
seeing
this
idea
through
to
implementation.
So
if
you
believe
it's
important,
I
mean
that's,
why
you
just
have
a
proposal.
D
You
follow
the
motivation
really
trying
to
motivate
the
problem
and
the
thing
that
I
keep
telling
people
back
to.
You
is
Russ
Cox's
blog
back
towards
go
to.
It
really
really
talked
about
the
need
for
motivating
change,
to
help
open
source
project.
Maintainers,
understand
kind
of
the
importance
of
a
proposal.
Given
you
know,
most
people
are
incredibly
overloaded
in
their
day-to-day
jobs.
The
helps.
A
To
Stubb's
forward
here
and
also
give
Stephen
my
contact
information,
if
you
want
to
stalk
us,
let
us
know
we're
gonna,
be
doing
more
Roadshow
activities
with
the
EPS
library
as
well
as
CLI,
and
those
in
the
room
motivated
to
be
Co
developers
and
do
things
not
necessarily
even
go
developers.
You
can
work
against
library
in
the
language
of
your
choice,
but
essentially
we
have
a
reference
sensation
for
the
CLA,
but
we
would
love
other
people
to
get
involved
and
you
can
contact.
Caleb
has
github
Caleb
emails
and
yeah.