►
From YouTube: Kubernetes SIG Architecture 20190221
Description
A
All
right
welcome
our
buddy.
It
is
Thursday
the
21st
of
February
2019.
This
is
the
kubernetes
sig
architecture
group
and
I'm
Jase,
singer
DeMars
your
host
and
I
work
at
Google
and
your
other
paint
chairs
are
here,
Brian
grant
and
that's
right
now.
We're
gonna
go
ahead
and
kick
off
a
slightly
different
Sagarika
picture
meeting
this
time
and
well
I'm
gonna
go
ahead
and
present
a
deck
and
we'll
get
started
there
before
I.
A
Do
I
do
want
to
ask
a
favor
of
the
community
as
we
go
through
this
and
I
am
pretty
light-hearted
most
the
time,
but
this
is
something
I'm
really
serious
about
and
I'd
love
to
to
sort
of
preserve
questions
until
the
end
and
I
kind
of
get
through
that
this
presentation,
just
so
that
we
can
sort
of
concentrate
our
discussion
and
not
have
it
be
sort
of
spread
out.
So
if
you
could
all
give
me
a
favor,
that
would
be
super
helpful
and
kind.
A
A
So
yeah
this
was
a
very
ostentatious
title:
re-envisioning,
sick
architecture,
sustainability,
effectiveness
and
millennial
project
values.
Behind
that
title
is
really
sort
of
a
growing
level
of
concern
amongst
myself
and
a
lot
of
people
that
I've
talked
to
informally
and
formally
over
the
last
several
weeks
about
what
we
see
is
sort
of
an
increasing
level
of
frustration
and
burnout
amongst
our
our
top
contributors.
A
Just
because
there
is
seems
to
be
an
endless
well
of
things
that
need
to
be
done
and
a
not
seemingly
and
as
well
of
people
to
do
those
things
and
if
you've
been
on
these
calls
with
Sagarika
tech
chure
over
the
past
year
year
and
a
half
a
rallying
cry
that
I
have
often
made
is
just
to
to
try
and
get
people
to
step
up
and
in
volunteer
for
various
things,
ranging
from
note-taking
duty,
which
has
anybody
volunteered
to
take
notes.
Yet
if
so,
please.
A
Wow,
we
really
need
to
add
more
api,
reviewers
and
approvers,
and
we
also
need
to
staff
out
some
of
the
other
sub
projects
we
have
like
the
code
organization,
so
so
this
led
to
a
series
of
discussions
with
people
blog
with
the
community
and
and
trying
to
think
about
what.
What
can
we,
as
a
group,
do
to
become
more
effective
to
become
more
useful
to
the
community
to
really
to
do
what
weird
tests
do
by
our
Charter?
A
So
let's
talk
about
that
for
a
second,
so
our
Charter
is
this
really
at
the
end
of
the
day,
where
we're
supposed
to
maintain
and
evolve
the
design
principles
of
communities
as
a
group,
and
in
order
to
do
that,
we
really
need
a
consistent
body
of
expertise
to
ensure
architectural
consistency
over
time.
So
with
those
two
things,
there's
a
lot
embedded
in
that
it's
a
short
sentence
with
a
lot
of
meaning,
and
so
we
have
to
maintain
which
has
a
lot
of
implications
and
then
there's
also
the
people
to
do
it.
A
A
A
It
helps
us
ensure
that
when
you
say
you
have
communities,
it's
consistent
across
all
implementations,
so
that
has
implications
in
terms
of
writing
tasks
in
terms
of
looking
at
the
testing
structure,
a
whole
bunch
of
work
code
organization,
same
thing.
How
do
we
deal
with
extending
and
all
all
manner
of
things
and
staging
and
all
that
good
stuff?
So
there's
a
ton
of
things
here,
and
so
what
I
did
was
I
wouldn't
looked
at
who's
actually
doing
this
work
and
I
came
up
with
anonymize
colored
dots
to
represent
people
who
are
doing
this
work.
B
A
Dots
across
these
various
things,
what
that
means
is
that
you
have
one
person
trying
to
do
a
lot
of
work
in
a
lot
of
different
areas,
which
is,
as
we
know,
is
incredibly
hard
in
terms
of
context.
Switching
and
all
the
things
that
you
have
to
do
to
be
effective,
especially
in
deep
technical
work,
I,
it
doesn't
lend
itself
to
concentration
or
actually
getting
anything
done.
So
this
is
a
big
problem.
You'll
also
notice
I
looks
like
there
are
dots
missing,
I,
think
I
have
an
old
version;
it
was
stacked
or
something
that's
right.
A
So
when
we
move
forward
in
the
in
the
thing
here,
we
look
at
these
people
and
we
notice
that
there
are
really
only
nine
people
spread
across
all
these
sub
sub
projects.
When
I
see
nine
people
that
that's
people
who
are
committed
and
owners
files
to
actually
work
on
these
things,
and
when
you
get
down
to
it,
the
people
who
actually
are
spending
a
lot
of
time
on
this
is
significantly
less
than
that
night.
A
And
so
we
talk
about
burnout
and
we
talk
about.
You
know
people
getting
tired
of
doing
the
same
thing
over
and
over
again
and
I
having
backups
or
people
to
pass.
The
work
on
to
this
is
really
the
heart
of
that
remind
you
that
the
people
who
are
at
least
colored
circles
here
are
also
leaders
in
other
areas
of
the
projects,
other
sakes
other
working
groups.
This
is
probably,
in
some
cases
only
some
partial
view
of
what
they're
doing,
for
example,
one
of
those
one
of
those
dots
is
also
released
late.
A
This
time,
all
right,
so
there's
a
lot
of
work
there.
So
in
in,
in
short,
really
our
mission
as
a
saying
is
at
risk.
We
have
the
centralized
reliance
on
a
few
contributors
that
are
really
reaching
burnout.
We
don't
have
a
succession
plan
and
we
don't
really
have
people
queued
up
and
lighting
up
to
become
the
replacements
for
the
people
who
are
getting
burned
out
and
last.
A
It
really
feels
like
our
meetings.
I
have
a
lot
of
different
formats,
but
this
sort
of
uniform
outcome
is
that
not
a
lot
of
things
happen
that
actually
result
in
work
getting
done
and
I
think
the
part
of
that
comes
from
the
fact
that
we're
just
a
meeting
is
not
a
good
place
to
make
decisions
for
as
a
general
rule,
especially
as
a
community
meeting,
because
for
when
this
meeting
is
at
a
terrible
time
for
people
in
other
time
zones.
A
It's
hard
to
get
people
with
diverse
perspectives
to
be
able
to
communicate
in
a
way
that
it
works
for
their
favor.
So
if
you're
a
quiet
person
the
room,
you
may
not
necessarily
have
the
mic
at
a
specific
time
to
eat
it
or
you
might
not
be
the
person
that
has
or
you
might
not
be
hearing
from
the
person
that
has
the
most
experience
or
relevant
viewpoint.
A
It
doesn't
really
give
an
opportunity
for
people
to
reflect
and
consider
so
for
me
personally
at
a
meeting
I
like
to
think
about
things
and
when
a
meeting
is
happening,
I
find
myself
so
focused
on
the
discussion
that
I'm
not
able
to
really
reflect
on
what
I
want
to
say
and
by
the
time
I
use.
Sometimes
it's
the
moment
is
past.
A
We
rarely
have
proper
representation,
full-on
stakeholders.
Again
it's
really
hard
to
get
the
people
in
a
room
when
they're
all
over
committed
in
other
places.
And
lastly,
roles
of
attendees
is
sometimes
confusing,
so
somebody
could
I
could
wax
poetic
about
the
intricacies
of
an
API
but
they're,
not
necessarily
an
approver.
So
it's
an
important
piece
of
information
to
have
that
viewpoint,
but
it
may
not
necessarily
solve
the
decision
or
or
finalize
it
so
again,
knowing
what
anybody's
role
is
is
super
important.
A
Lastly,
I
think
that
really
the
discussions
require
context
and
structure
and
one
of
the
things
I've
seen
as
things
come
to
this
to
this
meeting
and
certain
get
worked
out
in
real
time.
That's
not
really
effective,
because
there's
probably
a
lot
of
those
things
that
could
have
been
I,
D
duped
or
worked
out
ahead
of
time
on
the
mailing
list,
and
it
just
happened
to
wind
up
in
our
in
our
agenda.
A
So
one
of
the
ways
to
deal
with
that
is
to
have
more
thorough
discussion
before
things
are
brought
to
this
thing
and
to
have
the
well-defined
context
and
ask
so
that
we're
being
very
actionable
and
the
things
that
we
talked
about
a
little
quip
here
on
the
right
talks
about
how
senior
managers
say,
the
meetings
keep
them
from
completing
their
own
work
and
a
productive
and
efficient.
All
these
all
these
statistics,
I
feel
resonate
very
strongly
with
leaders
in
our
community.
A
They
were
tasked
with
a
lot
of
meetings
and
also
getting
a
lot
of
things
done
so
they're
very
disempowering
they're
not
happening
the
right
way,
so
I've
said
a
lot
of
problems
and
I'm.
Sorry
I
didn't
know,
but
it's
easy
to
harp
on
things
that
are
wrong,
but
I
think
that
we
have
some
really
powerful
compass
points
here
that
are
actually
in
our
project
values.
A
And
if
you
haven't
looked
at
our
project
values
I
highly
encourage
you
to
do
that,
something
that
it
really
spells
out
and
clear
clear
terms
what
it
is
that
we're
striving
as
a
community
to
home.
True-
and
these
are
a
few
of
those
and
I-
think
that
they're
really
appropriate
to
our
mission
in
architecture
and
so
distribution.
Obviously
it's
better
than
centralization,
because
when
you
have
centralization,
it
focuses
all
the
effort
in
one
place,
and
so
that
becomes
a
bottleneck.
It
learns
people
out
it's
destructive
to
people's
work-life
balance.
A
I
heard
somebody
refer
to
kubernetes
as
literally
their
fifth
child.
That's
not
a
good
pattern,
so
we
need
to
spread
that
out,
being
inclusive
is
really
good,
and
this
is
a
little
tricky,
because
inclusive
doesn't
necessarily
mean
that
everybody
is
making
the
decision
together.
It's
not
a
decision
by
committee.
It's
really
about
making
sure
that
everybody
feels
like
they
are
supported
in
the
right
way
by
the
right
people
at
the
right
time,
and
so
that
opens
the
door
for
all
sorts
of
people
to
be
in
various
roles.
A
A
So
this
conversation,
this
presentation,
my
my
feelings
on
this-
are
hopefully
a
recognition
that
evolution
in
this
meeting
is
also
from
pollution.
The
sig
is
important.
We
need
to
add
two
and
four,
so
we
get
into
some
of
these
values
starting
to
be
monologuing,
so
here
so
long
here
too,
and
I'll
wrap
up
soon,
but
I
wanted
to
talk
about
distribution
and
how
we
get
the
works
split
out
right
now,
we're
sort
of
acting
as
a
sort
of
centralized
gatekeeping
entity
and
that's
really
not
an
effective
way
to
scale.
A
Actually
so
then,
in
this
format,
what
we
want
to
do
is
limit
discussion
truly
managing
and
scaling
those
processes
of
our
particular
sub
projects
and
not
necessarily
the
outcomes
or
details
specific
actions.
So
what
I
say
that
is
really
that
we
really
need
to
focus
on
scaling
everything
that
everyone
in
this
room
does
every
one
of
those
colored
circles
out
to
at
least
two
or
three
people,
and
those
can
be
people
and
sayings.
Those
can
be
people
in
the
process
and
so
forth.
A
And
lastly,
this
meeting
us
getting
together
should
be
more
of
a
focus
on
reporting,
important
information,
the
community.
This
is
our
ability
to
radiate
all
the
great
work
and
all
the
things
that
are
happening
in
our
sub
projects
and
also
when
something
changes
that
is
architectural.
You
know,
there's
an
API
change
that
isn't
important
to
the
rest.
That
can
me
about
the
sort
of
calling
in
case
law,
how
we
want
to
do
things
in
the
future.
This
is
the
place
where
somebody
could
go
and
get
more
information
about
that
nest.
Subject
matter
experts
and
approvers.
A
You
have
to
have
the
respect
of
your
fellow
owners
and
it's
really
about
becoming
a
subject
matter,
expert
and
the
project
to
be
able
to
reach
that
point,
and
so
it's
important
when
you're
in
those
roles
to
make
it
clear
that,
when
you're
giving
feedback,
if
it's
binding
or
not
binding,
so,
for
example,
if
an
API
approver
says
something
about
an
API
review
that
could
be
a
binding
opinion
versus
somebody
who
is
really
just
participating
in
or
watching.
They
can
say,
I
think
this,
but
it's
not
necessarily
a
binding
decision.
A
So
when
we're
talking
about
things,
it's
important
to
keep
people's
roles
clear
so
that
we're
not
confusing
folks
in
discussions.
I
mailing
list
is
a
great
place
to
have
inclusive
discussions
because
it
doesn't
have
to
adhere
to
time
constraints.
It's
not
it's
not
necessarily
real
time,
so
it
helps
people
contribute
when
it's
most
convenient
appropriate
for
them.
And,
lastly,
a
big
part
of
our
our
job
is
to
radiate
this
information
back
to
other
non
attending
stakeholders
and
decision-makers,
and
so
that
can
be
done
on
the
mailing
list
and
hopefully
another
event.
A
Venues
like
community
meeting
and
other
sig
knees
as
well
and,
lastly,
evolution-
and
this
is
really
I
I've
kind
of
talked
about
this
a
lot,
but
we
need
to
get
new
leaders
cultivated
across
the
project
and
part
of
the
way
that
we
want
to
do
that
is
to
have
all
of
our
sub
projects,
focus
on
the
ability
to
cultivate
new
replacements,
for
the
people
who
are
leaders
and
those
sub
projects
are
architecture,
sub
projects
and
probably
a
lot
of
other
things
as
well
and
Tim.
St.
A
Clair
is
hopefully
going
to
chime
in
after
this
presentation
to
talk
about
the
ways
that
he
did,
that
in
state
cluster
or
cycle,
but
so
we
really
need
to
work
with
SIG's
on
engagement,
I
think
our
windows
kept
work
where
we
helped
guide
the
windows.
Folks
in
in
their
work
was
really
effective.
We've
done
great
106
George.
We
need
to
do
a
lot
more
of
that.
A
We
also
need
to
do
things
like
put
videos
up
and
show
how
we
do
API
reviews
and
code
reviews
so
that,
as
as
people
want
to
become
involved
in
this,
they
understand
it's
not
an
impossible
thing.
It's
just
something
that
mean
it
be
familiar
with,
and
last
we
really
need
to
prioritize
understand
them.
Unstaffed
architectural
sub
projects,
but
we
also
need
to
do
in
a
way
that
minimizes
toil
so
part
of
it
is
identifying
roles
we
need
to
fill
so
doing
leveraging
some
of
the
great
things
that,
like
cig
releases
done.
A
So
what
does
this
all
mean?
Practical
steps
is
really
just
a
look
at
our
cig
Turner
and
we
have
a
to
do
out
there.
That
is
served
and
lingering
about
how
we
manage
technically
the
cig
level
and
and
company
diversity
and
whatnot,
and
this
is
really
an
opportunity
for
us
to
finalize
the
Charter
as
it
is
and
to
say
that
concentration
of
effort
in
centralized
places
is
an
athame
to
the
risks
that
we
face
as
a
saint.
We
also
need
to
go
through
the
process
of
moving
catch
to
SiC
p.m.
A
This
is
a
way
to
do
that,
and
also
this
will
allow
us
to
have
more
focus,
reporting
back
from
the
sub
projects,
and
the
sub
projects
should
be
using
this
meeting
as
a
venue
to
say
help
and
how
people
actually
volunteer
and
help
do
that,
because
we
need
to
staff
instinctually
that
way
and
so
follow-ups,
Tim,
st.
Clair
has
volunteered
to
help
us
talk
about
how
to
run
federated.
So
projects
more
effectively
is
from
his
learnings
in
signal.
Cluster
life
cycle
and
Paris
is
kindly
offering
to
help
us.
A
Maybe
look
at
the
ways
we
might
mentor
additional
people,
so
those
are
really
concrete
steps.
Yeah
both
of
them
are
here
now
so
yeah
plants
also
glad
yeah.
Are
we
great
to
have
Q&A
there?
Last
thing
I
want
to
share?
Is
this
this
tweet,
which
was
very
timely
and
and
I?
It's
really
talking
about
Tim's
experience
with
cert
rebooting.
A
C
The
reason
I
sent
out
the
tweet
was
because
I've
been
inundated
with
post
acquisition
communication
to
the
point
where
I'm
I'm
effectively
not
effective
at
doing
some
upstream
work
currently,
but
when
I
come
back
to
it
and
I
touch
base
with
some
of
the
people
that
we
promoted
with
inside
of
the
sub
projects
that
I'm
pleasantly
happy
to
see
that,
like
the
ship's,
rolling
and
things
are
functioning
very
effectively
and
David
watt
is
also
here.
So
give
him
credit
too,
as
well,
because
he's
been
helping
out
in
cluster
API
work.
C
So
I
think
that
the
building
up
and
federating
the
work
into
responsible
parties
that
have
a
unified
vision
of
how
the
execution
can
be
done
makes
it
seamless
it
makes
it
so
that
we
can.
You
can
come
and
go
as
needed
and
be
the
arbiter
at
times
when
you
need
to,
but
don't
feel
like.
You
have
to
have
your
hand
in
the
pot
for
the
entire
cooking
process.
A
And
that's
really
great,
thank
you
so
much
and
it's
just
this
is
sort
of
the
reflective
of
the
feeling.
The
sort
of
the
right
things
happen
at
the
right
time
and
these
conversations
have
been
welling
up
in
a
lot
of
areas
of
the
project.
So
it's
nice
to
have
certain
coalescence
of
people
talking
about
this
at
the
right
time.
So
with
that
I
really
want
to
thank
everybody
for
listening.
A
Monologues
are
not
fun
to
listen
to
or
to
do,
but
at
the
end,
I
hope
that
everybody
in
this
meeting
recognizes
then
I
care
tremendously
and
deeply
and
personally
about
this
project
and
everybody's
success
and
I
can
say
confidently
that
everybody
I'm
surrounded
by
now.
It
feels
the
same.
So
we
we
really
care
and
we
want
to
find
a
ways
to
make
this
work
better
and
be
better
and
help
create
a
better
world
life
balance
for
everybody.
So
without
all
all
open-ended
questions
like
Jordan
to
actually
say
something
about
what
we're
doing.
D
The
first
is
as
we're
thinking
through
processes
and
things
like
that,
really
being
careful
not
to
be
so
aspirational
that
it
doesn't
actually
work
like
understanding
how
people
are
currently
working
with
issues
and
pull
requests
and
like
the
workflows
that
we've
been
using
for
the
past
five
years,
the
more
we
can
integrate
with
those
and
kind
of
help,
people
and
guide
those
the
better.
So
a
couple
things
that
have
happened
just
in
the
past
couple
weeks,
we
have
a
label
that
anyone
can
add
to
a
pull
request.
D
D
Here's
the
the
documentation
around
like
what
things
need
review,
what
you
should
do
before
asking
for
one
getting
input
from
the
people
who
are
responsible
for
this
area
of
the
code
and
then
here's
how
you
ask
for
a
review,
and
so
I
mean
it's
not
it's
not
rocket
science,
but
just
really
trying
to
meet
people,
contributors
and
reviewers
and
approvers,
where
they're
at
and
make
their
life
easier
as
much
as
we
can.
So
that's
just
kind
of
the
process.
D
So
there's
a
there's,
a
tracking
issue
in
the
community
Rico,
where
we're
linking
notes
that
we're
taking
as
we're
doing
these
reviews
and
the
thought
there
is
to
turn
those
notes
into
documentation.
So
the
first
step
is
kind
of
a
capturing
phase
and
then
the
second
step
will
be
documenting
and
coming
up
with
checklists
types
of
things
that
will
help
people
who
want
to
do
reviews
but
also
help
people
as
they're
making
these
changes
so
that
they
don't
have
to
wait
for
weeks
to
get
a
reviewer
to
look
at
their
pull
request.
To
tell
them.
D
A
D
We'll
see
once
it,
the
thing
is
more
lightweight.
We
are
the
more
adjustments
we
can
make
more
easily.
If
we
get
you
know
halfway
through
this
relation,
we
realize
one
aspect
of
this:
isn't
working
yeah
I
want
to
second
that
and
just
say
thanks
making
it
reasonably
approachable
means
that
I
can
actually
do
it
and
I
actually
felt
really
guilty.
When
I
did
one
review
and
I
forgot
to
fill
out
the
stream-of-consciousness
stock
along
the
way,
but
I
wouldn't
back
and
I,
did
it
retroactively?
D
Lee
and
I
will
say
that
I'm
trying
to
be
very
intentional
about
to
my
reviews,
more
so
than
I've
ever
done
before
previously
I,
just
sort
of
treated
them
like
another
Pru
and
now
I'm
trying
to
be
a
little
bit
more
thoughtful
put
aside
time
for
it,
because
these
API
reviews
sometimes
are
multi.
Our
reviews
and
working
with
a
shadow
has
actually
produced
better
reviews.
Shocking
I
know
to
all
you
a
pure
programming
believers,
but
it
has
produced
better
reviews
and
I
actually
think
that
should
be
be
standard
across
this
very
characters.
A
Yeah
I
just
had
one
point
for
people
learn
not
to
thank
me
I
reviews
and
may
not
be
aware.
Why
do
we
need
a
buck?
I,
really
somebody
changes
happening.
We
did
have
a
bot.
They
would
automatically
flag
ki
ours
to
touch
the
he
API
directories
with
API
change,
they're
about
a
hundred
and
twenty
pr's
labeled
with
that,
it's
really
hard
to
tell
which
ones
are
relevant,
which
ones
are
active,
which
ones
are
material,
API
changes,
and
things
like
that.
So
that
was
constitutions
and
just
a
follow-up
question
for
Jordan.
D
D
So
they
were
definitely
there
were
definitely
be
things
to
fold
back
into
that.
But
I
think
what
might
be
more
helpful
for
people
is
kind
of
targeted
like
what
kind
of
what
kind
of
change
are
you
doing?
Here's
here's
the
short
list
of
things
to
consider
like
targeted,
checklists
types
of
things,
I'm
still
kind
of
waiting
to
see
what
we,
what
we
gather
but
sharding.
Some
of
that
work
out.
There's
a
tracking
issue
in
the
community.
There's
a
tracking
issue
for
the
types
of
checklist
I'm
going
to
have
and
so
kind
of
assigning
those
out.
D
E
I
can
cover
that
on
the
next
meeting
from
like
a
tactical
perspective,
but
I
just
wanted
to
hit
on
the
fact
that
videos
are
key
here
for
scaling
purposes,
I
mean,
of
course,
one
one
minute
Orion
and
things
like
that
is
still
a
good
way
to
go.
But
from
if
we're
looking
at
scale
rapidly,
videos
are
key.
The
two
videos
that
I
included
in
chat
with
some
contributors
summit.
It
was
the
API
code
review,
daniel,
did
and
also
the
code
base
for
that
stuff
into
both
rave
reviews
from
contributors,
both
hi
hi
mark
sessions.
E
E
A
So
there's
this.
Thank
you.
Paris
is
gonna,
come
to
the
next
meeting,
where
she's
going
to
share
more
about
what
contributor
experiencing
has
been
volunteers
that
are
relevant
to
us.
Reducing
toil
through
automation,
mentoring,
defining
roles,
don't
make
it
easier
for
people
to
understand
what
one
needs
to
eat
on
and
stuff
up
to
those
roles.
A
So
there's
not
quite
enough
time
left
today
for
both
QA
and
for
that
discussions.
Don't
we
reschedule
that
for
the
next
time,
but
the
general
idea
here
is
and
we've
been
kind
of
barely
treading
water,
and
this
thing
for
a
long
time
now
we
really
need
to
focus
on
sustainability
and
making
sure
that
we
use
our
time
effectively.
F
F
A
C
There
is
a
separate
point,
but
I
can't
I
also
kind
of
wanted
to
respond
to
that
I
think
the
whole
purpose
of
federating
a
group.
Is
you
empower
that
subgroup
if
there
are
provers
or
that
that
subgroup
that
it's
their
responsibility?
If
you
get
a
bunch
of
minus
ones,
the
six
responsibility
is
to
be
the
arbiter
of
last
choice.
Right
this.
C
This
would
be
the
venue
for
the
-1
resolution
if
the
sub-project
can't
come
to
consensus,
but
if
the
sub-project
can
come
to
consensus,
that's
totally
in
their
Dominion
and
they
should
have
final
say
on
those
things
right,
so
I
think
in
power.
It's
all
about
empowerment
in
Federation.
If
you
empower
this
group
to
make
the
choices,
then
it's
their
choices
to
make
it's
their
responsibility,
to
give
you
feedback
from
time
to
time.
G
So
I'll
jump
in
now,
I
think
it's
handed
off
to
me.
This
is
actually
where
I
look
for
the
kept
process
to
do
a
lot
of
that
work,
as
Jace
noted
so
well
when
we're
in
these
meetings,
it's
not
a
great
time
to
reflect
and
think
about
it
and
give
feedback,
and
it
doesn't
really
work
for
time
zones
and
everyone's
busy
schedules.
G
But
if
we
get
everything
to
go
through
a
cap
and
then
we
review
those
caps,
then
that
can
be
a
place
to
to
to
say
no
or
to
say
instead
of
just
saying:
no,
because
yes
no
gets
into
preferences
too.
This
doesn't
work
with
the
patterns
of
the
project.
This
doesn't
look
where
we're
going.
If
this
is
going
to
happen,
maybe
it's
more
appropriate.
Also
we're
here
or
here's
a
different
way,
and
then
we
can
collect
those
pieces
of
information
and
document
them.
So
then
people
can
self
assess
this
from
themselves.
G
They
can
say:
oh
this,
isn't
the
right
pattern.
We
should
do
it
this
way.
You
know,
as
we
do
more
and
more
with
CRTs,
we
can
say
in
these
cases
C
or
DS
is
the
right
example
or
operators
or
the
right
of
you
know,
controllers
or
the
right
examples.
Things
like
this
and
that
kind
of
helps
federate
things
while
giving
people
time
to
review.
G
Although
right
now,
I
think
the
one
thing
that
Jay
showed
earlier
was
there
aren't
folks
going
after
that
whole
cup
thing,
which
is
one
of
the
things
that
I
think
in
order
to
do
this
well,
will
have
to
do
here
in
the
short-term,
and
so
that's
one
of
the
things
I'll
probably
go
after
to
try
to
help
just
get
the
ball
moving
in
on
that.
So
we
can
build
that
constructive
process
around
this
of
guidance.
G
H
H
Here,
I
mean
I
personally
would
be
happy
to
try
and
contribute,
but
it's
very
difficult
to
find
the
list
of
things
that
need
to
be
done,
and
it's
very
difficult,
and
it's
also,
you
know
sometimes
useful
to
have
someone
chase
you
up
and
say
you
know
your
point
person
for
this
thing.
Could
you
please
have
it
ready
for
presentation
at
the
meeting
next
week
or
whatever
I
wonder
to
what
extent
that
would
you
know,
help
us
to
grow?
H
The
group
of
people
and
I
know
there's
a
there's,
a
skill
problem
as
well,
which
is
you
know
not
everybody
has
skills
to
do
everything
but
I
think
there's
a
project
management
function
that
can
be
useful
here
and
and
things
like
load
balancing.
You
know
noticing
that
this
is
the
list
of
things
we
have
to
do,
and
you
know
Brian
signed
up
for
all
of
them.
Can
we
do
better?
Can
I
go
to
Brian
and
say?
H
That's
being
you
know
happening
somewhere
else,
you're,
just
not
aware
of
it
any
of
those
potential
problems,
whereas
if
you
have
a
I'll
call
them
a
project
manager
making
sure
that
we
know
what
has
to
be
done,
who's
doing
it
and
make
sure
that
the
stuff
gets
done.
I
think
that'll
go
a
long
way
towards
addressing
some
of
these
needs.
A
A
E
A
Like
we're
just
not
even
successfully
treading
water,
in
terms
of
focusing
like
I,
said,
focusing
on
sustainability
and
effectiveness
and
efficiency
or
just
sig
is
kind
of
party
number
one
in
terms
of
our
sub
projects,
and
you
have
two
sub
projects
that
are
really
critical
and
I
have
some
people
working
on
them,
obviously
not
enough
people,
so
I
suggest
we
just
double
down
on
those
sub
projects.
First,
before
trying
to
broaden
to
other
things,
but
the
API
review
and
influence
are
the
two.
There
is
a
conformance
working
group
next
week.
A
I
was
gonna,
send
out
you
know
about,
but
yeah.
We
need
to
figure
out
how
to
ski
ramp
more
people
up
on
these
efforts
and
get
project
management
under
control
for
those
two
areas,
and
you
can
think
about
expanding
to
you
know
other
artificial
documentation
and
things
like
that
which
is
honestly
harder
to
fan
out
anyway.
So.
F
F
Clair
is
advocating
for
that
worked
so
well
for
him.
Another
thought
here
is
I
just
wanted
to
say,
I
think
Tim.
This
has
been
doing
a
great
job
of
exemplifying
some
of
the
ideals
I
would
look
to
for
making
this
group
productive.
Where
he's
just
kind
of
showed
up
and
pushed
work
forward
only
escalating
when
it
comes
time
to
make
a
decision,
so
I
think
of
the
little
bits
like
you
know,
kick
a
log
and
and
forking
the
ammo
library
and
starting
to
ask
around
about.
Do
we
really
need
dr.
shim?
F
Do
you
really
need
this
containerized
flag?
Things
of
that
nature?
I
do
feel
like
he's
actually
trying
to
push
forward
on
making
the
sub-projects
move
forward.
But
what
really
needs
to
happen
is
more
people
need
to
show
up
and
start
doing
the
work
that
way,
I
mean
that's
how
I
trust
people
is
to
see
that
they
actually
say.
They're
gonna
do
the
work,
and
then
they
do
the
work
and
the
work
gets
done.
F
That
sounds
great,
but
at
the
same
time
we're
saying
writing
down
Docs
and
clarifying
case
law
is
really
the
only
way
we
do
scale
so
like
I.
Don't
have
any
answer
to
that
question
I,
just
like
incentives
need
to
be
aligned,
whether
that
is
us
putting
down
some
kind
of
big
nope.
Sorry,
big
nope
in
front
of
companies
that
just
want
to
like
have
people
show
up
and
do
work
without
actually
doing
some
of
the
hard
work
necessary
to
scale
the
project
or
whether
we
try
and
find
a
way
to
make
it
valuable
or
rewarding.
B
So
one
thing
that
I'm
seeing
here
as
well
as
in
the
case
in
front
group,
is
there
are
people
who
are
interested
in
doing
stuff,
but
then
they
don't
know
where,
to
start
and
from
our
side
the
people
were
talking
in
meetings
like
this.
Is
we
don't
know
who
they
are
and
what
they
are
capable
of?
So
there
is
like
a
disconnect
here.
Unless
we
get
to
know
the
people
and
and
get
get
to
know
away
and
trust
them,
then
we
are
not
going
to
be
able
to
help
them.
B
You
know
help
mentor
them
right,
so
I
think
going
back
to
the
good
first
issue,
kind
of
things
that
we
said
everybody
has
to
do
in
KK,
right
and
other
repository.
So
it
can.
We
define
some
some
chunks
of
work
that
is
bite-sized
where
we
we
can,
let
people
lose
and
they
can
prove
that
you
know
they're
capable
of
taking
care
of
those
kinds
of
things,
and
you
know
that
is
another
thing
that
I
think
we
need
to
start
doing
here.
I
wanted
to
talk
about
staffing,
the
other
projects,
but
then
Ryan
already
covered
that.
A
C
C
We
do
and
we've
documented
that
what
we
do
and
how
to
make
it
easier
and
it
helps
for
people
who
are
new
to
the
project
to
understand
where
to
engage,
because
we
do
have
help
on
it
and
good
first
issues
and
as
part
of
every
single
meeting,
we
actually
go
through
and
triage
a
inbound
so
because
we
have
a
unified
set
of
practices
that
we
do
and
it's
not
totally
unified.
It's
very
loose
coupling
right,
but
you
know
David
can
speak
to
it.
C
We've
been
doing
it
on
a
cluster
API,
a
little
American
speak
to
what
we've
been
doing
on
committee
M
and
it
allows
folks
who
are
new
contributors
to
get
involved
in,
engage
because
look
at
this
call.
There
are
32
people
in
this
call
that
is
crazy.
Number
of
people
for
a
single
phone
call
I'm
sure
they're
their
employers
would
allow
them
to
engage
if
they
knew
exactly
where
and
how
and
why.
G
I
was
actually
gonna
say
over
in
cig
apps.
We
needed
to
do
something
with
cron
jobs,
and
so
we
put
something
up
on
the
Help
Wanted
board.
George
pointed
me
to
the
right
place
in
the
community
meeting.
We
brought
up
a
hey.
This
is
a
place.
You
can
contribute,
and
next
thing
you
know
we
had
four
or
five
people
showing
up
and
well
we
had
to
figure
out
was
okay.
We
just
had
all
these
people
showing
up
ready
to
go.
What
do
we
do
with
them?
How
do
we
help
them
on
board?
G
They
were
ready
and
raring
to
go
and
jump
right
in
we
just
weren't
used
to
bringing
people
in
and
so
I
think,
wherever
we
jump
in
and
start
with
these
things.
If
we
think
through
how
we
can
bring
people
on
board
and
just
kind
of
prepare
for
that
initial
onboarding
and
then
we
go
out
and
just
start
broadly
asking
whether
it's
here
or
elsewhere,
we'll
be
surprised
at
the
people
who
might
show
up
and
start
doing
some
of
these
things.
G
A
I'm
going
to
add
an
addendum
to
that,
the
best
way
to
engage
somebody
in
the
community
is
to
actually
have
a
conversation.
A
lot
of
this
is
really
true
of
a
lot
of
under
represented
people
as
well
that
they,
they
will
not
feel
qualified
to
jump
in
and
do
anything
unnecessarily
because
of
imposters
a
lot
of
alteration.
But
if
you
have
a
conversation
with
people
who
don't
feel
like
they
can
do
it
and
you
tell
them
that
they
can,
and
you
believe,
with
them
and
you're
willing
to
take
that
time
and
build
that
relationship.
You.
A
The
way
in
which
that
can
flourish
and
cause
people
to
get
involved
so
every
if
everybody,
the
thirty-two
people
on
this
call,
had
one
person
in
mind
that
they
wanted
to
bring
this
effort
and
help
them
get
on
board
and
do
it
that
would
that
would
immediately
triple
the
amount
of
people
we
have
working
on
things.
So
we,
you
know,
remember
it's
really
conversations
where
community
we
we're
people
that
you
know
have
lives
outside
of
this
and
everything
that's
going
on,
but
the
heart
of
it.
A
We
all
care
so
I
think
that
touching
people
around
you
in
your
circle
and
having
those
discussions
and
explaining
why
this
is
so
important
can
help
elevate
that
work
in
their
sphere
as
well,
yeah.
Maybe
next
time
we
should
actually
reserve
some
time
for
intros
or
something
yeah
stay.
Some
people
to
introduce
themselves
say
who
they
are
and
why
they're
here.
A
E
I
just
want
to
reiterate
one
more
time:
people
of
different
learning,
styles
I
think
the
people
that
are
on
this
call
and
all
of
our
current
contributors
today
are
here
because
clearly
we
all
have
a
similar
learning
style
and
we
flourish
in
ambiguous
environments
and
that's
great
for
us,
but
the
next
wave
of
contributors
and
people
that
are
going
to
help
us
might
not
learn
in
that
fashion
and
so
that
that's
why
I
think
we
need
to
take
new
approaches
and
those
approaches
we'll
discuss
in
the
next
meeting.
That's
great.
A
B
A
E
A
More
completely
answer
the
questions
in
the
next
step
slide
indicated
change
in
mo,
where
we're
going
to
take
specific
technical
questions
and
direct
them
to
the
mailing
lists
and
have
discussions
there,
and
these
meetings
were
going
to
focus
on
the
big
organizational
and
scaling
and
sustainability
effort.
How
do
we
eat?
What
is
the
work
that
needs
to
be
done?
Are
we
going
to
organize
that?
How
we're
going
to
do
the
strap
people?
Are
we
going
to
do
project
management?
A
H
A
I
Is
quick
so
on
the
agenda
I'd
seen
that
Dems
had
made
note
of
the
containerized
cubelet
discussion?
I
was
not
sure
if,
since
I
had
already
act,
the
PR
to
mark
the
behavior
deprecated.
If
the
reason
it
was
raised
here
was
there
were
concerns,
but
I
feel
like
many
of
the
same
burnout
issues
that
are
being
reflected
here,
also
automatic
of
why
we
would
be
looking
to
deprecate
certain
capabilities
in
cig
note,
and
so
if
there
was
not
a
real
knack
on
it,
I
did
not
want
to
have
to
go
and
leave
her.
I
A
F
C
Well
night
was
we
get
asked
continually
just
so
it's
clear
that,
because
we
get
asked
continually,
what's
the
state
of
self
hosting
and
we've
continually
stated
that
it's
an
ace
and
Alf
agreed
state
feature,
but
we
don't.
We
don't
make
progress
any
of
this,
so
we'd
have
to
make
an
official
policy
to
say
you
know
it's
totally
deprecated
we're
not
going
to
do
this
as
long
as
we
have
a
statement,
but
you
care
as
long
as
I
can
point
to
a
decision
in
the
statement.