►
From YouTube: SIG Architecture 20180222
Description
A
B
A
A
Because
I
think
like,
as
we
start
to
break
down,
you
know
what
are
what
reach
our
Turing
for
the
sig
and
what
are
sub
projects
within
the
sig
I'm
sure
we're
probably
gonna,
have
some
level
of
distillation
as
in
and
reduce
some
of
the
SIG's
for
all.
We
have
and
try
to
like
coalesce
them,
underneath
one
banner
and
with
many
sub
projects,
yeah.
A
C
It
might
be
a
different
different
thing
now
the
yeah
and
then
there's
the
sprawl
around
all
the
cloud
provider
stuff
there
and
I
think
some
of
that
is
is
so
so
there's
this
cap
on
sort
of
breaking
out
the
cloud
providers
and
there's
a
PR
in
flight
right
now
from
Caleb.
That
starts
specifying
a
whole
bunch
of
new
repos
for
the
individual
cloud
providers
and
I.
Think
that
sort
of
begs
the
question
of
like
okay.
C
C
I
I
think
that
that's
a
sane
way
to
go
I
think
that
you
know
there's
just
making
that
happen.
You
have
to
have
somebody
step
up
and
sort
of
pull
people
together
and
and
start
a
form
than
the
nucleus
of
that
of
that
particular
cig.
That'll.
A
I
was
debating
whether
or
not
we
wanted
to
have
like
a
forcing
function.
I
was
going
to
talk
about
this
in
the
next
earring
committee
and
I
think
it
kind
of
it
percolates
back
to
this
was
like
we
need
to
have
the
SIG's
have
like
an
updated
charter
like
ATS
yeah,
and
that
charter
would
be
like
the
forcing
function
to
be
like
okay.
We
should
coalesce
and
reconvene
and
and
redefine
what
that
charter
is.
But
the
question
is
like
who
approves
said
Charter
is
that
cigar
no.
C
I
think
it's
got
to
be
the
steering
committee
in
consultation
with
sig
Ark
architecture,
so
I
would
say
that
it's
the
steering
committee.
This
is
my
sort
of
opinion.
It
would
be
the
steering
committee
for
sort
of
the
governance
parts
of
the
Charter,
but
in
terms
of
how
do
we
actually
sort
of
break
up
the
project
and
and
assign
you
know,
code
to
areas,
I
think
sig
architecture
consulting
on
that
makes
a
ton
of
sense,
yeah.
A
Now,
because
we
have,
we
have
so
many
SIG's
and
some
of
those
things
are
not
even
attended
right
as
much
as
they
used
to
be
I
know
there
was
a
there
was
a
whiz-bang
in
the
beginning,
but
then
it
kind
of
dissipated
and
the
question
of
what
are
they
maintaining
and
owning
has
always
been
so
distilling
that
down
so
that
way,
it's
it's
rationalized
and
people
can
have
a
way
to
figure
out,
what's
what's
actively
being
worked
on
and
maintained
and
who
it
was.
What
would
help
well.
C
I
think
you
know
one
of
the
reasons
why,
in
my
opinion,
we
got
into
the
mess
that
we're
in
now
was
because
there
was
there
was
nobody
to
definitively
say
no,
where
yes
on
things,
and
so
what
would
happen
is
and
you'll
see
this.
If
you
look
at
sort
of
how
some
of
these
SIG's
were
formed,
it
was
like
hey,
I
want
to
do
cig
XYZ,
and
then
they
send
mail
to
kubernetes
dev
and
then
it's
crickets
and
then
somebody
with
wide
range
and
commits
power
just
sort
of
makes
it
happen
right.
C
So
so
there's
no,
like
you
know
it's
it's.
It
was
all
based
on
sort
of
people
and
convincing
a
certain
person,
and-
and
sometimes
this
stuff
would
all
happen.
Sort
of
you
know
you
know
out
out
of
out
of
sight
of
sort
of
the
the
larger
community,
so
I
feel,
like
we've
at
least
moved
past
that
now,
but
there
is
that
sort
of
go
up
and
you
know
go
back
and
try
and
clean
stuff
up
yeah.
B
You
know
it's
interesting
I
before
this
during
committee
was
formed,
I
was
actually
working
on
a
governance
model
that
I
was
going
to
socialize,
but
the
steering
committee
happened
and
kind
of
obviated
some
of
it.
Essentially,
the
the
model
that
I
had
was
a
series
of
committees
that
are
the
sort
of
munch
together.
B
Aspects
like
architecture
is
one
of
them,
but
then
there's
also
like
program
management,
so
that
includes
things
like
testing,
documentation,
etc,
and
then
these
committees
would
essentially
have
power
to
create
and
destroy
six
that
are
under
their
auspices.
So
essentially,
if
you
know
like,
for
example,
the
the
program
management
committee
says,
you
know,
sick
PM
is
not
cutting
it
anymore.
B
It
slowly
attended
it
needs
to
be
disbanded,
then
they
would
have
that
power
and
and
I'm
wondering
like
if
there's
not
some
way
to
maybe
call
out
some
of
the
bits
and
pieces
of
this
governance
model
to
look
and
see
if
it
might
be
relevant
to
have
some
sort
of
cogent
way
of
creating
disbanding
SIG's
or
making
sure
that
they're
actually
meeting
their
charter.
Because
I
don't
feel
like
the
steering
committee
is
the
right
group
for
that.
I
feel
like
that's
a
little
bit
like
one
level
too
low
in
the
details.
Yeah.
C
Well,
I
mean
I
think
the
idea
was
to
you
know,
was
to
find
sort
of
groups
under
the
steering
committee
and
delegate.
You
know
powers
and
decision-making.
There.
I
think
that
the
goal
from
the
get-go
was
not
to
have
the
steering
committee
in
the
thick
of
every
discussion
and
decision.
That
was
explicitly
something
that
we
didn't
want
to
do.
C
One
of
the
things
that
I
think
we
haven't
done
a
good
job
of
is
really
you
know,
driven
home
the
the
nomenclature
between
you
know,
committee,
sig
and
working
group,
and-
and
so
you
know
just
that's
a
little
bit
of
a
little
bit
of
ass
up
and
aside
from
this,
but
in
my
mind
committee,
we
shouldn't
that
many
committees,
because
committees
have
you
know
defined
membership
and
closed-door
meetings,
and
you
know
there's
there's
a
privacy
sort
of
like
okay,
we
have
to.
We
have
to
talk
in
there.
Sort
of
I
mean
there's
a
there's.
C
B
C
It's
not
I
mean
now
it's
not
too
far
off
or
from
where
we're
at
I
think
one
of
the
things
that
we've
done
is
and
I
Anna
and
I'm,
not
sure
if
you
have
okay,
so
you
do
talk
about
sort
of
like
you
know,
consensus
I
mean
this
idea
of
you
know:
modified
lazy
consensus
for
decision-making
because,
like
like
probably
90,
95
percent
of
the
decisions
that
we
make
in
kubernetes
are
not
are
not
contentious
right.
It's
just
a
matter
of
getting
attention
and
getting
eyes
on
stuff
like
getting
this
PR
merge
to
that.
C
B
Percent
so
I
think
that
yeah,
this
is
probably
the
next,
the
next
wild
frontier
of
things
that
we're
gonna
have
to
conquer,
because
I
do
believe
at
this
point:
sig
sprawl
and
just
in
the
dis.
What
is
the
right
word
that
I
want
to
use
there?
It's
a
dis
word,
the
the
there's
too
much,
there's
too
much
granularity
and
ownership
like
there's,
it's
there's
areas
where
I
feel
like
things
are
just
not
being
looked
at
because
it's
so
just
first,
that's
the
word
well,.
C
And
I
think
you
know,
as
we
start
to
try
and
align
code
to
people
structures,
we
are
gonna,
find
that
hey.
We
have,
you
know
code
that
nobody
owns
and
and
that'll
actually
force
us
to
think
about
what
is
the
right
sig
to
own
this,
and
does
that
sig
exist
or
is
it
sort
of
a
generalization
of
a
bunch
of
stuff
we
already
have
so
I
think
those
are.
Those
are
definitely
useful
discussions
to
have
okay.
B
Well,
all
right,
well,
I,
think
we've
wandered
so
far
off
the
architecture
map.
We
should
probably
just
adjourn
but
I
think
these
are
fantastic
discussions
and
I
think
that
we
should
try
and
continue
to
find
forms
for
these,
because,
frankly,
this
is
this
is
what's
going
to
keep
this
project
healthy.
If
we
can
keep
a
good
rainy,
anon
governance,
I.
D
Had
a
quick
question:
if
everyone
has
a
minute
or
two
left
and
it's
kind
of
related
to
the
documentary
chase
about
contributors
and
it's
a
theme,
I've
seen
emerge
in
quite
a
few
other
places
where
there
is
a
an
opinion
that
that
non-technical,
non-code
contributions
are
as
valuable
or,
in
some
cases,
more
valuable
than
technical
and
code
contributions
and
I
personally
kind
of
disagree
with
that
point
of
view,
but
I'm
curious
what
other
people's
perceptions
of
that
are.
I.
A
Management
and
overhead
of
having
a
a
release
is
a
of
trying
to
coalesce.
What
is
inside,
of
a
release
is
a
non-trivial
amount
of
work
and
and
to
make
it
sane
and
rationalize
the
order
of
execution,
and
none
of
that
is
quote
a
core
technical.
It's
tough!
It's
almost
like
project
management
and
and
I
think
that's
super
invaluable
because
for
the
community,
because
it
allows
them
to
focus
on
execution
priorities
and
yeah.
D
Yeah
I
don't
disagree
with
that
and
I
guess.
In
my
mind,
the
things
that
I
think
are
valuable
are
the
other
concrete
mechanisms
by
which
we
produce
good
code
and
and
release
it
out
into
the
wild
in
a
stable
form.
So
so
that
is,
you
know,
writing
the
code
testing
the
code,
releasing
the
code
that
those
those
kind
of
things
which
I
think
are
somewhat
distinct
from
I
would
I
would
characterize
them
as
the
more
sort
of
socialized
social
stuff
which
is
yes,
stuff.
C
That
doesn't
involve
actually
getting
code
out
the
door,
so
so
I
think
the
right
way
to
maybe
you
know
and
I
responded
to
the
on
to
your
comment
on
the
doc
when,
in
my
mind,
the
right
way
to
think
about
this
is
that
you
know
ambassadors
or
advocates.
Those
are
outward
facing
right.
Those
are
people
who
are,
who
are
you
know
helping
with
the
the
larger
community
I?
Don't
think
that
that's
a
kubernetes
contributor
right,
that's
somebody
who's
helping
to
boost
the
kubernetes.
C
You
know
world
so
they're
a
booster
or
an
ambassador,
but
they're
not
actually
helping
to
move
the
project
forward.
You
know
in
terms
of
making
the
project
better
intrinsically
and-
and
you
know,
when
I
when
I
look
at
this
I
think
you
know
the
you
know
like
we
hired
George
right.
So
George
is
not
writing
code,
but
I
think
he's
definitely
a
contributor
because
he's
really
helping
to
to
sort
of
organize
and
make
stuff
happen
and
drive.
C
Meetings
and,
like
you
know,
he's
he's
sort
of
you
know:
lubricating
the
community
process
him
in
Paris
and
and
a
set
of
other
folks,
but
then
I
also
hired.
You
know
Chris
Nova
now
she
also
writes
code
and
does
stuff
like
that,
but
a
bulk
of
her
activities
is
going
out
and
talking
to
the
larger
community,
and
so
it's
an
outward
facing
role.
D
And
to
be
clear,
I'm
not
actually
disputing
that
we
have
different
kinds
of
contributors
and
that
they're
all
necessary
so
I
think
that
is
very
clear
and
I
think
they
should
all
get
recognition
for
the
contributions
they
make.
Even
if
there
are
ambassadors
and
they're,
you
know,
writing
blog
posts
or
hosting
meetups
or
whatever
that
might
involve
by
my
question,
is
more
around
I
mean
I,
guess
to
put
it
simply,
and
then
maybe
this
is
not
the
right
place
for
a
discussion,
but
I'll
finish
it
off.
D
So
I
think
if
we
had
none
of
any
of
those
things,
and
we
just
had
a
small
group
of
people
writing
code
as
I
think
it
was
largely
the
case
in
the
early
days
of
communities,
and
you
know
something
went
out
there
and
people
used
it.
We
would
still
have
a
kubernetes
I
think
if
we
just
had
all
the
other
stuff
other
than
writing
code
and
testing
it
and
releasing
it.
We
wouldn't
have
a
kubernetes
and
and
I
guess.
D
B
That
that
that
there's
two
sides
of
the
coin
I
mean
that
you
see
this
reflected
in
any
large
software
organization.
You
have
product
and
you
have
code
right,
I
mean
if
you,
if
you
just
have
people
writing
code
without
some
sort
of
guardrails
it
just
goes
squirrely
fast
or
turns
into
horrible.
You
know
legacy
monoliths
and
all
sorts
of
things
so
and
in
fact,
the
early
part
of
the
code.
B
So
I
believe
that
it's
really
it's
a
it's
a
it's,
a
partnership
between
the
functional
and
non-functional
requirements
and
that
those
those
balance
one
another
out
and
a
healthy
way.
And
yes,
actually,
if
everybody
stopped
writing
code
right
now,
we
would
still
have
our
communities
and
if
everybody
disappeared
off
the
project,
you
know
as
far
as
there
wasn't
contributing
code.
Yes,
we
would
have
a
continual
version
of
kubernetes
with
unknown
level
of
stability
or
sanity
or
etc,
etc.
B
So
those
those
things
in
my
mind,
one
does
not
obviate
the
other
they're
there
there's
a
strong
partnership
there
that
has
proven
time
beginning
to
be
valuable
and
every
software
organization
I've
worked
at.
So
what
I
would
I
think
muddies.
The
waters
is
where
you
have
people
who
are
sort
of
doing
neither
and
and
those
those
sort
of
edge
fringe
roles
are
a
little
more
complicated
to
assess
what
the
value
is
to
the
ecosystem
and
I.
B
Think
that
that's,
maybe
maybe
the
more
important
thing
and
that's
why
I
put
the
third
leg
and
of
contree
community
contributors,
because
that's
somebody
that
shows
that
that's
at
the
bottom
of
the
line.
That's
somebody
who
shows
up
attends
meetings
does
things.
Maybe
they
report
an
issue
in
every
now
and
then
but
they're
not
actively
working
for
the
betterment
of
the
ecosystem,
they're
just
participating
so.
C
Just
just
to
put
some
some,
you
know
concrete
meat
on
this.
The
reason
why
this
matters
is
that
that
you
know
the
folks
that
we
consider
to
be
contributors
of
some
stripe
will
ultimately
have
a
say
in
the
governance
of
the
project,
whether
that
be
electing
the
steering
committee
or
within
a
particular
sig
helping
to
make
decisions
within
that
sig
when,
when
things
get
contentious,
so
I
think
that's
why
this
stuff
matters
and
I
think
it's
it's
to
some
degree.
This
is
gonna
have
to
be
in
the
hands
of
the
SIG's
themselves.
C
You
know
like
if
somebody
is,
is
actively
contributing
to
the
sig.
It's
going
to
be
up
to
the
sig
to
actually
know
that.
I,
don't
think
that
our
current
process
of
having
people
send
email
to
a
list
saying
hey
I'm,
like
you
know,
want
to
be.
You
know
a
member
add
me
to
the
github
membership
I.
Don't
think
we
want
to
keep
that
centralized
long
term.
At
least
that's
that's
my
feeling
on
this.
C
The
counter-argument
here
is
that
we
don't
we
don't
want
people
to
sort
of
you
know,
throw
bodies
at
the
community
and
sort
of
you
know,
and
and
and
have
them
show
up
to
the
point
of
being
able
to
distort
the
governance
process.
You
know,
because
there
is
this
idea
of
like
and
I
am
with
Quinn
to
some
degree
like
not
not,
everybody
is
contributing
at
the
same
level,
yet
you
know
any
sort
of
like
hey.
You
know
proportional
votes
based
on
your.
D
D
C
So
I
I
say
we
we
do
need
more
people
writing
code,
but
right
now
our
current
structures
are
not
set
up
to
actually
scale
to
that
level.
I
think
I
think
our
ad
hoc
one-on-one
self-organizing
structures
are
at
their
breaking
point
with
respect
to
people
being
effective
in
terms
of
writing,
quality
software
and
so
for
us
to
actually
have
more
people
writing
code.
We
do
need
you
know,
more
organization,
more
structure,
more
communication
paths.
D
That
that's
a
good
way
of
thinking
about
it
that
be
useful
to
measure
those
things
and
see
whether
whatever
we
do,
if
the
ultimate
goal
is
to
increase
that
the
volume
and
quality
of
functionality,
I
won't
call
it
code,
because
otherwise
people
start
counting
lines
in
it.
But
you
know
that
the
technical
value
of
kubernetes,
then
then
I
guess
we
should
measure
we
should
come
up
with
some
way
of
measuring
what
it
is
and
whether
that
trajectory
goes
up
or
down.
D
As
a
result
of
you
know,
process
I
think
we've
alluded
to
the
fact
that
adding
process
can
sometimes
in
there
take
us
backwards
rather
than
forwards,
and
we're
consciously
cautious
of
that.
But
we
should
probably
try
and
figure
out
a
way
to
measure
whether
we're
heading
in
the
right
direction
or
not.
Yeah.
A
Over
the
class,
six
months
has
gone
from
I
think
it
was
700
pending
to
over
a
thousand
pending
and
the
the
approvers
the
people
who
can
actually
get
the
code
into
the
repository
that
count
has
not
increased
over
time
like
the
the
project.
Number
of
PRS
has
scaled
super
linearly
and
the
approvers
has
been
some
linear
at
best
right.
So
having
a
group
of
people
who
can
review
and
help
approve
the
process
and
to
make
it
more
smooth,
I
think
would
greatly
benefit
the
project
as
it
starts
to
scale.
C
Mean
one
other
thing
that
I'd
like
to
put
on
there
and
I've
seen
this
anecdotally.
You
know
people
being
frustrated
I,
you
know
I'm
gonna,
say
but
like
frustrated
in
terms
of
like
hey
I
wrote
a
PR.
How
can
I
get
it
reviewed?
How
can
I
get
it
in
there?
You
have
to
work
at
a
big
company
and
know
somebody
to
be
able
to
get
anything
done
in
kubernetes
right
and
you
know,
and
the
truth
of
it
is
it's
like
that's
kind
of
true
right.
I
mean
it's
like
it's
like
you
know.
C
Getting
a
PR,
reviewed
oftentimes
means
that
you
have
to
build
human
connections.
You
have
to
build
those
relationships
and
and
and
I
don't
think
ours.
Our
structure
is,
is
conducive
to
to
helping
people
build
the
relationship,
so
they
can
work
effectively
and
so
I
think
that
that's
one
of
the
things
that
that
we
need
to
do
here.
Yes,.
D
I
think
I
think
that's
a
kind
of
a
I
don't
want
to
try
go
sonic
to
everyone
who
wants
to
leave.
We
can
call
it
a
day
now,
but
but
I
think
there's
also
a
self-balancing
aspect
there.
You
know
if
a
PR
that
is
not
interesting
to
the
sig
arrives
and
it's
badly
written
chances
are
no
one's
going
to
get
excited
about,
reviewing
it
and
merging
it.
D
If
the
super
important
pyaare
arrives
and
it's
well
put
together,
I
think
it's
much
more
likely
to
get
you
know,
enthusiastic
reviewers,
getting
it
merged,
so
I
think
to
some
extent
the
symptom
of
not
getting
stuff
reviewed
and
merged,
maybe
as
much
as
symptom
are
lots
of
bad
or,
let's
put
it
this
way,
an
important
and/or
low
quality
PR
submitted
as
it
is.
You
know,
sheer
lack
and
reviewers.
We
have
tons
of
reviewers.
We
they
just
focus
on
what
they
think
to
be
the
most
important
thing
for
their
I.
Think.
A
That
I
think
there
there's
this
weird
self,
selecting
priority
right
and
I.
Think
that's
the
problem,
as
Joel
alluded
to
like
a
company
X
will
care
a
lot
about
PR
Y
and
they
will
spend
time
and
energy
reviewing
that
PR
because
it
matters
to
them
and
they
will
spend
less
time
reviewing
a
PR
that
they
might
consider
unimportant.
So
the
idea
of
self
selection,
priority
I
think
is,
is
a
problem.
B
A
That's
the
thing
it's
like
who
assigns
the
priority,
because
right
now,
some
of
the
elements
there's
a
lot
of
nepotism,
driven
PR
quid
pro
quo
and
I
think
you
we
need
to
have
a
way
of
you
know
having
a
priority
queue,
which
also
has
priority
inversion.
Just
because
a
person
submits
a
PR,
and
we
might
consider
it
unimportant
doesn't
mean
that
we
shouldn't
give
it
review
cycles
right
it
should.
It
should
have
some
level
of
priority
inversion
after
a
period
of
time
and.
C
C
The
one
issue
that
I'm
thinking
about
is
somebody
submitted
a
change
to
add
a
dependency
to
the
hypercube
container
image.
Okay,
so
so
number
one
hyper
itself
is
kind
of
a
redheaded
stepchild
that
nobody
like
claimed
ownership
with
the
packaging
and
testing
of
the
hypercube
container
image
is
yet
another
level
of
sort
of
like
no
concrete
ownership,
and
this
person
was
relying
on
that
and
and
didn't
know
who
to
talk
to
to
actually
sort
of
you
know
figure
out
like.
Is
this
a
good
idea?
C
What
do
I
do
so
they
submit
a
PR
and
it
kind
of
drops
into
the
void
and
and
and
nobody's
claiming
ownership
of
that
thing,
and
so
I
think
a
big
part
of
this
also
is.
Is
you
know
again
this?
In
my
mind,
this
comes
down
to
creating
clean
lines
of
ownership,
so
that,
when
somebody
says
hey,
I
want
to
change
X
Y
Z.
These
are
the
people
that
I
need
to
talk
to
to
do.
C
That
will
help
create
community,
create
relationships
and
and
and
and
guide
people
from
creating
crappy
PRS
that
nobody
wants
to
look
at
which
I'm
not
saying
that
this
was
the
case
here
to
creating
PRS
that
are
guided
by
best
practices
and
experience,
and
it
brings
them
into
the
community
so
that
maybe
they
can
actually
start
contributing
more
and
and,
and
you
know,
become
more
and
more
additive.
So
yeah,
that's
that's
what
I
was
thinking
about
when
I
was
saying
that
you.
B
Cool
this
is
fantastic
discussion.
Folks,
thank
you.
So
much
I'm
gonna
go
ahead
and
wrap
it.
So
we
don't
get
too
far
afield
here,
but
I
sincerely
appreciate
everybody's
time
and
have
a
great
rest
of
your
day
and
I'll
see
you
in
a
week
or
sooner
all
right.
Thanks,
Jase
have
a
good
one.
My
bet
Thanks.