►
From YouTube: Kubernetes Meet Our Contributors Session 2 20190403
Description
When Slack seems like it’s going too fast, and you just need a quick answer from a human...
Meet Our Contributors gives you a monthly one-hour opportunity to ask questions about our upstream community, watch interviews with our contributors, and participate in peer code reviews.
Check this out for more information: https://github.com/kubernetes/community/blob/master/mentoring/meet-our-contributors.md
A
All
right,
hi,
everyone
welcome
to
our
second
session
of
the
day
for
communities
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
spending
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
wait?
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
alleviate
some
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.
A
A
D
E
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
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
similar
takes
a
shot,
yeah.
B
A
C
C
It's
been
so
long
and
coming
at
kubernetes
time,
yeah
I
just
remember
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.
It
was
my
first
heads
on
first
a
go.
Work
on
this
thing
is
gigantic
code
and
try
to
get
it
in.
C
C
E
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
queue
project,
just
started
kind
of
in
tandem,
so
I
just
started
working
on
that
and
my
first
PR
mini
cube
was
I.
E
Don't
even
know,
I
mean
probably
like
a
during
the
adding
the
like
vendor
folder
or
something
like
that
or
the
makefile.
And
then
my
first
upstream
contribution
was
I
fixed
some
some
issue
with
TP
ours.
Where
mini
kid
would
just
panic,
which
was
a
bit
problematic
because
it
had
to
do
with
like
when
I,
don't
know,
I
think
something
got
registered
and
then,
when
many
peeps
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
responsibilities,
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
your
handle
will
appear
in
on
a
section
of
the
code
that
you
that
you've
committed?
So
that's,
that's!
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
somebody
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
E
I
would
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
reviewer
as
a
coder
as
as
whatever
but
I
mean.
E
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
and
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
yeah.
You
can't
review
this
right,
you
know.
So
it's
just
like
kind
of
get
reviews
out
there
ask
questions.
Oh.
A
E
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
uber
are
going
from
the
reviewer
to
an
approver.
A
So
infil
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.
C
You
know,
because
cubanelle
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
that
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
You
know,
step
zero
step,
one
step
two:
how
to
contribute
to
kubernetes.
So
a
lot
of
the
a
lot
of
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
do
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
freshly
on
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
when
it
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
I
think
I
was
mean
yeah.
To
add
to
that
I
would
say
like
as
a
new
contributor
I
think
it's
good
to
like
start
off
small
and
slowly
grow
the
contributions
as
you
get
more
comfortable
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
overall
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.
E
I
would
I
would
have
to
reiterate
that
so
much.
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
road
map,
you
know
the
feature
set
in
scope
or
whatever
of
the
project,
then
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.
E
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.
The
contributor
population
that
took
the
survey.
I
was
like
a
hundred
and
seventy
people.
A
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
that
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
E
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
CLA
is
you
know,
maybe
creating
a
github
account
figuring
out
what
issues
are
what
PRS
are?
E
If
you're
used
to
kind
of
an
internal
version,
control
system
you
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
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
I
was
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
gold
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
where
the
path,
but
basically
it
outlines
a
lot
of
the
steps
that
you
need
to
get
started
on
a
technical
front.
C
The
tools
that
you
need,
how
to
use
git
to
to
check
out
the
code,
create
your
own
branch,
locally,
etc
and
ree-ree
base
that
against
the
master,
get
your
you
know,
work
on
your
code
and
then
what
you
need
to
do
to
check
that
back
in
and
and
and
I'll
push
that
back
in
and
create
a
PR
out
of
it
so
they're.
You
know
there
are
a
lot
of
different
knowledge
that
are,
and
that's
a
different
domain
of
knowledge
that
you
need
to
get
started
and
that
can
be
intimidating.
C
C
Development
environment
set
up
and
you're
rolling
you'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.
B
A
C
Yeah
I
think
even
in
even
in
storage,
I
wish
I
had
time
to.
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
a
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
going
to
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,
in
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
that
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
Farren.
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
E
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
going
to
do
CSI
code
based
or
which
is
super
awesome
Vlad.
Do
you
want
to
take
it
away?
Share
your
screen?
A
Yes,
and
while
you
do
that,
if
folks
are
out
there
and
want
a
code
based
or
of
anything
special
or
if
you
want
dependencies
explained
or
if
you're
ruffling
through
the
code
and
say
this
whole
entire
section
is
just
a
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
queue
builder
next
month,
also
of
the
scheduler
next
month,
and
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
up
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
would
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
stranger
code
reviews
and
you
were
pegged
to
the
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
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.
We
have
monitor,
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
Let's
look
at
the
external
components,
we'll
look
at
the
let's
see
this
is
the
this
is
the
the
kubernetes
that
CSI
repository,
and
this
is
where
we
keep
all
of
the
consequential
external
components
that
make
up
that
allows
us
to
to
that.
Allow
a
driver
author
to
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.
C
For
instance,
if
you
want,
if
you're,
deploying
a
driver
that
support
snapshot,
you
would
make
use
of
this
sidecar.
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
in
place
resizing
of
volumes,
and
then
we
have
an
external
provisioner,
which
is
another
side
car
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
path,
the
driver-
and
it
is
a
implementation
of
the
existing
host
BAFF
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're
starting
out
creating
their
own
CSI
driver.
You
come
here
and
look
to
see
how
this
works,
and
then
there
are
other.
C
C
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
as
actually
this
is
a
great
area
for
anybody
who's
interested
and
want
to
start
contributing.
You
know
we
with
with
it's
juggling
writing
code
and
documents.
A
lot
of
us
do
the
best
we
can,
but
documentation
usually
suffered.
But
again
this
is
certainly
an
area.
C
E
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.
B
B
C
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
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
All
right,
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.