►
From YouTube: Meet the Contributors - Ask Us Anything
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hey
hi
everyone
and
welcome
to
our
second
session
of
the
day
for
humanities,
meet
our
contributors.
My
name
is
Paris
I
work
here
at
Google
on
kubernetes
community
strategy.
We
have
an
awesome
panel
for
you
today.
I'm
super
excited
about
it
and
we've
got
Jeff,
who
is
behind
his
avatar
there,
who
is
spinning
our
youtube
ones
and
twos?
A
If
you
will,
if
you're
Adi,
if
any
aspiring
DJ's
are
out
there,
he
is
making
sure
that
we
are
coming
through
crystal
clear
if
we're
not
yell
at
Jeff
in
the
chat
you'll
know
about
that
in
a
second,
but
first
things
first.
Why
are
you
here
for
people
on
Twitter
who
are
like
what?
What
is
this
link?
What
did
I
just
come
and
stumble
upon?
This?
Is
our
efforts
to
help
upstream
contributors
both
on
board
and
get
questions
answered,
and
maybe
things
unblocked
and
questions
that
they
would
usually
ask
a
mentor.
A
Not
everybody
has
time,
unfortunately,
to
do
traditional,
one-on-one
mentoring.
So
this
is
our
efforts
to
help
we'll
be
the
sum
of
those
pain
points
and
keep
people
moving
and
keeping
them
from
being
blocked.
Of
course,
we
do
have
a
code
of
conduct.
This
applies
to
both
our
panelists,
as
well
as
our
people
in
the
people
in
chat
and
stuff
that
are
asking
questions
if
you
could
just
be
excellent
to
each
other.
That
would
be
awesome
panelists.
You
are
also
more
than
welcome
to
ask
each
other
questions.
A
You
probably
don't
know
each
other
I
mean
Michelle
and
Vlad
most
likely
to,
of
course,
but
Matt
you
may
not.
You
may
not
know
these
folks
so
feel
free
to
ask
any
questions
that
you
like
as
well,
but
we're
gonna
kick
things
off
with
some
introductions,
Michelle.
Why
don't
you
go
first,
give
us
a
quick
rundown
if
you
are
and
how
you'd
come
to
us,
yeah.
A
B
B
A
B
D
Guys
matt
record
I'm
r2d
for
on
github
I
work
at
Google
and
I've
been
working
on
kubernetes
since
I
joined
Google
in
2016,
so
I
started
out
I'm
like
I,
guess
the
founding
team
of
mini
cube.
That
was
kind
of
the
first
thing.
I
worked
on
and
then
I
moved
more
into
more
kubernetes
developer
experience
things
across
kind
of
the
whole
ecosystem
and
now
I'm
working
a
little
a
little
out
of
tree
on
things
like
Kay,
native
and
good
flow.
A
Cool
and
the
same
thing
with
you,
I'm
sure
we'll
hear
about
that
a
little
bit
more
in
a
second.
So
first
question
is
a
general
question
one.
What
brings
you
to
kubernetes
specifically
and
two
is
kubernetes
and
its
ecosystem
projects,
the
first
open
source
project
that
you've
contributed
to
upstream
and
Michelle?
Why
don't
you
go
first?
What
did
Singler
take
a
shot,
yeah.
A
C
That's
how
I
got
kind
of
Lenin
into
into
doing
or
writing
code
for
a
volume
volume
provider
of
volume
plugin
for
one
of
the
products
there
and
that's
that's
how
I
got
started
and
that's
what
I've
been.
You
know
that
there's
been
my
area
sense
as
far
as
first
PR
I
think
it
was
a
I
think
it
was
a
massive
PR.
It
I'm.
C
It's
been
so
long
and
coming
at
kubernetes
time,
yeah
I
just
remember
a
massive
PR
trying
to
get
in
and
it
was
like.
Not
it's.
You
know
the
code
review
alone
to
put
too
long
and
we
never
got
it
in.
So
we
went
back
to
the
drawing
board
and
kind
of
learned
from
our
mistakes
and
it
from
my
mistake
as
well
cos.
C
It
was
my
first
heads
on
first
a
go
work
on
this
thing
is
gigantic
code
and
try
to
get
it
in
then
it
was
a
learning
experience
but,
as
Michelle
said,
the
community,
you
know
it
always
amazes
me
to
see
the
machinery
of
the
community
working
to
get
this
massive
amount
of
coding
out
every
quarter.
So
I'm
still
amazed
to
see
it
working
today,
yeah.
C
A
D
So
I
didn't
have
any
kubernetes
PRS
I
I
had
opened
up
a
few
issues
and
docker
and
I
had
tried
to
send
a
few
PRS
there,
which
Farrow
failed,
pretty
miserably
so
I
would
say.
Kubernetes
was
was
probably
my
best
open
source
experience
getting
started,
but
yeah
I
started
when
I
started
at
Google
I,
basically
like
the
mini
project,
just
started
kind
of
in
tandem,
so
I
just
started
working
on
that
and
my
first
PR
mini
cube
was
I.
D
Don't
even
know,
I
mean
probably
like
a
during
the
adding
the
legs
under
folder
or
something
like
that
or
the
makefile.
And
then
my
first
upstream
contribution
was
I
fixed
some
some
issue
with
TP
ours,
where
many
key
would
just
panic,
which
was
a
bit
problematic
because
it
had
to
do
with
like
when
I
don't
know,
the
I
think
something
got
registered
and
then,
when
many
keeps
shut
down
and
turned
back
on
it,
just
panicked,
but
yeah
it
was.
It
was
a
one-line
fix.
A
C
C
Make
it
habit
to
review
existing
pr's
be
present
in
the
community?
It's
all
about
relationship
at
the
end
of
the
day,
so
the
more
people
see
your
reviews,
the
more
you
participate,
the
more
likely
folks
who
are
leading
different,
different
SIG's
will
recognize
you
and
ask
you
to
take
on
responsibility,
and
you
know
once
you
start,
volunteering
eventually
you'll
have
some
commits
and
you
most
likely
end
up
owning
a
section
of
the
code
or
your
name.
Will
the
animal
will
appear
in
on
a
section
of
the
code
that
you
that
you've
committed?
B
To
add
to
that
I
think
also,
a
nice
way
to
get
familiar
with
a
new
component
is
to
just
take
a
look
at
those
files
and
see.
If
there's
you
know,
missing
unit
test
coverage
and
start
adding
unit
tests
for
them.
That
can
really
help
with
like
actually
understanding
the
nitty
nitty-gritty
of
what
the
code
is
actually
trying
to
do,
and
you
who
knows
you
might
even
uncover
bugs
as
you're
writing
tests.
C
C
You
know
my
introduction
to
the
codebase
had
to
do
more
with
understanding
what
was
going
on
as
far
as
go
being
curious
about
kubernetes
kubernetes
itself,
but
I,
don't
think,
there's
there's
any
hard
prerequisite
to
to
be
a
storage
buff
or
someone
who's
super
knowledgeable
about
storage.
It
definitely
helps
but
I,
don't
think
it's
a
disqualifying
attribute
if
you're
not
there.
As
far
as
as
far
as
storage
knowledge.
B
And
to
add
to
that
I
think
with
respect
to
storage,
it
also
depends
on
which
part
of
the
storage
codebase
you're,
looking
at
so
I,
would
I
would
basically
split
up
the
storage
codebase
into
two
parts.
There's
the
general
storage
controllers,
which
sort
of
manage
the
lifecycle
of
the
storage
backends
and
then
there's
the
actual
storage
back-end
drivers
themselves,
so
I
think
for
the
actual
storage
backends,
those
you
might
need
to
be
a
little
more
familiar
and
have
experience
or
access
to
those
storage
systems.
B
A
Matt,
what
about
you
with
me
cube
when
you
were
growing
reviewers?
What
were
some
things
that
you
were
looking
for
and
folks
as
they
were,
making
more
and
more
contributions.
I
would.
D
Say
like
one
piece
of
advice
for
reviews:
is
that,
like
reviews
always
don't
have
to
be
reviews
per
se,
like
don't
be
afraid
to
ask
a
question
like?
Why
is
this
being
done
like?
Why
is
this
code
this
way,
like
you,
don't
necessarily
mean
like
to
know
the
right
way,
and,
and
sometimes
you
know,
the
I
mean
I
feel
like
the
the
author-
will
always
respond
with
they're
kind
of
thinking
behind
it
and
that
can
help
you
grow
as
a
reviewer
as
a
coder
as
as
whatever
but
I
mean.
D
Who
knows,
you
might
even
uncover
some
assumption
that
was
being
made
that
didn't
really
make
a
lot
of
sense
or
that
the
author
hadn't
thought
through
so
I
would
say,
like
don't
be
afraid
to
ask
like
a
question
like
I
mean
stupid
questions,
whatever
there's
there's
none
of
them
right,
really
just
just
kind
of
getting
familiar
with
the
code.
You
know
reviewing
cups
I
mean
there's,
no,
you
know
no
one
says
hey.
You
can't
review
this
right,
you
know.
So
it's
just
like
kind
of
get
reviews
out
there
ask
questions.
Oh.
D
A
D
I'd
say
in
my
experience
like
if
you
can
own
like
like
a
clearly
delineated
piece
of
the
project,
that's
a
great
candidate
for
an
approver
right,
I
mean
just
kind
of
structurally
organizationally,
so
kind
of
carving
out
like
a
little
section
of
the
project,
whether
that
be
through
a
cap,
or
you
know,
through
this
area
that
you're
really
well
known
as
you're
you're,
responding
to
all
the
issues,
you're
you're,
reviewing
all
the
code,
I
think
like
I
mean
that's
pretty
much.
What
I
look
for
and
approvers
are
going
from
the
reviewer
to
an
approver.
A
Soffel
I'd
mentioned
earlier
that
there
were
some
challenges
with
his
first
PR.
So
knowing
what
you
know
now,
would
you
go
back
and
do
anything
differently
and
would
end,
or
would
you
tell
new
contributors
to
like?
Would
you
tell
new
contributors,
a
tip
or
some
kind
of
piece
of
information
that
might
help
them,
along
with
their
verse,
VR.
A
C
You
know
because
kuba
net
is
such
a
massive
codebase
just
about
everybody
who's
doing
anything
in
kubernetes,
especially
when
you
know
toward
the
end
of
the
release
cycle.
You
know
people
get
super
busy,
so
you
you
have
you.
You
have
to
get
their
attention
quickly.
You
know
early
and
I.
Think
part
of
the
failures
of
some
of
the
larger
features
and
I've
worked
on,
had
to
do
with
not
being
vocal
enough
or
and
not
being
proactive,
asking
questions
not
being
afraid
to
ask
questions.
C
Be
willing
to
be
wrong
so
that
to
me
you
know
if
I
had
to
do
things
differently,
I
think
that
would
have
helped
me,
and
you
know
the
the
working
on
kubernetes
there's
while
their
documentation
is
out
there
there's
a
lot
of
documentation
out
there,
but
there
is
no
tutorial
on.
You
know,
step
zero
step,
one
step
two:
how
to
contribute
to
kubernetes.
C
So
a
lot
of
the
a
lot
of
the
things
that
you
have
to
do
to
be
successful
and
contributing
has
to
do
with
a
lot
of
discovery
exercises
and
that
you
have
to
get
it
yourself
and
it's
super
intimidating
and
can
be
intimidating.
But
I
found
out
over
the
years
that
I've
been
doing.
This
people
are
always
willing
to
help
freshen
slack,
but
you
have
to
be
willing
to
ask
question:
you
have
to
be
willing
to
sound.
C
Like
you,
don't
know
what
you're
talking
about
and
people
will
you
know,
even
if
you
do
know
what
you're
talking
about,
but
you
know
you
can't
come
in
as
well.
I
know
everything
which
is
completely
impossible
comes
to
the
Nettie's.
Even
if
you
were
some
of
the
earlier
code
contributors
who
Vanetta
has
grown
to
such
a
size
that
it's
hard
to
know
everything
about
everything
in
kubernetes.
So
you
always
ask
a
question
and
you
always
willing
to
learn
and
listen
to
others
and
be
willing
to
be
wrong
and
be
corrected.
B
B
Sometimes
some
things
I
see
is
some
new
contributors
sort
of
like
they
want
to
jump
in
on
some
sort
of
big
features
and
stuff
and,
and
they
start
coding
coding
up
everything
and
then,
when
it
comes
time
to
review,
like
you
know,
some
of
the
reviewers
end
up.
You
know
having
a
lot
of
like
design,
discussions
and
stuff
like
that
and
I
think
like
before.
You
know,
spending
a
lot
of
time
and
energy
going
to
implement
something
I.
Think
of
it.
B
The
I
think
communication
is
key
to
communicate
with,
like
the
leads
of
the
cigs
in
the
areas
where
you're
planning
to
do
this
work
just
to
like
communicate
your
plan
and
communicate
your
design
and
get
approval
on
the
over
all
ideas.
First,
before
you
start
spending
a
lot
of
time
coding
and
then
finding
out
that
maybe
the
design
is
not
the
direction
that
people
wanted
to
take
things
in
I'm.
D
I
would
I
would
have
to
reiterate
that
so
much
it.
It
pains
me
to
see
people
spend
so
much
time
on
features
that
are
I
mean
they
might
work,
they
might
be,
you
know
actually
well
coded,
but
if
they
don't
fit
in
with
the
design
principles,
the
roadmap,
you
know
the
feature
set
in
scope
or
whatever
of
the
project.
Then
it's
it's
gonna.
It's
gonna
be
a
tough
time
to
review
it
after
it's
already
been
done,
and
so
that's
one
thing
I
just
I
see
it
over
and
over
again
people
send
huge
PRS.
D
You
know
seemingly
pretty
good
features,
but
it
hasn't
been
discussed
yet
has
it
been
reviewed,
the
design
hasn't
been
reviewed
and
I
mean
I
I've,
seen
a
lot
of
PRS
kind
of
sit
and
be
closed
because
of
that
so
I
would
just
say,
communicate.
Get
people
involved.
You
know,
obviously
right
as
I
read
a
cap.
A
Did
get
a
DM
from
someone
who
is
who's
very
new
and
wants
to
understand
what
owner's
files
are
and
the
reviewers
and
approvers
just
a
little
nugget
to
data
the
last
time
that
we
did
a
contributor
experience
survey,
which
was
last
big,
like
October,
25
percent
of
the
people
said
that
they
were
new
to
open
source,
and
this
was
based
on
our
current
contributor
population
that
took
the
survey.
It
was
like
170
people
so
with
that
said,
with
some
advice
here
for
like
folks
that
are,
you
know
also
new
to
open
source.
A
B
I
mean
so
the
the
basic
premise
of
owners
files
is
to
be
able
to
kind
of
guide
guide
people
to
like
who
are
the
experts
in
that
particular
component
and
I
understand
that
component
very
well.
So
when,
as
a
new
contributor,
if
you
are
making
a
change
in
that
area,
the
owners
file
can
help
can
help
you
figure
out,
who
might
be
the
best
people
to
communicate
your
ideas
with,
and
you
know,
discuss
your
ideas
with
I
think
that's.
A
D
I
would
say
my
advice
is
like
make
the
actual
code
or
documentation
or
whatever
change,
very
small
cuz,
there's
so
many
other
things
that
go
into
that
first
contribution
right,
I
mean
there's
signing
the
CLA
understanding.
What
the
CLA
is.
You
know
maybe
creating
a
github
account
figuring
out
what
issues
are
what
PRS
are?
D
If
you're
used
to
kind
of
an
internal
version
control
system
even
getting
used
to
guess
you
know
what
it
means
to
send
a
PR,
you
know,
I
mean
get,
is
really
confusing,
I
have
to
say,
as
someone
who's
used
it
for
a
very
long
time
and
and
understands
a
lot
about
it.
There's
it's
it's
a
lot
of
magic
as
well,
but
yeah,
there's
just
so
many
other
things.
I
go
into
like
actually
getting
that
code.
Merge
that,
like
keep
the
actual
part
of
it
kind
of
small.
C
What's
gonna
add
to
that
you
know
if
it's
starting
out
as
a
new
contributor
to
kubernetes
there.
A
lot
of
you
know
different
steps
matter
of
fact.
I
was
talking
to
somebody
on
slack
earlier
about
that,
and
you
know
it's
it's
a
large
code
base.
You
would
definitely
have
to
select
which
section
you're
interested
in,
but
then
they're
these
technical
preparations
that
you
have
to
undertake.
C
C
Obviously,
some
knowledge
of
go
would
help,
and
one
of
the
thing
I
didn't
do
when
I
start
I
was
starting
out
is
spend
a
lot
of
time
with
the
the
get
started.
I
think
it's
the
development
that
nd
there's
a
development
file
somewhere
under
the
community.
Repo
I
can't
remember
the
path,
but
basically
it
outlines
a
lot
of
the
steps
that
you
need
to
get
started
on
a
technical
front.
C
C
Development
environment
set
up
and
you're
rolling
it'll,
probably
take
you
more
than
a
couple
hours
a
few
hours
and
getting
it
wrong
at
first,
go
back
to
the
documentation
and
figure
out.
What's
going
on
and
and
and
and
get
things
working,
so
I
think
patience
is
the
key
operative
word
here,
but
it's
definitely
possible
and.
B
D
D
Obviously
good
first
issue
is
always
a
great
label
to
look
at
across
kind
of
all
of
these
repositories,
there's
kind
of
a
special
github
one,
because
it
actually
shows
up
in
your
feed
if
you're,
following
a
project
or
following
someone,
when
you
tag
it
and
I,
know
a
lot
of
repositories,
use
that
mini,
cube,
I,
think
we
published
a
road
map
not
too
long
ago
of
sorry.
I
might
be
getting
kicked
out,
but
I
said
I
had
this
room
for
an
hour.
Yes,.
A
In
true
in
true
Google
spirit
right
here,
this
is
a
I
just
got
kicked
out
of
my
room
y'all,
so
bear
with
Matt,
as
he
figures
out
a
new
room
situation.
Alright,
so
I
got
a
question
in
DMS
and
it's
what's
one
area
of
the
project
that
you
actually
wish
that
you
had
time
to
help
out
more
on,
but
unfortunately
you
just
don't
have
the
cycles
to
do
it.
A
C
As
Michelle
said
earlier,
there
are
different
segments
of
storage,
there's
the
internal
controllers
and
then
there's
the
plugins,
so
the
internal
stuff,
which
they
don't
get
touched
too
often
because
they
they
impact
so
much.
So
it's
it's
stable
code
that
you
know,
but
I
wish
I
had
time
to
learn
more
and
participate
more
and
and
in
that
section
which
probably
I'm
gonna
try
to.
But
definitely
it's
an
area
of
interest
in
the
internal
controllers.
C
B
B
Think
kubernetes
has
been
pretty
good
in
that
regard,
and
within
that
we
have
our
cig
testing
group,
which
is
super
phenomenal,
but
they're
definitely
like
there's
so
much
work
that
could
be
done
and
they
definitely
need
a
lot
of
they
there's
a
lot
of
things
that
they
could
use
help
with.
I
think
the
theme
theme
of
this
call
is
also
create
more
tests
and
it's
not
just
creating
more
tests,
but
also
like
making
tests
easier
to
run
for,
like
the
rest
of
the
kubernetes
ecosystem.
I
think
very.
B
The
current
test
infrastructure
has
has
been
customized
very
specifically
to
kubernetes
and
now
as
we're
as
the
kubernetes
core
is
starting
to
push
out
a
lot
of
the
not
so
core
modules
out
of
the
main
kubernetes
tree.
We
have
this
next
set
of
problems
where,
like
now
all
of
these
out
of
trees,
sub
projects
have
to
figure
out
their
own
testing
infrastructure
again.
B
A
A
And
kind
is
definitely
picking
up
contributors
there
as
well.
So
that's
really
cool
all
right.
So,
let's
move
on
to
a
question
that
was
asked
several
weeks
ago.
Actually,
because
sometimes
we
get
code
based
or
requests,
and
we
have
one
today,
Vlad's
gonna
do
CSI
code
based
tour,
which
is
super
awesome
Vlad.
You
want
to
take
it
away.
A
Share
your
screen,
yes
yeah,
and
while
you
do
that,
if
folks
are
out
there
and
want
a
code
based
tour
of
anything
special
or
if
you
want
dependencies
explained
or
if
you're
ruffling
through
the
code
and
say
this
whole
entire
section
is
mishmash,
I
have
no
idea
what
I'm
looking
at
this
is
the
place
for
you.
We've
done
kubernetes
kubernetes
here
as
well.
We're
gonna
do
Cube
builder
next
month
also
have
the
schedule
or
next
month,
so
we're
gonna
pick
apart.
Some
of
this
together
all.
C
There
is
the
internal
cubelet
work
controllers
and
what
I
call
a
a
CSI
adapter
internally,
and
then
we
have
the
external
component
so
we'll
look
at
both
real
quick,
so
I
am
at
the
2d
nineties,
kubernetes
and
I've
already
clicked
on
PKG
and
if
you
scroll
all
the
way
down,
you'll
see
volume
and
by
the
way
there
other
portion
of
this
that
we're
not
gonna
look
at,
which
is
the
kind
of
the
internals
that
drive
all
this.
But
we
don't
need
to
go
that
far
out
or
that
far
down
the
abstraction
chain.
C
So
inside
here
you
can
see
all
the
internal
drivers,
and
this
is
the
way
we
used
to
do
storage,
maybe
about
a
year
or
so
ago,
and
basically
the
way
we
did.
Storage
is
a
revenger
storage
vendor
with
come
in
and
try
to
get
their
own
gold
packages
inside
that
particular
directory
and
work
at
it
and
and
write
code
against
the
internal
volume
API.
Well
that
works
great,
but
there
are
two
things
that
was
against
it.
C
One
is
that
you
were
working
against
kubernetes
kubernetes,
so
you
had
to
have
the
strategy
code
reviews
and
you
were
pegged
to
the
release
cycle
of
kubernetes
and
the
other
thing
that
was
a
strike
against.
This
is
the
fact
that
it
was
growing
the
codebase,
and
you
know
if
something
if
there
was
a
bill
failure
or
here
it
could
take
down
the
entire
building
structure
for
the
code.
C
Now,
inside
si
si,
this
is
all
of
the
and
it
has
grown
since,
since
we
started
maybe
about
a
year
and
a
half
ago,
and
we
see
the
all
of
the
different
go
files
that
makes
si
si
works
and
each
one
of
these
files
and
their
accompanying
test,
but
basically
implements
a
portion
of
the
internal
volume
API.
For
instance,
we
have
si
si
plug-in
which
implements
the
plug-in
a
portion
of
the
API.
C
We
have
mounter,
which
implements
the
mounting
portion
of
the
API
we
have
an
attached
or
which
basically
does,
as
the
name
suggests
it
implements
the
attacher
portion
of
the
API.
Now
this
portion
of
the
code,
when
it
runs
internally,
will,
at
a
high
level,
intercept
API
request
that
comes
in
for
volume
operations
and
once
it
receives
that
Winston
intercepts.
Is
these
calls?
C
This
is
the
this
is
the
the
Cooper
net.
Is
that
CSI
repository-
and
this
is
where
we
keep
all
of
the
consequential
external
components
that
make
up
that
allows
us
to
that.
Allow
a
driver
author
to
participate
and
to
deploy
a
CSI
driver
you'll,
see
that
we
have
several
external
components,
and
these
are
sidecar
components
that
a
driver
author
would
would
deploy
along
with
their
driver
to
add
functionality.
For
instance,
if
you
want,
if
you're,
deploying
a
driver
that
supports
snapshot,
you
would
make
use
of
this
sidecar.
C
If
you
do
an
external
attachment,
you
would
use
this
this
sidecar,
we
have
the
docs.
This
is
very
recent.
We
have
a
resizer
which
allows
you
to
do
and
put
in
place
resizing
of
your
volumes,
and
then
we
have
an
external
provisioner,
which
is
another
sidecar
that
will
allow
you
to
create
your
volume
as
as
as
needed.
C
There's
also
in
here,
there's
also
some
what
we
call
they're
like
demo,
drivers
and
they're
fully
functional
drivers
not
recommended
for
production,
but
gives
you
an
idea
of
how
some
of
the
drivers
work
and
how?
If,
if
you
were
interested
in
creating
your
own
CSI
driver,
it
gives
you
a
starting
point.
So
one
of
the
one
driver
that
we
use
a
lot
of
is
the
CSI
host
bass
driver
and
it
is
a
implementation
of
the
existing
host
path
driver
that
we
have
inside
kubernetes.
C
But
this
one
is
a
CSI
specific
one
and
it
like
I,
said
it's
a
functional
driver.
It
has
all
the
different
all
the
different
constructs
that
you
need
to
create
a
fully
functional
driver,
so
a
lot
of
people
when
they
are
starting
out
creating
their
own
CSI
driver.
You
come
here
and
look
to
see
how
this
works,
and
then
there
are
other.
C
This
is
actually.
This
has
grown
since
the
last
time.
I
looked
at
it
and
we
could
see
additional
drivers
and
other
components
that
are
part
of
that.
A
part
of
the
external
seus
CSI
repo,
and
then
we
also
have
the
documentation
section,
and
this
is
the
kubernetes
CSI
doc.
We
saw
that
repo
inside
the
kubernetes
inside
the
kubernetes
repo
and
the
doc
is
actually.
This
is
a
great
area
for
anybody
who's
interested
and
want
to
start
contributing.
C
You
know
we
with
with
its
juggling
writing
code
and
writing
documents.
A
lot
of
us
do
the
best
we
can,
but
documentation
usually
suffered.
But
again
this
is
certainly
an
area.
We
can
use
more
hands
to
keep
it
updated,
but
there
was
a
big
effort
done
toward
the
end
of
last
year
and
earlier
this
year
to
bring
a
lot
a
lot
of
the
documents
up
to
speed.
So
I
think
it's
a
better
shape
now,
but
definitely
can
use
additional
help.
B
A
B
And
you
scroll
up
to
the
top
again
towards
the
top
you'll
see
I
just
wanted
to
point
out
here
on
some
of
these
repositories.
You'll
see,
you
know,
X
issues
needs
help.
So
if
you're,
a
new
contributor
and
you're
interested
in
getting
started
out,
you
can
like
take
a
look
at
these
repositories
where
they
we
have.
We
have
the
Help
Wanted
tags
on
there.
I
was.
C
C
C
B
A
Good,
that's
really
good
sweet.
This
was
great
and
let
me
make
sure
that
I've
answered
all
of
the
questions
in
chat.
What
a
one
sec,
don't
move,
I've
answered
everything
in
my
direct
messages
and
it
looks
like
we've
answered
everything
in
slack.
Let
me
go
to
Twitter
in
the
meantime.
Do
y'all
have
any
questions
for
each
other.
A
A
Alright
I
feel,
like
y'all,
know
each
other.
You
know
where
each
other
lives.
So
if
you
had
something
you'd
ask
directly,
but
that's
it.
For
today
we
have
officially
wrapped
up
two
episodes
of
meet
our
contributors.
I
feel
like
we've
already
had
hundreds
watch,
so
this
is
amazing.
Thank
you,
everybody
for
joining
us.
Thank
you,
of
course,
who
our
panelists
for
taking
the
time
out
to
help
mentor
folks
in
the
community.
This
is
such
a
benefit.
It
will
live
on
YouTube
forever
and
our
information
will
be
stale
in
three
days.