►
From YouTube: Kubernetes Meet our Contributors 20180801
Description
Interested in learning how to contribute to Kubernetes? This livestream lets you ask contributors questions about getting started diving into the world of cloud native infrastructure.
Check out this page for more information: https://git.k8s.io/community/mentoring/meet-our-contributors.md
A
Hi
everyone,
my
name,
is
Paris
Pittman
I
work
at
Google,
I
do
kubernetes
community
management.
Here
this
is
our
August
edition
of
meet
our
contributors
meet.
Our
contributors
is
a
very
fast
way
for
our
current
and
also
new
contributors
to
get
information
that
they
would
typically
get
from
a
mentor.
Today
we
are
joined
by
several
mentors
of
different
backgrounds
and
different
parts
of
the
project,
which
will
give
us
a
good
idea
and
experience
level
of
questions
and
they'll
also
be
allowed
to
answer
issues.
A
We
ask
each
other
questions
so
panelists,
please
feel
free
to
do
that.
Of
course,
we
do
have
a
code
of
conduct
as
well
that
we
abide
by
that's
under
the
cloud
native
compute
foundation.
So
that
would
be
anybody,
that's
answering
or
asking
questions.
So
please
be
excellent
to
each
other.
Now
how
you
actually
ask
questions,
we
have
a
slack
channel
of
the
same
name
at
sea,
our
contributors
on
the
kubernetes
slack
instance.
If
you
do
not
feel
comfortable
asking
questions
publicly,
please
feel
free
to
direct
message
me.
A
My
display
name
is
just
Paris
like
the
city.
Pa
are
is
also
I
will
be
watching
Twitter
as
well,
so
I'll
catch.
My
DMS
there,
my
handle,
is
Paris
and
be
more
like
Baltimore
I
used
to
rub
that
city
for
33
years,
hi
everybody
in
410
and
then
oh,
am
I
gonna.
Keep
that
oh
I
almost
got
kicked
out
of
my
room
here
at
Google.
A
No
did
not,
though
anyway.
So
oh,
you
have
twitter.
So
if
you
are,
if
you
would
like
to
just
do
a
status
update
to
to
Twitter
just
use
the
hashtag
k8s
MOC
for
kubernetes
near
contributors,
so
first
things
first,
hello,
panelist!
Thank
you
for
joining
today.
We're
gonna
do
brief.
Intros
for
all
of
you
feel
free
to
take
up
to
admit
it
or
so
just
to
give
a
brief
introduction
and
then
we're
going
to
go
right
into
the
questions.
Let's
start
at
my
top
left
and
Jeffrey
Jeff
hello,.
B
My
name
is
Jeffrey
Sica
I
currently
work
at
the
University
of
Michigan.
My
title
is
research
database
administrators
senior,
which
doesn't
really
reflect
what
I
do
a
lot
of
the
time
right
now
we're
running
multiple
different
kubernetes
instances
for
research
and
academia.
So
that's
my
day
job,
but
on
the
side.
I
also
do
contributions
to
sig
UI
and
George
and
Bob
roped
me
into
sig
control
X
as
well.
I.
C
A
E
I'm
Tim,
pepper,
Tim,
pepper
and
I
would
echo
parros's
mention
there.
I'm
Ben
I
appreciate
the
help
you
give
me.
I
am
a
systems
engineer
by
trade
but
in
particular,
open
source
I've
been
doing
open
source
for
over
20
years,
which
gets
crazy
to
say.
Is
it
as
I
say
that
more
and
more
and
to
bubble
up
the
stack
where
he
had
done
things
much
lower
in
the
sadoc
towards
firmware
and
embedded
systems
and
Linux
in
my
past?
A
F
F
A
I
moved
away
from
that
discipline
and
now
I've
been
working
for
about
the
last
month
and
a
half
I've
been
working
as
a
software
QA
engineer
in
particular,
I've
been
trying
to
focus
on
upstream
testing
and
in
particular
a
QA
DM
and
all
the
sig
sorry
sig
life
coaster,
life
cycle
with
Tim
and
all
the
other
folks
in
in
the
company
that
are
there
as
well
I'm
again
like
super
happy
and
content
with
the
communities
community
and
I.
Hopefully,
I
can
provide
some
insights
for
those
wanting
to
participate
in
party.
D
D
A
Also
does
excellent
work
with
contributor
experience
y'all.
So
if
anybody
on
the
line
right
now
is
looking
for
ways
to
enter
the
project
contributor
experience
is
here
to
help
you
they've
done
a
lot
of
work
with
the
contributor
guide.
We
are
going
to
stand
up
a
contributor
website
shortly
and
lots
of
really
exciting
work
happening
in
this
special
interest
group,
and
that
actually
leads
me
to
the
first
question.
What's
a
special
interest
group
for
those
who
are
watching
right
now
and
are
like,
what's
a
sake
like
what
are
they
talking
about?
B
So
sick
is
a
group.
That's
managing
a
piece
of
correct
me
if
I'm
wrong,
because
I
could
very
well
be
wrong.
A
cig
is
a
group
managing
essentially
code
that
is
part
of
kubernetes
overall,
so
like
there
is
sake
UI
that
is
focused
on
the
kubernetes
dashboard,
which
many
people
may
log
into
and
like
V
the
cluster
there
is,
but
contrib
X
is
kind
of
an
interesting
thing.
You
do
have
code,
but
it's
more.
You
know
website
stuff,
so
yeah
yeah.
A
E
That's
that's
kind
of
the
the
top
level
distinction
around
code
ownership,
but
maybe
maybe
more
broadly,
it's
part
of
how
the
community
organizes
any
large
community
has
to
figure
out
how
to
organize
and
splits
work,
split
responsibility
and
do
that
in
a
way
that
has
ownership
and
active
ownership.
So
you
get
maintenance
and
you
don't
end
up
with
what
people
will
call
the
tragedy
of
the
Commons.
F
Yeah
I
agree
with
all
the
definitions
so
far,
but
I
think
also
at
least
the
way
I
understand
that
is
it.
Sig's
are
like
the
champions
for
that
particular
section
right,
like
they're
the
advocates
and
champions
so
like
at
signo
did
they
are
not
only
the
people
who
held
the
part
of
this,
they
know,
but
they
also
advocate
upstream
whether
they
need
to
contribute
with
a
different
say.
You
know
so
like
they
champion
also
the
causes
and
making
sure
that
things
get
done.
I
would.
D
Agree
and
I
would
add
to
what
Tim
said
that,
besides,
like
the
governance
aspect,
there
is
the
I
need
to
talk
to
someone
about
networking.
How
can
I
find
someone,
and
these
special
interest
groups
help
the
corner
box
people
working
on
in
the
project
into
like?
Well,
this
group
of
people
is
working
in
this
area,
so
that
might
help
you
find
someone
to
talk
to
you.
F
And
also
worth
the
distinction
that
it's
it's
not
at,
the
intent
is
not
to
silo
people
or
silo
teams.
It's
just
a
matter
of
like
being
able,
as
Tim
mentioned
earlier,
like
Lex
played
of
responsibility
and
and
that
sort
of
thing
so,
like
don't
think
of
SIG's
in
silos,
but
more
I'd
like
and
you
know
like
these
people
are
good
at
this,
and
they
want
to
work
on
this
type
of
thing.
But
it's
not
closed
off
to
anybody
and
it's
fairly
open
to
contribute
and
collaboration.
I
mean.
E
Just
some
of
the
six
sort
of
map
to
what
you
might
think
of
as
a
traditional
vertical
there's,
also
horizontals,
there's
things
that
span
all
of
these.
So
it's
it's
an
organizational
construct,
but
there's
overlap
and
fuzziness
and
there
they
they
mutate.
We
have
new
SIG's
that
come
and
we
have
some
that
retire
as
well.
So
this
is
a
constantly
evolving
thing
and.
D
I
can
explaining
to
say
that
y'all
could
kind
of
explain
how
that
relates
to
a
working
group.
I
think
it
would
help
people
understand
the
organizational
constructs
there
and
you
want
to
follow.
One
more
note
when
we
were
talking
about
the
siloing
I
think
it's
also
important
to
note
that
not
only
is
it
not
siloed,
but
people
are
involved
in
many
of
them
and
in
fact,
some
of
the
people
that
sort
of
run
the
SIG's
run
more
than
one
sig
and
that's
totally
encouraged.
We
wouldn't
want
anyone
to
force
himself
to
focus
on
one
area.
A
G
F
D
D
So
the
way
I
seem
like
a
so
SIG's
own
right
and
a
working
group
is
more
if
you
want
a
cross-disciplinary
thing,
that's
either
for
like
a
temporary
goal.
Right
like
we
need
to
accomplish
this,
and
we
need
involvement,
these
or
SIG's
I.
Think
of
it
as
a
Venn
diagram.
That's
what
that
is
right,
then
yeah,
the
middle,
the
middle
thing
that
has
all
the
overlaps
that
could
be
considered
like
a
working
group.
It
has
to
interface
with
a
lot
of
things
to
kind
of
force
that
horizontal
work
flow.
E
Then
there's
also
projects
or
sub
projects
within
SIG's
or
maybe
also
working
groups,
but
those
are
a
little
more
local,
so
a
distinction
than
being
like
if
a
work
group
sig
has
something
that's
substantial
and
they
want
to
have
a
focus
group
doing
it
that
maybe
becomes
a
sub
project.
But
if
that
thing
isn't
just
focusing
scope
to
the
sig
but
kind
of
has
some
Bret's
that
then
becomes
the
working
group
area.
Yes,.
A
A
So
we
do
have
a
ton
of
questions
actually
from
current
contributors
and
are
actually
around
some
similar
concepts.
One
is
maintainer
ship,
so
this
one
is
from
Nikita
who
does
significant
work
with
API
machinery
amongst
other
groups
like
contributor
experience,
Thank
You
Nikita
for
your
contributions
by
the
way,
so
she
still
struggles
to
understand
open-source
maintainer
ship.
From
the
perspective
of
how
do
you
become
one
and
then
how
do?
How
do
you
also
continue
as
a
maintainer
without
burning
out,
especially
if
that's
not
your
full-time
job,
so
this
is
sort
of
a
two-part
question.
A
D
I
think
it's
just
sort
of
a
natural
extension
of
you've
worked
in
an
area
so
much
and
that
you've
effectively
own
something
at
some
point.
People
declare
hey
this
person
owns
this
thing.
We
need
someone
to
maintain
it.
We're
gonna,
say
this
person
owns
it
so
with
kubernetes
you'll,
see
that,
like
oh,
this
person,
kind
of
I,
like
the
word
Tim
used
earlier,
championed
in
building
this
area
out.
If
they
did.
D
All
of
that,
then
we'll
go
ahead
and
say
you
know
this
person
is
a
maintainer
of
this
area,
but
other
people
can
come
along
and
make
significant
contributions
and
eventually
will
recognize
that,
like
they
should
really
be
a
maintainer
of
this,
you
could
so
I'd
say
just
to
rest.
There's
other
outre,
creating
something
I
mean
de-facto,
maintainer
ship
or
making
significant
contributions
to
something
and
then
winding
up
becoming
another
maintainer.
E
Yeah
echo
that
the
the
two
main
paths
I've
seen
are
like
a
project
that
I
started
for
example
or
me,
and
a
set
of
people.
We
started
out
on
a
white
board
trying
to
describe
a
problem
and
solve
it
and
ended
up
with
something
I
get
hub
eventually,
and
we
were
the
ones
who
were
the
maintainer
is
the
owners
of
the
git
repo
that
sort
of
thing
where
there
is
a
an
ownership
aspect.
A
And
what,
if
there's
a
current
contributor-
and
they
have
been
contributing
to
the
project
for
quite
some
time-
and
they
are-
you
know
in
a
prover
stage,
for
instance,
but
they
just
can't
seem
to
get
to
that
level
of
maintainer
ship,
because
there's
already
maintainer
x'
there
that
are
solid
and
doesn't
they
don't
seem
to
necessarily
be
going
anywhere?
How
does
like
what
is
your
advice
to
that
approver
to
gain
a
trust
or
to
gain
that
next
level
of
maintain
ership
I.
D
Mean
so
we
might
not
be
entirely
functional
there,
but
I
think
that,
like
if
you
have
been
making
significant
contributions,
maybe
you
might
need
to
book
someone
and
say:
hey
I'd
like
to
be
a
maintainer
if
someone
hasn't
already
called
you
out
for
it,
but
I
would
hope
at
that
point
we
would.
We
would
just
add
you
I,
don't
I,
don't
think
there's
any
like
super
special
way
to
like
get
around
that.
It's
just
if
you
I,
think
Tim
hit
on
something
with
with
this
sort
of
de
facto
delegating
I.
Think
that's
really.
D
The
key
thing
is
maintainer
Zoar
people
that
we
can
expect
to
delegate
like
maintaining
something,
and
if
you've
been
doing
that,
then
you
should
be
recognized
as
a
maintainer.
If
you're
not
doing
that,
then
you
kind
of
already
aren't
a
maintainer,
and
then
it
wouldn't
make
sense
to
recognize
you
this
one.
E
This
may
even
tie
into
the
second
part
of
the
question,
because
the
the
the
the
current
maintainer
may
be
burning
out
without
anybody
around
them,
knowing
it
so
as
somebody
aspiring
to
help
out
more,
even
just
raising
your
hand
and
articulating
that
out
loud
could
be
a
huge
act
because
it
gives
them
a
chance
to
say.
Oh
I
didn't
want
to
burden
you,
but
can
I
delegate
this
particular
thing
to
you,
because
I
really
need
help.
A
That
is
a
huge
step
in
open
source,
especially
because
we
all
are
so
busy
and
sometimes
in
our
silos-
and
you
may
not
know
what
other
people's
intentions
are
or
where
their
growth,
where
they'd
like
to
take
their
growth.
So
if
you
are
out
there
and
you
do
want
to
get
to
the
next
level
and
whatever
that
next
level
means
whether
it's
a
new
contributor
reviewer
and
improve
maintainer
etc.
A
Please,
like
folks,
know
who
are
decision-makers
that
that's
something
that
you're
very
interested
in
in
the
future,
alright
and
then
the
so
the
second
question
and
to
Tim's
point
about
burnout.
What
are
some
strategies
that
you
all
employed
that
help
you
with
managing
either
potential
burnout
or
have
you
ever
burnt
out
or
don't
tell
us
tell
some
stories.
H
A
Of
the
million
dollar
question
I'm
not
gonna
lie
feel
like
we
get
this
a
lot
open
source
in
general
gets
us
a
lot
and
I,
don't
think.
There's
I've
never
heard
any
one
person
have
them
have
the
same
answer
so
please
feel
free
to
be.
You
know,
off-the-cuff
and
give
your
own
kind
of,
even
if
it's
hey,
I've,
burnt
out
I
have
no
idea
what
I'm
doing
Jeff
you
raised
your
hand
yeah.
B
So
I'm
a
developer
by
trade,
not
necessarily
like
a
sysadmin,
though
that's
kind
of
become
a
fair
amount
of
my
job,
but
when
I
first
started
out
as
a
developer,
like
I
taught
everything
myself.
So
it
was
super
fun
for
me.
So
it
was
my
hobby
and
my
career
and
then
there
was
a
point
a
few
years
in
where
I
just
could
not
think
like
you,
wind
up
staring
at
your
screen
and
realize
you've
stared
at
your
screen
for
20
minutes
and
you've
done
nothing
and
you
can't
focus
and
that's
burnout.
B
It's
something
that
we
all
need
to
recognize
and
also
like
spread
awareness,
there's
ways
of
doing
that.
The
way
that
I
wind
up
combating
that
is
doing
the
exact
opposite
of
what
I'm
doing
it.
If,
if
I
feel
like
I'm
burnt
out
I'm
gonna
go
play
around
a
golfer
I'm
gonna
go
play
with
my
dog
I
need
to
have
clear
separation,
that's
hard
for
myself
and
for
a
lot
of
us
because
we
really
enjoy
what
we
do.
But
we
have
to
try
and
have
the
cognizance
to
recognize.
B
E
E
At
the
video
that
a
number
of
us
possibly
work
from
home
as
well,
so
that's
something
a
little
more
common,
potentially
an
open
source
and
and
that
can
make
it
challenging
to
set
the
boundaries,
because
sometimes
your
your
commute
hours
just
time
box
your
time
at
work
and
give
a
little
bit
of
physical
separation.
I
have
a
friend
who,
whose
wife
actually
made
a
fake
little
badging
swipe
machine
and
put
it
on
his
home
office
and
made
him
wear
a
badge
at
home.
And
if
he
was
wearing
the
badge
in
the
house,
he
was.
E
E
But
do,
though
you
can
do
that
with
your
community,
so
I
have
a
co-worker
who
is
in
a
European
timezone
and
I've
counseled
him
to
suggest
to
the
things
that
he
works
with,
like
hey
this
meetings
at
a
bad
time
versus
just
silently
attending
or
missing
it
or
saying:
hey
I
want
to
take
up
this
issue,
but
it's
actually
2:00
a.m.
I'm
gonna
table
it
till
tomorrow.
So
I
think
is
a
maintainer.
E
It's
important
or
there's
any
sort
of
a
leader
in
in
our
discipline
across
all
of
these
time,
zones
is
to
communicate
that
type
of
stuff.
Let
people
know
a
little
bit
about
where
you
are
the
struggles
you
might
be
going
through
a
time
balance
and
that
you,
you
do
you
definitely
eat,
and
sleep
and
I
do
think.
People
will
respect
that
I.
D
Would
it
is
important
occasionally
to
just
shut
things
out
for
a
little
bit
and
and
as
something
to
kind
of
ties
into
that
I
think
for
any
non-trivial
amount
of
code,
it's
important
to
as
much
as
possible
avoid
being
the
sole
maintainer.
You
really
just
shouldn't.
Do
that
to
yourself.
There
needs
to
be
someone
else
around
some
time.
You're
gonna
be
out.
You
need
to
take
a
break.
There
should
be
someone
else
lined
up
to
say
you
know
if
they
can
do
this
for
a
while
or
trade
off
I.
D
Don't
think
anyone
I
also
don't
think
anyone
who
maintains
very
non-trivial
amounts
of
code
in
this
project
has
done
it
without
doing
it
full-time.
It
is
just
you
can't
keep
up
I,
maybe
if
you
have
and
I
am
amazed
by
that,
but
I
wouldn't
recommend
it
I
think
out.
There
are
a
lot
of
good
places
that
would
be
willing
to
hire
someone
like
that,
and
then
it
might
be
worth.
You
know
looking
for
something
like
that,
because
it
really
is
just
extremely
time
consuming
yeah.
F
I
think
just
for
contributing
and
being
part
of
several
different
open-source
projects.
I
think
that
you
have
to
I
mean,
like
you
have
to
set
boundaries
for
your
own.
Your
own,
like
I,
alluded
to
this
earlier
right,
like
in
the
sense
like
you
says,
like
these
are
my
work
hours.
You
know
like
I,
try
to
be
flexible
so
that
way
I
can
encompass.
You
know
people,
let's
say
from
the
you
down
or
whatever,
but
like
don't,
kill
yourself
like
trying
to
like.
Please
everybody
don't
kill
yourself
trying
to
like
work
on
Saturday.
F
So
that
way
you
can
catch
somebody
from
like
7:00.
You
know
time
zones
be
looking
behind
you
or
something
right
like
you,
just
you
and
I
think
everybody
who's
been
in
open-source
is
very
empathic
and
very
understanding
of
this.
So,
like
I,
think
using
for
your
own.
You
know
well-being
in
your
own
sanity.
F
It's
just
you
know,
set
boundaries
like
so
it's
like
if
you
cannot
meet
one
day,
because
that
whatever
it's
a
team,
somebody
set
a
meeting,
let's
say
like
in
the
West
Coast
and
you're
in
the
East
Coast,
and
you
really
need
to
like
leave
that
day
at
5
p.m.
because
you
have
things
going
on
outside
your
work.
That
is
not
Cuban
eighties.
Just
say
it
I
mean
you
cannot
attend
that
meeting.
I'm
gonna
be
out
right.
F
F
If
you
don't
push
back
on
things,
if
you
know
I
mean
gently
and
of
course
you
know
like
in
there
in
the
psyche
of
the
community,
if
you
don't
defend
your
own
time,
like
people
will
unintentionally
like
assume
that
you
always
gonna
be
there
and
then
that's
only
gonna
lead
to
like
people
quote-unquote
abusing
your
time
right
like
it's
just
like
well
I
schedule
something
at
7
p.m.
because
you've
always
come
up,
and
you
never
say
anything
right
like
so
I
schedule,
something
that
maybe
you
already
have
different
plans
before
that
right.
F
So
like
it's
a
matter
of
like
hey
I,
think
most
of
us
in
the
community
are
painfully
aware
of
how
difficult
it
is
to
deal
with
a
distributed.
Do
you
distribute
the
team
and
special
in
communities
that
has
you
know
contributors
from
all
over
the
planet,
so
they
set
your
own
boundaries
and,
like
you
says,
like
I'm,
only
gonna
work
from
this
from
let's
say
a
a.m.
to
6:00
p.m.
and
that's
it
I
mean
like
I,
will
not
work
outside
those
things
either.
F
That
will
not
absolutely
not,
in
my
opinion,
should
not
hinder
your
ambitions
or
progression
towards
my
internship
or
anything
like
so
like
a
lot
of
people
think
that
putting
more
sweat
equity
put
somehow
gets
you
farther
there.
In
my
opinion,
that's
not
necessarily
true
I
think
like
with
the
quality
of
work,
and
especially
if
you
have
good
people
skills
you
can
like
get
anywhere
that
you
want
in
a
in
any
particular
say
that
you
want
to
participate,
or
you
want
to
lead.
A
Awesome,
those
were
really
good
responses.
I
heard
a
lot
of
communication
themes
in
there
which
actually
we
talked
about
and
the
first
question
so
state
your
intentions
and
state
your
boundaries.
That
seems
to
be
a
reoccurring
theme,
but
so
tacking
on
to
the
boundaries
piece.
You
know
as
someone
that's
actively
involved
in
the
project.
What
do
you
know?
People
like
what
are
RSL
leis
talk
to
us
a
little
bit
about
like
how
you
handle
the
influx
of
things
on
your
on
your
plate.
A
From
you
know,
an
actual
day-to-day
perspective,
I
hear
I
hear
that
a
lot
I
mean
I,
hear
the.
What
do
you?
What
do
we
owe
the
contributor
as
far
as
response
times
are
concerned?
A
lot?
That's
a
lot
of
chatter
right
now
and
open
source.
It's
like
what
do
you
people
reaching
out
to
you,
especially
when
you
might
have
you
know
hundreds
of
people
reaching
out.
D
I
think
maybe
Oh
might
be
the
wrong
way
to
phrase
it.
You
know
like
you,
should
do
your
best
and
that
we
should
you
know
we
should
try
to
foster
that
sort
of
thing,
but
I
think
as
soon
as
you're
framing
it
as
as
owing
them
something
you're.
Just
not
like
I,
don't
I,
don't
think
that's
the
same.
Well,
I
think
that's
the
wrong
mindset.
F
1,000%
agree-
and
you
know
I
I'm
fairly
involved
with
the
you
know,
folks,
in
the
Python
community
and
like
I,
you
know
off,
you
know
like
of
the
records,
but
with
a
couple
of
folks
who
maintain
larger
projects,
and
it
is
that
mentality
of
ownership.
That
actually
is
hurtful
like
maintain
errs.
Don't
owe
you
anything
right
like
you
just
like
you're
participating,
that's
their
project.
They
will
be
happy
to
make
it.
You
know,
keep
sure
they
practice.
F
It
keeps
going
and
keep
moving
and-
and
you
know,
see
well
your
PR,
czar,
etc,
but
like
they
are
doing
it
out
of
their
own
time,
and
most
of
us
are
doing
our
own
time.
Like
sure
I
know
some
of
us
get
paid
in
a
way
indirectly
to
do
this,
but
like
it's
like
I,
feel
yeah
for
me,
as
a
matter
of
like
the
maintainer,
hey
Owen,
something
to
to
the
community.
That
feels
like
a
bad
frame
of
mind.
My
opinion.
D
I
just
want
to
say,
even
though
someone
might
be
paid
full
time
to
work
on
a
project.
Some
things
like
kubernetes
are
so
complex
and
so
large
that
it's
impossible
for
one
person
to
do
that.
So,
while
we
are
fortunate
to
have
lots
of
great
companies
sponsor
the
work
and
everything
that
still
doesn't
mean
that
you
know,
oh,
that
person
works
here.
Therefore,
you
know
I
feel
like
I
can
give
them
an
incredible
amount
of
work.
We
have
to
be
cognizant
of
that
as
well.
D
I
just
wanted
to
add
that
point
there,
because
I
it
used
to
bother
me
that
I
can
never
keep
track
of.
What's
going
on
and
literally
part
of,
my
job
is
to
read
everything
that's
going
on
and
how
people
understand
that
it's
like
I
I
should
know
this
as
much
as
it's
impossible.
So
the
sooner
you
just
say,
there's
no
way.
I
can
do
this
on
myself
and
I'm
gonna
lean
on
the
team
of
people
around
me
to
help
us
all
get
there
together,
you're
just
immediately
you're
in
a
different,
better
mindset.
D
D
I
was
gonna,
I
mean
I.
Do
like
personally
kind
of
keep
my
own,
like
unofficial,
isn't
like
I
would
prefer
to
get
at
least
some
comment
on
someone's
PR.
That's
sent
my
way
within
24
hours.
I
think
that's
reasonable,
but
you
can't
like
force
yourself
to
hold
that
and
and
I
would
also
say
they.
You
know
to
the
point
of
the
people
that
are
working
full-time
on
this
I.
Think
almost
everyone
that's
working
full-time
on
kubernetes.
D
They
have
not
been
assigned
to
work,
full-time
on
engaging
with
PR
views
and
things
like
that
and
so
they're
almost
sort
of
still
donating
their
time
to
go.
Do
these
things
because
they're
not
really
getting
any
serious
credit
for
that
at
work
or
anything
like
that,
they
still
have
things
that
they're
expected
to
do
during
their
work
time.
That
really
don't
have
anything
to
do
with
that.
D
A
Then
and
I
think
that
this
program
right
here
is
an
example
of
that
I
don't
know
if
anybody
here
is
I
mean
I
kind
of
am
paid
to
do
this,
but
I
don't
know
I,
don't
know.
If
anybody
else
really
is
you
know
so
mentorship
and
growing
the
community
and
being
that
helpful
guide
is
stuff
that
some
people
don't
necessarily
have
to.
If
you
will
in
quotes,
do
so.
It's
just
important
to
note
that
I
think
so
echo.
A
D
Also
good
that
somebody
at
some
point
recognizes
that
we
as
a
project
need
to
develop
programs
like
this
on
purpose
now,
so
that
in
the
future,
we're
you
know
we're
basically
investing
in
ourselves
at
this
point
right
and
our
future
selves
and
the
people
that
we're
gonna
come
in.
So
like
a
plus
one.
E
So
echo
a
couple
of
things:
there
I
definitely
like
the
bin
throughout
a
number
I
am
going
to
try
within
48
hours.
It's
it's
hard
within
24,
so
I
sort
of
have
48
and
I
think
that
also
is
whatever
your
number
is.
It's
so
important
as
a
professional
to
have
some
sense
of
that
we
all
get
overwhelmed
in
our
email,
but
to
be
able
to
to
back
that
up
with
tools
and
things
so
you're,
you're,
sorting
and
filtering
and
you're
noticing.
Ok,
this
bucket
is
getting
too
full
of
stuff
that
I'm
not
getting
to.
E
Maybe
this
is
actually
a
place
that
I
need
to
start
delegating,
because
I'm
gonna
get
burned
out
that
sometimes
our
inbox
is
the
leading
indication
around
other
things.
So
there's
that
and
then
I
also
I
think
something
that
been
kind
of
got
onto
and
and
also
Rubin
the
idea
just
around
empathy.
It's
also
important
for
contributors
and
folks
new
to
open
source
to
understand
that,
within
whatever
this
hierarchy
is,
as
you
get
towards
maintainer
shapour
leadership,
types
of
roles
that
you
do
become
more
busy
and
it's
easy
for
things
to
potentially
fall
through
the
cracks.
E
There's
a
there's
a
talk
on
YouTube
by
somebody
in
a
different
community
describing
that
our
maintainer
ship
and
how
they
get
multiple
thousands
of
emails
a
week
and
each
of
there's
still
maybe
a
thousand
threads
of
discussion
with
a
thousand
people.
And
then
one
of
those
people
comes
up
to
them
on
a
conference
and
is
like
hey.
E
Are
you
gonna
merge
my
PR
and
they're
like
who
are
you
which
conversation
is
that,
like
so
there's,
there's
a
lot
going
on
and
it's
important
to
realize
that
people
may
be
overtaxed
and
is
the
person
coming
in
to
be
empathetic
to
that
and
think
about
like
how
can
I
engage
way?
That's
a
light,
touch
and
efficient
and
is
also
considerate
to
that
person's
time.
Recognizing
that
they're,
busy
and
and
I
may
not
be
their
biggest
priority,
but
to
also
I
would
say,
stick
with
it
because
we're
all
better
together.
E
So
if
you
don't
get
a
response
immediately,
you
know
I
mean
something
might
have
happened
and-
and
you
never
know,
I
mean
each
of
us
has
things
that
happen
outside
of
work
and
life
as
well.
That
takes
us
away
from
the
project
or
from
work,
and
you
may
be
hounding
somebody
who's
having
a
major
life
crisis,
or
something
like
that,
and
it's
so
important
to
have
that
empathy
aspect
there.
I.
A
Good
answers
all
right,
so
now
we
have
a
technical
question
in
the
meter
contributors
slack
channel
from
M
Singh.
They
would
like
to
know
which
packages
libraries
modules,
not
sure
what
they're
called
and
go.
Does
every
software
engineer,
regardless
of
special
interest
group,
have
to
interact
with
/
understand
for
the
project.
D
I
mean
so
hopefully
not,
hopefully
not.
Everyone
has
to
necessarily
understand
that
I'm
sure
it
happens.
I
don't
think.
There's
necessarily
one
I
think
this
project
is
so
wide,
especially
once
you
start
to
consider
things
like
all
the
different
sub
projects
and
things
that
nobody
really
I
think
that's
the
real
thing.
People
people
often
think
like.
Oh,
you
must
know
like
all
the
tests
or
something
reality
is
there's
just
too
much
and
I.
Don't
think
anybody
actually
knows
all
of
it
and
that's
okay.
We
collectively
know
it.
F
No
I
do
agree
with
a
client
go
like
I.
Think
that's
pretty
much
across
the
board
like,
and
it's
got
a
love.
Let's
say
new
ones
to
it
so
like
from
version
to
version
as
well.
So
I
think
that
is
something
very
good
to
know.
If
you
know
it
well
like
it
can
become
very
useful
and
practical
in
a
number
of
different
verticals
I.
E
D
D
Is
you
kind
of
need
to
understand
some
of
the
concepts
behind
communities
like,
for
example,
that
most
of
things
work,
I
use,
specify
what
I'd
like
things
to
look
like
in
some
declarative
format,
and
then
something
else
will
pick
that
up
and
try
to
make
the
world
look
like
that
is
kind
of
core
to
kubernetes
and
how
everything
works
and
understanding
that
I
think
it's
a
lot
more
crucial
than
like
one
particular
part
of
the
codebase.
However,
if
you
do
start
working
on
it,
client
goes
everywhere.
I
would
echo
that
maybe.
E
A
And
any
anything
else
from
Jeff
for
Ruben
before
we
go
on
sort
of
related
question,
that's
why
I
teed
that
up
there,
what
were
some
challenges
that
you
all
faced,
in
particular
with
learning
a
particular
part
of
either
the
codebase
or
the
process
like
what
was
your
most
challenging,
where
you
had
to
Wow
go.
Oh
wow
I
really
need
to
to
learn
more
in
either
this
area
or
study
this
more
or
examine
this
more.
F
So,
at
least
for
me
like
that,
the
hardest
part
was
to
know
where
to
look
at
the
code
like
that
was
like
that
for
I
knew
the
problem
at
hand
and
I
knew
where
I
had
to
solve
it,
and
what
to
do,
but
I
could
not
find
the
pertinent
code
save
my
life,
I
mean
just.
It
took
a
lot
of
conversations
in
the
sig
and
hopefully
have
people.
You
know
I
helped
you
helping
me
out.
You
know
like
for
this,
but
it
it
was.
F
It
was
very
challenging
to
find
out
where
things
move,
because
I
can
be
such
a
big
piece
of
software.
Not
all
the
code
is
in
the
same
place
where
you
were
clicked
or
things
pre-select
the
website,
that's
a
different.
The
repol
together
so
like
you
can
spend
a
half
an
hour,
trying
to
figure
out
what
to
fix
things
in
the
docs
and
they
turns
out
is
a
different
repo
same
with
communities
released
like
you
will
figure.
Everything
is
under
the
bill
thing,
but
it's
not
necessarily
true
release.
F
Does
their
own
thing
their
own
different
thing
so
like
it's,
that
was
to
me,
like
the
most
jarring
part,
was
the
fact
I
had
to
reconcile
the
fact
that
code
that
I
code
that
I
needed
to
either
code
of
Doc's
that
I
needed
to
manipulate
or
either
add
or
modify
we're,
not
in
the
structure
that
my
mental
concept
wasn't
and
they're
like
this
is
where
you
know
the
six
come
here
very
handy,
because
that
will
definitely
people
let
you
know
where
things
are
so
like
there's.
You
know
like
I,
said:
hey.
F
E
A
couple
of
places
that
I
struggled
as
a
newcomer
was
that
similarly,
the
organizational
stuff
but
I
would,
for
example,
I
didn't,
go
look
at
the
sub
directory
hack
because
I'm
thinking-
oh
that's,
advanced
stuff,
not
for
me,
but
then
there's
some
important
stuff
that
you
might
use
almost
regularly
in
there.
Or
that
gives
you
context
on
things
and
also
on
the
release
team.
There
is
a
magic
subdirectory
of
documentation
called
ephemera
and
I
thought
initially.
E
Oh,
that's
just
random
other
bits,
but
there's
a
few
things
that
are
important
there
and
then
sometimes
you
go
to
the
snake
and
ask
a
question
and
they
say:
oh,
are
you
following
that
thing
from
ephemera
or
hack
or
whatever
the
equivalent
isn't
like?
We
really
ought
to
delete
that.
So
people
don't
fall
into
the
same
trap.
So
we
we
have
in
all
open-source
projects
are
today.
D
Just
exactly
it's
such
a
huge
project
again
that,
like
knowing
everything
you
know,
if
you
run
into
something
you're
like
this,
is
hard
I,
don't
know
where
this
is
more
often
than
not
it's
better.
To
just
say
you
know.
This
is
probably
this
SIG.
Let
me
reach
out
to
some
folks
who
probably
do
know
this
and
and
not
spend
days
wandering
through
rabbit
holes.
I
I've
had
that
a
few
times,
and
definitely
if
you're,
if
you
just
reach
out
within,
for
example,
slack
and
and
ask
the
community
they're
generally
like
very
willing
to
hope.
D
F
F
It's
like
go
make
that
like
to
be
like
a
punitive
against
yourself
like
because
even
people
with
a
lot
of
experience
in
the
project
sometimes
get
in
these
loops
themselves,
like
because
there's
a
lot
of
MIB
on
undocumented
tribal
knowledge
for
a
particular
sake
of
a
particular
vertical,
and
you
know
like
it,
doesn't
matter
what
skill
of
a
software
engineer
you
are
like.
Unless
you
have
that
information
like
you,
might
spend
unnecessary
amounts
of
time
and
very
frustrating
times
trying
to
figure
something
out,
so
just
I
think
they've
met.
F
You
know
I
suck
at
this
right,
like
I
know
it's
easy
for
us
engineers
to
be
very
you
know,
self-punishing
and
very
you
know
like
a
impostor
syndrome
and
all
this
stuff,
and
especially
in
a
huge
project
like
you,
ladies,
this
is
very
very
easy
to
happen.
So,
like
just
don't
be
hard
on
yourself,
yet
reach
out
to
people
and
you'll
be
guided,
you
know
towards
a
possible
solution
or
a
possible
area
where
you
can
actually
get
this
done.
F
B
Like
to
add,
like
IV
programming
is
art
and
oftentimes
when
I
am
like
working
on
PRS
I
feel
like
I'm
finger
painting
on
top
of
Mona
Lisa,
but
it's
still
helping
me
get
better
as
a
person,
so
don't
feel
bad
if
you're
also
feeling
the
same
way,
you
will
get
you
know,
reviews
you
will
get
comments
and
critiques,
but
they
will
help
you
both
in
your
pee,
our
end
to
become
a
better
program.
What.
B
Going
like
I
am
a
polyglot
when
it
comes
to
languages,
however,
golang
is
like
I
can
read
it
and
understand
it,
and
then
it
takes
me
forever
to
fully
like
understand
how
streamlined
people
can
code
in
it.
So
just
getting
up
to
speed
in
learning
more
about
golang
was
the
hardest
thing
for
me,
and
and
even
still
like
I
have
a
PR
hanging
because
I'm
using
a
pool
and
not
a
struct,
and
it
is
currently
you
know,
taking
up
eight
bytes
instead
of
zero
in
memory.
B
A
C
B
F
F
Benitez
had
just
been
released
like
a
month
before
that,
and
this
was
when
obviously
docker
was
I
called
the
rage
right
like
docker
was
amazing
and
everything,
and
so,
and
it
just
so
happens
that
well
Austin,
what's
going
on,
there
was
a
meet-up
at
the
New
Relic
offices
there
in
Portland,
and
you
know
we
went
there
as
a
group,
all
the
Rackspace
folks,
where
the
booth
whatever
and
show
up,
and
it
turns
out
that
kills
Tower.
It
was
there
giving
a
demo
about
this
thing
that
never
ever
heard
of
you
know
like.
F
Oh,
this
Cuba
needs
thing,
and
then
he
gave
like
a
live
demo.
You
know
like
some.
He
did
some
crazy
things
with
back
then
in
the
early
versions
of
your
knees-
and
you
know
lo
and
behold,
things
work
and
you
know
we
were
like
as
soon
as
that
demo
was
done.
Where
we're
talking
to
ourselves
like
okay.
How
do
we
use
this?
Let
let's
start
learning
so
like
that
was
my
first
exposure,
particularly
in
eighties,
was
in
2014,
July
plus,
and
we
got
through
it.
I
threw
me,
you
know,
through
the
user
group
in
Portland.
C
D
So
I
think
it
was
like
early
2015
I
was
still
in
college.
I
was
very
interested
in
open
source
and
I
wound
up
deciding
I
wanted
to
do.
A
google
Summer
of
Code
and
I
was
interested
in
systems
stuff
and
I.
Looked
around
and
I
found
this
a
nice
project.
Wasn't
it
we
don't
get
and
they
had
a
couple
of
things.
I
wanted
worked
on
and
one
of
them
was
they
had
this
user
space
proxy.
That
was
connecting
everything
together.
D
They
wanted
to
make
the
kernel
do
it
and
this
Tim
Hawking
guy
google
had
this
cool
idea
to
use
iptables.
It's
like
one
song,
the
work
on
it
so
I
applied
and
they
accepted
so
I
worked
on
that
that
summer
and
even
back,
then
the
community
was
just
pretty
awesome
and
it
was
a
cool
project.
So
about
two
years
later,
when
I
graduated
I
applied
to
Google
and
I
wound
up.
Luckily
someone
noticed
that
and
said
no,
let's
put
him
on
a
team
that
is
true.
D
Nice
stuff
and
I've
been
doing
that
for
about
a
year
and
again,
I
would
just
say,
like
probably
the
biggest
draw
for
me
beyond
the
interesting
software
is
just.
This
is
a
really
excellent
community.
This
is
a
community
that
has
some
people
like
Paris
and
Georgia,
who
work
on
this
full-time
to
make
sure
that
we
have
a
friendly,
active
community,
and
that
makes
it
an
awesome
project
to
work
on.
A
I
was
actually
gonna.
Ask
you
a
G
sock
question,
so
I'm
glad
that
you
brought
that
up.
Yes
and
kubernetes
does
participate
in
google
Summer
of
Code
for
all
of
those
who
are
listening.
Yes,
we
are
now
done
with
our
we're
rounding
out
the
summer,
so
catch
us
next
summer
for
those
that
are
listening
for
that
and
then
Tim.
What
about
you.
E
E
So
we
were
doing
a
number
of
things
to
look
at
well.
Can
you
orchestrate
vm's
and
containers
together?
Can
you
make
vm's
fast,
and
one
of
the
things
that
came
out
of
our
department
was
the
clear
containers
which
became
cata
containers
and
another
less
known
thing
was
a
thing
called
the
cloud
integrated
advanced
Orchestrator.
We
wrote
our
own
Orchestrator
back.
E
D
Yeah
I
had
a
friend:
does
he
miss
Chuck?
He
was
on
former
coworker
at
mine.
Chuck
was
his
last
name,
sorry
Chuck,
and
he
was
like
hey
check
this
out.
I'm
gonna
show
you
something
cool.
You
know,
containers
right,
I
was
like
yeah
I
know,
containers,
it's
a
blob,
I,
get
it
and
he's
like
so
go
to
this
URL.
It's
on
my
laptop
and
I
typed
in
you
know
ten
dot,
whatever
it
was,
and
then
he's
like.
Are
you
on
it?
Are
you
on
it?
D
Okay,
I'm
gonna
kill
some
things
now
and
then
he
turns
around
his
laptop
shows
me
killing
a
bunch
of
stuff
and
he's
I
keep
hitting
f5
on
your
browser
and
I
was
like
okay
got
it,
you
know
and
it
it
worked,
and
everything
and
I
was
like.
Oh
I,
remember
doing
this
when
I
was
assistant
admin
in
college,
you
know
we,
you
know
everyone
kind
of.
Does
this
load
balancer
thing
or
whatever
he's
like
yeah,
but
this
is
for
containers
and
it's
kind
of
generic
and
for
everybody.
D
So
you
don't
have
to
build
this
from
scratch
or
house
like
that.
That
is
the
holy
grail.
Like
I've
been
ops,
people
have
been
looking
for
their
whole
life
like
without
having
to
make
your
own
custom
thing
or
or
all
that
stuff
and
then
at
scale,
I
think
the
next
year,
Tim
Hawking
gave
a
talk
right
before
it
was
before
1.0,
and
he
was
talking
about
at
the
time.
Kubernetes
didn't
scale
at
all
past,
like
I,
think
it
was
a
hundred
nodes
or
whatever
and
Tim's
talk
was
like.
D
This
is
why
we're
not
worried
about
that
like
we
know
the
work
that
needs
to
be
done
there,
but
what
we're
working
on
is
like
more
of
an
API
thing,
if
not
that
right,
like
all
that
stuff
kind
of
comes
later
and
I,
think
we
also
kind
of
get
bent
around
kubernetes
is
like
an
orchestrating
container
thing
that,
like
what
it
really
is,
is
a
common
set
of
api's
to
do
the
stuff
that
people
want
and
and
as
soon
as
I
saw,
that
I
was
like
this
is
this?
Is
it
this?
D
Is
the
one
and
and
I
yeah
I
found
myself
trying
to
find
every
excuse
I
could
to
work
on
them
and
eventually
got
an
opportunity
to
be
here
so
I
like
love?
Nothing
makes
me
happier
to
see
when
other
people
get
that
moment,
whether
they're
doing
their
first
deployment
or
when
you
go
in
and
kill
nodes
under,
like
I
like
to
show
people
and
then
kill
nodes
without
telling
them
you
know,
and
then
it's
hey
I
just
removed
hefty
infrastructure.
You
didn't
even
know
like
to
watch
people
like
understand
how
that
actually
helps
them.
D
A
D
Okay,
so
I
would
say
my
team,
probably
just
previous
to
me
being
on
it.
We
were
sort
of
I
mean
so
Google's
one
of
the
groups,
that
kind
of
like
bootstrap
the
project,
I
guess,
would
be
a
rough
Farish
approximation
and
at
some
point
someone
said
we
need
testing
and
throw
up
a
Jenkins
somewhere
and
was
like
this
is
fine
and
over
time
all
the
tests
became
containerized
and
someone
realized
hey
kerbin,
as
runs
containers.
Why
are
we
maintaining
a
whole
bunch
of
yen
somewhere
to
run
containers,
and
we
can
do
that
with
communities?
D
So
Crowl
is
a
couple
of
things.
One
of
those
is
running
the
tests
for
kubernetes
by
using
kubernetes.
The
other
thing
is
a
variety
of
project.
Automation
thinks
things
so
that
you
can
automate
various
giddup
things.
A
big
thing
we
run
into
is
that
we
like
to
label
things
in
the
project
and
say
like.
Oh,
this
is
an
approved
thing,
or
this
is
the
sig
or
something.
But
in
order
to
let
people
edit
labels
on
github,
you
have
to
give
them
write
permissions
to
the
repo
which
is
crazy.
D
A
A
H
D
D
D
I
would
say,
the
biggest
thing
is
knowing
that
there
are
these
various
commands
you
can
use,
which
I'm
going
to
send
in
the
slack,
and
we
have
some
live
generated.
Details
at
that
link.
Where
you
can
say
what
is
this
repo
and
what
can
I
do
in
it
and
who
can
use
it?
Those
are
super
useful
other
than
that.
Hopefully,
contributors
don't
actually
need
to
know
much
about
prowl.
It's
just
there's
tests,
they're
posted
it's
like
having
Travis
or
something,
and
then
we
have
these
Chaddock
commands.
So
you
can
do
various
things.
D
D
A
B
A
D
D
Slack
is
a
great
way
to
do
that,
if
but
other
than
that
on
github
they're,
our
Help
Wanted
and
for
new
contributors,
labels
and
I
know
I
had
some
other
folks
have
been
trying
to
push
for
actually
using
those
and
particularly
marking
things
as
this
is
for
new
contributors,
then
those
are
get
up
wide
concepts,
so
hopefully
you'll
find
those
pretty
commonly,
and
you
can
look
for
some
issues.
That
say
you
know
this.
We
think
this
is
a
good
one
for
someone
starting
off.
F
I
would
like
to
echo
Ben's
sentiment.
I
think
it
is
right
now
there
is
more
work
than
there's
people
to
do
it,
and
this
is
across
SIG's,
and
you
know,
like
any
contributions,
are
very
welcome
so
like
whether
it's
ducks
where
there
is,
in
fact
sometimes
it
is
very
helpful.
Just
do
if
you
happen
to
know
a
particular
area
review
that
say
that
you
have
experience
from
your
work,
and
you
know
you
have
answers
to
things
just
being
in
the
slack
channel
answering
questions.
F
That
is
very,
very
helpful,
even
if
you
never
contribute
one
line
of
code
that
is
incredibly
valuable,
like
for
the
community,
like
I've,
seen
people
answering
questions
in
slack
channels
that
perk
to
my
own
questions,
I
mean
like
they're,
not
necessarily
the
maintainer,
so
they're
necessarily
in
the
sig.
They
just
happen
to
know
you
know,
because
they
themselves
have
been
caught
by
certain
issues
before
or
they
point
me
out
to
other
places.
F
So,
like
a
you
know
like
they're
like
telling
song
heroes
so
to
speak,
and
you
know,
I
would
like
to
thank
those
people
who
do
that
use
this
opportunity
to
thank
them
for
that.
But
especially
if
you
just
want
to
get
acquainted
with
a
community
window
with
a
particular
sig,
just
you
know,
bending
in
the
channel
and
answering
questions
like
that
is
incredibly
helpful,
so
I
think
that's
my
plug
will
be,
for
you
know
a
bug
it's
just.
Basically,
if
you
are
a
new
contributor
you're,
an
aspiring
contributor.
F
Just
going
to
this
thing
that
you
fill
more,
you
know
like
and
not
empathy
that
you
form
or
I
tune
with
a
maybe
you're,
a
specialist
on
storage.
You
go
to
six
storage
or
your
network
specialist,
but
the
signal,
work
and
turtle
help
people
they're
like
I.
Just
you
know
to
answer
questions,
and
you
know
like
be
helpful
and
you
know
like
you'll
become
noticed,
and
you
know
people
will,
like
you
know,
say:
oh
that
person
in
this,
like
they're,
really
good
at
whatever
so
like
it's.
F
It
is
a
great
way
to
create
rapport
in
that
particular
community,
and
you
know,
like
I,
think
it's
just
the
best
way
in
the
lowest
cost
and
the
lowest
pant
and
the
least
part
of
resistance
towards
becoming
an
actual
can
play
like
a
code
or
that's
a
code
or
documentation
contributor
before
that.
The
easiest
path
for
that
would
be
just
being
in
the
channel
and
participate
in
the
community.
A
E
With
the
other
or
the
other
folks
have
said,
like
Ruben,
it's
a
kind
of
a
frequently
asked
question
as
a
new
contributor.
What
should
I
work
on
well?
Obviously,
although
the
first
pass
is
what
do
you
have
an
affinity
for,
but
if
you're
looking
more
broadly
at
the
project,
stick
release
and
the
release
process,
if
you're
a
skilled
software
engineer,
who's
done
releases
things
like
that
understand,
project
management,
documentation,
contributor
experience
as
well.
A
Great
awesome
session
today,
y'all,
thank
you
so
much
for
your
time,
greatly
appreciated
for
those
that
are
listening
to
either
live
or
the
recording.
We
do
this
once
a
month.
First
Wednesday's
of
the
month,
please
subscribe
to
the
YouTube
channel.
If
you'd
like
to
get
alerts,
that's
the
best
way
to
keep
up
to
date
with
live
streams
and
meetings
and
sig
meetings
and
meetings
and
meetings,
and
thanks
again
to
the
panel
and
I,
will
see
you
all
on
slack
I'm.
Sure
thanks
so.