►
From YouTube: Steering Comittee 20181024
Description
Notes: http://bit.ly/k8s-steering-wd
Chat transcript (times may be off):
00:03:33 Joe Beda: Gah -- zoom seems screwed up on Mojave. Can't get to unmute controls.
00:03:40 Clayton Coleman: Derek is in the room with me
00:03:41 Joe Beda: I may rejoin
00:03:58 Clayton Coleman: sig-node is derek
00:06:04 Aaron of SIG Beard: Brian says he’s going to show up, working on it
00:20:28 Joe Beda: But perhaps the vast majority is because of hte CLA?
00:21:27 Timothy St. Clair: Agreed
00:26:08 Aaron of SIG Beard: Dims then tim
00:26:44 Aaron of SIG Beard: Brendan after dims
00:27:16 Aaron of SIG Beard: Brian after Brendan (assumgin Brendan still wants to go)
00:27:52 Aaron of SIG Beard: I’m curious what empower means here, like what’s the authority that is missing
00:35:01 briangrant: https://github.com/kubernetes/community/blob/master/community-membership.md
00:36:14 briangrant: Or role board
00:41:29 Aaron of SIG Beard: Joe than I think I heard brandon?
00:43:41 Joe Beda: Another kick to contribX
00:43:42 Joe Beda: :/
00:44:30 Aaron of SIG Beard: https://github.com/kubernetes/community/pull/2830
00:44:39 Timothy St. Clair: Yes, +1 from me
A
E
A
B
B
Before
so,
I
will
share
my
screen,
so
we're
all
looking
at
the
same
thing,
all
right.
So
in
the
blocked
waiting
column.
There
was
a
question
about
sunset
procedure.
For
here
the
zoom
bar
always
blocks
tabs.
What,
if
I
open
them
up?
So
there
was
a
question
when
it
came
to
George
and
Paris
are
working
on
the
process
to
sunset
SIG's
in
working
groups.
They
realized
that
this
file,
basically
should
probably
just
be
renamed
like
sig
lifecycle.
B
So
it's
just
the
logistics
and
administrivia
of
how
you
clean
up
a
sig,
but
then
we
kind
of
realized
this
file
is
also
called
sig
govern
it's
not
unlike
the
state
governance
template
that
will
link
to,
and
if
you
look
at
the
top
here,
there's
a
bunch
of
stuff
here
that
sounds
an
awful
lot
like
signals
and
responsibilities
that
I
feel
like
we
should
move
into
the
state
governance
charter,
so
I
or
somebody
can
take
an
action
item.
I.
B
B
Yeah,
so
that's
that's.
What
I
had
linked
to
I?
Just
put
it
on
our
block
call
and
to
talk
about
that
on
the
formalizing
sub-projects
issue.
There
basically
seems
to
be
some
consternation
around
the
fact
that
right
now,
sub
projects
are
more
or
less
just
a
collection
of
goods.
Lord.
This
is
a
trail
of
things
to
follow.
B
Some
projects
are
just
a
collection
of
owners
files
and
some
people
get
confused
by
this,
especially
those
sakes
that
are
more
or
less
just
process
or
non
code
related,
so
things
like
sig
TM,
sometimes
on
sub
projects
and
sake
release
in
some
of
our
projects.
Sig
contributor
experience
the
stuff
that
I've
said
in
the
past
is
that,
even
if
you
are
a
process
only
sub
project,
you
should
still
probably
document
what
your
process
is
put.
B
That
document
someplace
and
then
drop
an
owner's
file
in
that,
but
I
get
that
as
human
beings,
people
are
not
really
enjoying
the
whole
owners
file
thing
because
they
they
can't
like
it
looks
terrible.
Basically,
if
I
were
to
go
through,
let's
use
the
sub
projects
first,
for
my
sake
as
an
example
like
this
is
not
super
clear
to
people
and
it's
also
not
clear
who
the
actual
human
beings
are
and
be
to
contact.
You
have
to
actually
click
through
to
these
files,
and
it's
like
it's
not
super
friendly.
B
So
Steven
augustus
had
something
out
to
try
and
change
it
from
owners
files
to
actual
human
beings.
I'm
pushing
back
on
this
because
I
think
it
should
it's.
It's
going
to
fall
even
more
out
of
date
than
it's
already
likely
to
fall
out
of
date
with
the
current
owners
files.
There
needs
to
be
somebody
owning
the
automation,
I
thought
it
was
going
to
be
me,
but
I
really
haven't
had
the
bandwidth
to
do
this.
So
I'm
happy
to
farm
it
out
to
somebody
else
or
I.
Let
Steven
continue
and
unblock
him.
B
I
had
thought
that
this
maybe
could
be
a
topic
for
discussion
at
sync
architecture.
So
I
guess
one
thing
I'm
asking
the
steering
committee
here
is:
if
they're
comfortable
delegating
this
discussion
to
sake
architecture,
while
icing
architecture.
That
seems
like
the
wrong
thing
to
me,
because
I
feel
like
it's
about
the
organization
of
code
within
the
project,
but
maybe
this
is
the
appropriate
forum
to
have
the
discussion.
I.
Don't
think
it's
really
actionable
right
now.
F
B
F
B
B
Documenting
what
work
groups
working
groups
are
and
how
to
form
in
disband
them.
I
I
think
we're,
like
almost
done
here.
I
think
Phil
had
a
follow
up
PR.
If
I
remember
right,
there
was
a
question
from
seed
contributor
experienced
they'd
really
like
to
see
us
formally
specify
that
working
groups
have
to
be
tied
to
SIG's
and
that
we
should
call
out
those
six
in
SIG's
EML,
so
that
we
can
generate
generate
this
as
part
of
a
working
groups
documentation.
B
So
if
a
working
group
happens,
spam
seek
release
and
say
testing
we,
we
know
that
as
a
community,
and
it
would
be
easier
for
us
right
now
sake.
Sponsorship
is
called
out
as
part
of
the
working
group
formation
process,
so
I
feel
like
it's
not
super
controversial.
If
we
formalize
this
people
agree
the.
B
D
B
Can
we
can
get
to
that
when
we
get
to
get
to
back,
but
well
so
just
the
tangent
on
that
was
I.
Those
of
us
in
the
Kate's
and
for
working
group
felt
like
it
was
really
important
to
be
very
formal
and
precise.
Since
this
is
about
running
project
infrastructure,
we
wanted
to
make
sure
there
were
clear
things
like
how
decisions
are
made,
how
members
are
voted
in,
how
we
do
leadership
changes
and
such
and
a
lot
of
the
language
in
the
state.
Governance
template
already
had
all
of
that
information
in
there.
B
So
we
felt
like
it
was
easy
to
just
reuse
that
and
then
overlay
the
specific
changes
for
us
as
a
working
group,
I'm
happy
to
like
copy/paste
all
of
that
directly
into
our
readme.
But
since
I
had
just
written
up
a
charter
for
state
testing,
that's
the
pattern
I
followed
for
the
working
group.
You
can
review
that.
Let
me
get
there
so.
G
B
B
On
the
charters,
Mehta
issue,
I
think
we
had
I
think
y'all
had
a
great
last
week
to
go
through
and
notify
a
bunch
of
SIG's.
That
charters
are
due,
so
I
got
sick,
testings
charter
merch
through
Thank,
You,
Brandon
and
James
for
the
review
Tim
and
I
reviewed
the
Sig
multi
cluster
charter.
It
looks
super
specific
and
super
light,
like
it
just
calls
a
couple
repost,
but
it's
good
enough
for
now.
B
Sega
AWS
had
a
charter
out
there
I
think,
even
though
I'm
not
an
official
reviewer
on
this,
it
mostly
looked
good
to
me,
except
at
the
end,
it
seems
like
they
copy
pasted
a
bunch
of
roles
and
organization
management
stuff
instead
of
overlaying
their
specific
changes.
Brandon
and
I
have
some
concerns
on
this
Joe.
B
C
B
B
So
maybe,
as
a
follow-up
I
can
check
in
to
see
where
we
are
at
with
the
six
that
are
completely
missing
charters
next
week,
they're
also
a
couple
six
that
have
charters
in
process
but
aren't
quite
ready
for
review
and
then
there's
six
you've
got
charters
merged
in,
but
they
didn't
really
go
through
the
whole
template
that
we
have
now.
So
you
contributor
experience
was
one
of
those
six,
so
they're
working
through
that
at
the
moment.
B
G
F
B
All
right:
well,
let's
follow
up
on
all
of
this
by
next
week
and
take
a
look
Jim's.
Maybe
you
and
I
can
see
if
the
if
merging
stake,
OpenStack
in
a
safe
cloud
provider
is
something
that's
covered
in
these
Doc's
that
are
being
worked
on
here
as
far
as
logistics.
So
we
can
get
any
pick,
those
okay
insuring
all
communities,
repos
follow
the
same
contributing
structure,
I'm
just
going
to
put
that
into
you
block
right
now,
because
there's
some
disagreement
about
whether
or
not
we
are
polluting
rooting
with
too
many
files.
B
D
G
The
meta
issue
behind
that
was
we
were
talking
about
was:
do
we
need
to
do
better
in
terms
of
getting
people
who
are
occasional
contributors?
You
know
bring
them
more
into
the
fold
so
to
say,
then,
right
now
we
are
organized
towards
companies
with
full-time
employees
who
and
their
day
job
is
Cuban
redress
right.
So.
F
My
general
experience
with
this
is
that
we
need
more
productive
contributors,
not
more
interviewers
right,
like
it's.
A
software
project,
mythical
man-month
still
applies
people
who
only
contribute
on
weekends,
are
gonna,
have
trouble,
keeping
their
pr's
up-to-date
and
getting
them
merged.
That's
been
a
real
struggle
in
the
past.
You
know
it's
just
until
the
project
slows
down
enough
or
you
know
if
they're,
just
like
fixing
very
well
contained
bugs
it's
not
gonna,
be
very
friendly
to
occasional
contributors.
Regardless
of
changes
we
make
to
DCO
versus
CLA.
So.
B
On
so
I,
just
don't
think
we
really
have
the
right
people
here
to
talk
about
this.
If
this
is
about
getting
the
lawyer
perspective,
we
should
have
the
lawyer
perspective.
I
feel,
like
the
contributor
perspective
has
been
hashed
out
on
an
issue.
That's
not
here
and
I
think
there
are
more
productive
use
of
our
time.
We
get
back
to
this.
If
we
finish
the
rest
of
our
lists,
yeah.
C
But
I
do
want
to
address
what
Brian
just
said.
There
I
think
that
for
parts
of
kubernetes,
like
API
machinery
and
stuff,
like
that
I
think
you're,
probably
right,
but
there
are
a
ton
of
other
sub
projects
and
ancillary
projects
that
are
much
more
amenable
to
folks.
Actually,
you
know
spending
time
on
without
it
being
a
full-time
job.
So
we
could
that's
a
narrow
view,
so
I
just
want
to
make
sure,
because
this
is
a
philosophical
thing
Aaron
in
terms
of
like
sort
of
like
who
do
we
want
like
who's
the
community?
C
F
B
G
B
D
D
H
Tim's
then,
you
and
I
have
a
discussion
on
this
issue
and
talking
about
trying
to
force
pull
a
bandaid
on
OpenStack
and
then
realize
that
wasn't
going
to
be
possible
to
to
stake,
storage
needs,
so
I
guess
Tim
I'm,
not
sure,
like
it's
even
fully
understood
everything
that
needed
to
be
done
in
order
to
make
it
happen.
In
some
cases
we
tried
to
go,
make
it
happen
and
only
realize,
after
the
fact
that
they
were
still
yet
more
work
and
I
had
discovered
to
be
done.
D
E
H
H
D
G
So
sig
OpenStack
is
the
one
that
is
closest
to
getting
out
the
latest
stumbling
block.
That
we
found
was
that
we
can't
drop
support
for
the
existing
cinder
volumes
API
and
we
need
to
support
it
somehow
and
so
I
was
able
to
flip
the
tables
and
say:
okay,
the
code
for
OpenStack
is
going
to
go
into
the
repository
and
will
render
the
cloud
provider
OpenStack
repository
back
into
the
main
KK
repository
just
enough
to
support
the
cinder
use
case.
So
I'm
able
to
do
that.
G
E
F
You
know
that
was
simpler
because
it
was
effectively
only
had
a
couple
of
six
that
were
stakeholders
and
we
announced
when
we
were
going
to
deprecated
it,
and
we
made
it
happen.
You
know
our
our
team
specifically
at
Google's,
and
that
has
invested
quite
a
bit
and
the
cloud
provider
extraction
you
know,
so
we
do
want
to
to
make
it
happen
and
unblock
the
cloud
providers
that
have
not
been
able
to
add
their
support.
At
you
know,
that's
the
top
priority
getting
the
rest
of
the
provider.
F
F
G
B
Yeah
I
was
just
kind
of
unclear
when
Tim
started
talking
about
empowering
like
what
what
Authority
is
lacking,
that
people
don't
already
have.
It
seems
as
though
your
broader
point
is
that
cloud
provider
extraction
isn't
happening
fast
enough.
How
can
we
make
that
happen,
and
so,
like
one
way
is,
perhaps
people
are
blocked
and
they
need
empowerment
to
unblock
or
push
through
things?
E
We
can't
force
people
to
write
code
is
basically
the
problem
and,
and
so
I
think
we
have
to
realize
that
we
have
to
structure
our
architectural
decisions
towards
the
notion
that
we
can't
force
people
to
write
code
as
opposed
to
in
a
more
single
corporation
setting
where
you
potentially
could
force
people
to
write
code.
I
think
that's
the
fundamental
problem.
G
Just
observing
the
people
who
are
doing
the
work
Brendon,
it's
not
that
they
lack
it's
just
that
people
are.
There
are
many
cloud
products
and
we
meet
cloud
provider.
The
people
are
a
different
stage
of
experimenting
with
the
different
things
that
are
possible.
So
it's
just
getting
consensus
there
in
a
single
direction,
like
I,
am
pushing
in
one
direction
and
then
Andrew
is
pushing
in
another
direction.
So
Andrew
is
pushing
in
the
direction
where
we
chop
off.
G
You
know
things
into
staging
and
then
slowly
over
a
period
of
time
we
will
get
things
out
and
I
was
like
okay,
just
rip
everything
out
and
render
main
KK
and
use
it,
even
if
there
is
a
recursive
dependency
between
the
KK
and
the
cloud
provider.
So
you
know
just
getting
everybody
in
sync
in
the
same
direction
is
the
issue
and
not
that
we
are
lacking
top-level
approvers.
That
kind
of
stuff
is
not
a
problem
right
now,.
G
So
it's
not
removal
per
se,
it's
more
like
getting
them
to
assign
other
people
who
are
currently
not
in
owners
as
reviewers
and
approvers,
and
maybe
take
them
out
themselves.
If
they
are
not,
you
know
doing
active
reviews,
so
the
first
step
in
that
was
trying
to
figure
out
who's
active
and
who's.
Not
active
and
I
came
up
with
excel
sheet.
G
Where
I
highlighted
like
ten
people,
I
say:
okay,
can
we
see
you
know
so
the
basic
idea
was
to
go
through
the
owners
files
and
see
how
many
files
have
the
names
of
the
people
and
then
look
at
the
dev
stats
data
to
see
how
many
of
them
are
active,
actually
active
in
the
last
year
or
so,
and
then
next
step
is
I.
Don't
want
to
go
as
an
individual
to
ask
them.
G
I
want
like
steering
committee
or
contra,
backs
to
approach
these
people,
and
and
do
it
that
way,
and
it's
not
like
okay
you're,
not
doing
anything.
Can
you
just
get
out?
It's.
That's,
not
the
idea,
it's
more
to
encourage
them
to
get
more
people
into
the
owners
files
rather
than
taking
people
out.
Erin
yeah.
B
My
my
opinion
is:
this
would
be
a
great
thing
for
contributor
experience
to
do
I
feel
like
they
own
policy
around
owner's
files.
I
feel
like
they
own
the
best
messaging
to
the
community.
It's
kind
of
unclear
to
me
how
much
they
own
the
individual
roles
within
the
contributor,
ladder-like
reviewer
versus
approver,
but
I
do
think.
Culturally
as
a
project.
We
should
be
incentivizing
everybody
to
help
pull
people
up
the
ladder
behind
them.
F
B
C
Mean
I
love,
you
know.
The
idea
of
kicking
this
stuff
off
to
stuff
like
contra
backs
but
contributes,
is
essentially
unfunded
from
sort
of
a
cool
ability
point
of
view
right.
They,
you
know,
there's
a
ton
of
stuff
that
I
think
they'd
love
to
build
tools
around
across
a
whole
bunch
of
stuff,
but
that
the
the
set
of
folks
that
are
heavily
involved
there
and
just
are
not
set
up
to
do
to
do
that.
C
Where
do
we
want
automation,
let's
find
the
priorities
and
then
maybe
we
can,
you
know,
do
Help,
Wanted
or
or
perhaps
you
know
appeal
to
the
CNC
F
to
actually
help
us
get
some
contractors
to
actually
help
write
some
of
this
tool
ability
I
do
think
that
that's
something
that
could
unlock
a
bunch
of
stuff-
and
this
is
just
one
of
many
things
on
that
list-
that
I
think
is
pretty
critical,
so
I
just
would
love
to
know
what
folks
think
about
that
idea.
I
think.
B
Contributor
experience
does
have
people
who
are
cave
of
working
on
this.
It's
a
question
of
bandwidth
like
we're
already
using
a
tool
to
automate
the
management
of
github
membership
now,
and
we
plan
on
expanding
that
to
the
automation
of
all
github
teams
and
then
expanding
that
to
teams
and
hackles,
and
then
you
could
probably
see
something
that
kind
of
marries
those
with
the
concept
of
owner's
files,
so
that
maybe
owner's
files
can
reference
github
teams
instead
of
people
directly
and
that
all
gets
unified
a
little
bit.
B
C
Ok,
ok,
so
not
saying
it's
totally,
they
don't
have
the
skill
set,
but
like
the
amount
of
need
that
we
need
around
automation,
we've
been
saying
this
for
years
now
at
this
point
far
outstrips
the
capacity
of
that
cig,
and
I
don't
think
that
you
know.
One
of
the
things
that
I
don't
think
we
are
is
is
super
disciplined
about
actually
prioritizing
where
the
most
critical
things
are
across
tooling.
In
that
particular
cig
I.
C
I'm,
not
you
know
and
again,
I
think
it's
the
appropriate
saying
for
it.
I
just
think
that,
like
you
know,
it's
very
easy
for
us
to
say
hey,
there
should
be
a
contrived
X
thing
that
doesn't
mean
that
it'll
get
done.
I
think
we
should
face
that
when,
when
things
like
this
come
up
in
the
industry,
ok.
B
That's
the
point
I'm
trying
to
make
I
guess
I
like
saying
that
it
should
get
done
generally.
An
open
source
means
you're
gonna
commit
the
resources
to
do
it,
and
so
I
feel
like
DIMMs
has
started
that
effort
by
committing
himself
to
it.
Personally,
if
you'd
like
to
have
George
commit
the
CNC
F
to
do
it
through
contractors
that
would
be
that'd
be
welcomed,
but
I'm
sure,
like
state
testing,
would
probably
have
some
concerns
as
well
to
make
sure
that
that
functions
appropriately
with
all
the
automation
that
we've
crafted
around
that
right.
G
Now
we
were
not
able
to
do
this
before
so
that
that's
a
good
news
there,
plus
they
Joe.
We
did
a
few
more
things
in
their
stats
like
we,
since
we
identified
that
India
and
China
are
you
know
we
are
trying
to
get
attract
more
people
from
there,
so
what
we
did
was
in
some
of
the
graphs.
We
asked
the
CNC,
if
contractor,
to
add
the
country
field.
So
you
know
you
could
see
from
China
how
many
people
were
doing
what
kind
of
contributions
so
that
helped,
you
know,
push
some
more
stuff
from
there.
G
F
Anyway,
I
know
how
the
existing
owners
fathers
were
created,
so
I
can
talk.
To
that
I
mean
it
was
a
combination.
There
was
an
initial
automated
pass
to
try
to
distill
who
was
contributing
and
who
was
reviewing
to
individual
files
and
that
created
auto-generated
a
bunch
of
files,
and
then
there
was
some
manual
fixed
up.
Indeed
you
being
an
elimination
of
noise
for
people
who
just
did
one-off
PRS
and
things
like
that
but
effectively.
F
You
know
other
obvious
people
who
shouldn't
be
there
and
things
like
that,
but
where
we
never
really
literally
got
the
sub-project
owners
to
sort
of
take
over
the
maintenance
of
those
files,
so
I
think
from
my
perspective,
having
like
one
top-level
file
per
sub-projects
and
then
say
well,
the
sub-project
thinks
they
need
more.
They
can.
They
can
create
more
and
manage.
Those
makes
a
lot
of
sense
and
centralizing
again.
The
set
of
approvers
for
the
sub-project
I
think
would
would
simplify
a
lot.
C
Think
the
just
to
double
down
on
what
Brian
just
said,
I
think
there's
there's
a
difference
between
numbers
of
owner
owner
files
on
the
number
of
owner
files,
with
unique
sort
of
like
random.
Ask
grab
bags
of
people
right
I
think
we
have
a
lot
of
owners
files
with
grab
bags
of
people
if
we
actually
had
a
more
disciplined
way
to
actually
identify
that
hey.
This
is
part
of
the
sub
project.
Here
are
the
people
who
are
approvers
on
the
sub
project.
C
B
I
guess
that's
been
part
of
the
push
to
make
sure
that
every
sync
has
all
of
their
sub
projects
enumerated
through
hunters
files.
I've
been
able
to
automate
that
front
like
to
ensure
that
every
repo
is
covered,
but
I
don't
really
know
how
you
can
even
automate
that
on,
like
subdirectories
of
kaykai
love.
What.
C
I
would
what
I
would
do
is
I
would
say
we
want
to
minimize
the
number
of
owner
files
that
have
individuals
named
and
don't
have
teams
names,
because
if
you're
naming
a
team,
then
you're
actually
managing
this
stuff
in
bulk
and
then
we
can
actually
use
those
teams
as
keys
for
sub
projects,
I
mean
like
even
extending
the
do.
We
have
sub
project
as
an
it
as
a
separate
field
and
owners
I
know
we
had
talked
about
that.
Did
that
ever
happen?
C
B
A
B
Okay,
like
I,
think
we
collectively
agree
that
there
should
be
better
policies
for
owner
files
than
there
are
wreck.
Anybody
here
wants
to
take
an
AI
to
actually
write
those
down.
Then
maybe,
as
a
next
step,
we
can
figure
out
how
to
best,
implement
automation
for
those
who
wear
the
appropriate
staffing
before
that
could
come
from.
It
is,
unfortunately,
not
something
I
personally
have
the
bandwidth
for.
B
So
the
last
topic
I
had
on
the
agenda
was,
according
to
our
wonderful
new
documented
working
group
process.
In
order
for
me
to
create
a
working
group,
I
need
to
get
approval
from
chairs
from
all
of
the
involved.
Sakes
and
I
need
a
majority
vote
from
the
steering
committee,
so
I
sent
an
email
to
the
steering
lists.
Thinking
was
a
Monday
this
week
with
the
Charter.
B
So
the
only
like
objection,
I've
heard
thus
far,
was
Tim
pointing
out
that
yeah.
It's
weird,
that
a
working
group
has
a
charter.
Thus
far
no
working
groups
have
had
charters
or
aren't
required
to
and
like
I
said,
I
tried
to.
We.
We
wanted
to
be
really
specific
and
formal,
because
we
feel
like
it's
important,
to
get
this
stuff
right
in
the,
in
the
same
way
that
the
product
security
team
is
trying
to
be
very
diligent
about.
You
know
who
has
this
level
of
authority?
B
So,
for
example,
although
right
now
the
majority
of
people
showing
up
to
this
working
group
are
from
one
company,
you
would
really
like
to
live
in
a
world
where
it's
more
than
one
company
and
in
fact,
that
it's
held
to
the
same
majority
representation
rules
that
the
product
security
team
steering
committee,
a
code
of
conduct
committee
and
other
groups
are
held
to.
So
we
would
look
to
like
bring
people
from
other
companies
on.
F
B
The
thought
was,
we
wanted
to
start
as
a
working
group
and
if
it
makes
sense
to
have
all
of
this
stuff
happening
under
the
umbrella
of
one
sig
on
an
ongoing
basis,
we
can
convert
to
a
sig
in
the
way
that
sig
cloud
provider
did.
However,
we
have
also
explicitly
called
out
which
SIG's
seem
to
be
responsible
or
direct
consumers
of
the
different
pieces
of
infrastructure,
and
it
could
also
be
that
we
decide
to
ultimately
disband
and
leave
ownership
of
those
sub
projects
to
the
individual
SIG's.
B
So
we
called
out
that,
like
GCR
and
GCB,
for
example,
are
primarily
the
responsibility
of
sake.
Release,
whereas
like
gke
and
the
prow
stuff
is
probably
the
responsibility
of
state
testing.
So
if
we
ultimately
find,
as
we
work
through
all
of
this-
that
we
can't
untangle
and
everything
clearly
into
specific
SIG's,
then
we
can
revisit
whether
this
should
turn
into
a
sink
and
extract
ownership
of
that
code.
To
this
C
plus.
G
Some
of
the
stuff
we
can
ship
off
the
CNC.
Also
they
let
them
manage.
You
know
access
and
whatever
else
is
needed,
so
hopefully
we
don't
have
to
become
a
sec.
That
would
be
the
good
news,
and
hopefully
we
will
stick
to
the
you
know
at
least
six
months
or
nine
months,
and
you
should
be
done
by
that
time.
B
Yeah
this
was
another
area,
much
like
Tim's
concerns
over,
say
cloud
provider
not
having
it's
out
of
tree
extraction
happening
fast
enough
and
Jenna's
concerns
that
were
not
automating.
The
things
that
we
want
to
automate
fast
enough.
We
have
concerns
that
we're
not
going
to
extract
this
project
infrastructure
from
Google's
hands
fast
enough,
because
there
are
not
enough
people
not
from
Google
showing
up
to
take
this
work
on,
and
so,
although
we
aspire
to
have
this
done
in
six
months,
it
could
take
longer
if
we
don't
have
more
resources
being
committed
to
this
effort.
B
E
B
So,
like
the
product
security
team
is
really
the
only
other
model
I
have
to
go
on
for
that
and
as
far
as
I
know,
they're,
not
really
a
formal
working
group
or
or
entity.
In
that
way,
you
know
we
would
be
like
if
you
are
that
central
authority
for
some
level
of
credentials,
we'd
be
happy
to
delegate
to
you
for
that.
B
And
I
think
we
agree
with
that
that
that
again,
is
why
I
tried
to
at
least
draft
us
to
draft
up
the
Charter.
That
was
more
formal,
sounding
I.
Don't
think
we
want
to
do
that's
too
much
friction
until
we
actually
have
traction,
but
you
know
we
we
are
happy
to
introduce
whatever
level
of
formalism
is
required
to
does
the
steering
committee
agree.
This
is
an
appropriate
level
of
formalism
for
now
and
can
I
move
forward
with
working
group
creation,
or
are
there
any
objections
here,
I.
F
E
F
B
B
Call
out
in
our
charter
that
our
sole
purpose
is
the
extraction
of
infrastructure
to
the
C
and
C
F,
and
we
intend
to
disband
when
that's
done,
like
we're
responsible
for
creating
the
processes
along
the
way
that
may
sure
that
it
is
going
to
be
taken
care
of
when
it
is
when
it
is
extracted.
But
we
don't
intend
that
to
be
a
long-lived
effort
right.
G
Just
as
an
example,
one
of
the
items
that
we
need
to
work
on
is
get
GC.
Our
repository,
where
folks,
outside
of
Google
can
push
stuff
to
it
and
have
enough,
and
eventually
it
should
end
up
with
sig
release,
and
you
know
not
with
our
team,
then
vini
yeah.
So
so
and
then
the
other
example
is
the
apt
and
yum
repositories
need
to
be
extracted
out
from
where
they
are
now
and
they
need
to
go
to
sig
release
as
well.
G
So
we
rely
on
people
who
are
already
members
of
these
other
groups,
other
SIG's
as
part
of
this
working
group
to
actually
do
the
work
and
the
only
other
thing
that
we
had
was
do.
We
need
a
git
repository
and
then
we
said
we're
going
to
use
the
kits
dot.
Io
I
repository
well
for
now,
and
if
you
need
anything
more,
then
we
will
work
with
one
of
the
existing
SIG's
and
get
a
repository
that
we
can
use.
So
that
was
the
only
other
thing
that
we
could
think
of.
F
F
Sig
like
from
the
proposed
charter
I
think,
is
likely
to
engender
confusion.
If
there
are
parts
of
this
that
we
don't
need
like
sub
project
creation
or
or
whatnot,
if
we
can
just
call
those
from
the
document,
I
think
that
would
be.
That
would
be
good.
Like
other
working
groups,
you
know
if
they're
gonna,
if
something
needs
to
be
designed
and
proposed,
that
would
go
through
the
ordinary
kept
process
and
whoever
proposed
the
cap
would
be
driving
it.
F
So
you
know,
does
the
whole
effort
do
we
need
to
specify
details
in
this
document
or
sub
projects?
Or
things
like
that,
and
you
know,
I
wanted
to
I
was
hoping
that
we
would
keep
working
groups
more
lightweight
as
these
forms
for
collaboration
and
to
the
degree
that
it
looks
more
like
a
sick,
then
I
think.
G
F
A
B
F
So
what
I'm
wondering
I
guess
a
couple
of
things?
One
is
if
we
need
policies
about
level
of
trust
occur
on
these
roles
permanently,
not
just
through
the
duration
of
working
group,
the
working
group,
maybe
that
needs
to
go
somewhere
else
or
maybe
we
do
need
a
committee
more
like
the
security
effort
to
own
these
things.