►
From YouTube: Steering Committee 20180926
Description
Chat transcript (times may be off):
00:30:22 Michelle Noorali: nicely stated Clayton
00:34:46 briangrant: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#sig-repositories
00:35:33 Michelle Noorali: Joe next
00:36:00 Phillip Wittrock: Hand
00:36:10 Timothy St. Clair: did you know there is a raise hand feature ;-)
00:36:24 Phillip Wittrock: I am so bad at zoom
00:36:42 Aaron of SIG Beard: yes but do you see me raising my hand right now
00:36:45 briangrant: The hand-raise feature is not effective
00:37:31 Clayton Coleman: Where is it
00:37:38 Aaron of SIG Beard: participants window
00:37:49 briangrant: I can only see about 4 people at a time
00:37:51 Clayton Coleman: O. M. G.
00:37:56 Quinton Hoole: If a sig/approvers allows code to merge into their code base, they need to be accountable for that. If they don’t want to be accountable, they should not approve the merge of the code.
00:39:52 Michelle Noorali: Clayton then Brendan
00:42:50 Michelle Noorali: Brian then Joe
00:43:55 Michelle Noorali: Joe then quinton
00:44:00 Joe Beda: (thanks for playing traffic cop Michelle!)
00:44:04 Michelle Noorali: my pleasure
00:45:18 Michelle Noorali: Quinton then brendan
00:46:14 Aaron of SIG Beard: I don’t understand what’s driven us to kill nearly 45min on this topic
00:46:32 Michelle Noorali: +1
00:46:53 Aaron of SIG Beard: I have a concrete question related to this I’d like answered but it’s unclear to me whether we’ll get there today
00:47:50 Aaron of SIG Beard: Do we call the PR premature and go back to iterating on google doc with new owners other than Jaice?
00:48:02 Michelle Noorali: Phil next
00:48:19 Joe Beda: I missed the start -- what PR?
00:48:27 Michelle Noorali: https://github.com/kubernetes/community/pull/2702
00:49:30 Michelle Noorali: Phil then we should wrap up this discussion
00:50:16 Quinton Hoole: +1 to what Brandan said.
00:50:22 Quinton Hoole: Brendan!
00:53:00 Clayton Coleman: Is Michelle hiding in a cave?
00:53:09 Aaron of SIG Beard: Big storm rolling through?
00:53:12 Clayton Coleman: is this a steering committee horror movie?
00:53:29 Clayton Coleman: The pull request is coming from INSIDE THE HOUSE!!!
00:53:30 Aaron of SIG Beard: The working groups: this time it’s serious
00:53:48 Michelle Noorali: lol
00:54:32 Aaron of SIG Beard: https://github.com/kubernetes/community/issues/2715
C
B
A
B
E
E
E
E
A
C
E
F
C
The
past,
when
anybody
tries
to
impose
some
new
process
or
rule
or
gate
on
other
contributors
in
in
the
project,
there
is
a
range
of
responses
from
push
back
to
ignoring
it
and
doing
their
own
thing
anyway,
and
we
would
just
need
to
make
sure
that,
if
they're
either
of
one
of
those
things
happen,
that
we
really
backup
that
they
have
the
authority
to
establish
whatever
policy
is
necessary
to
ensure
that
features
being
added
to
communities
have
high-quality
documentation.
For
example,.
C
F
C
Feel
more
empowered
than
other
people,
and
you
know
this
is
definitely
something
we've
expressed.
That
we
want
to
do
is
to
delegate
to
the
groups
that
we
believe
should
have
the
authority
because
they
have
the
domaine
knowledge
so
yeah,
this
I'm,
not
sure
I
mean
we
could
either
wait
and
see,
or
we
can
explicitly
tell
them
that
in
advance
that
they
are
empowered
and
we
expect
them
escalate
its.
Then
you
know
what.
A
B
Typically,
though,
the
problem
is
awareness
that
they
have
these
powers,
like
you,
have
to
say
it
like
30
times
in
a
community
forum
in
order
for
it
to
kind
of
need
to
get
registered.
I
I
don't
have
a
good
answer
for
this,
of
how
you
disseminate
information
so
that
it
becomes
clear
about
what
rights
and
rules
and
responsibilities
people
have.
It
seems,
like
you,
just
have
to
regurgitate
it
over
and
over
again
yeah.
C
F
Other
places,
but
when
I
think
it's
up
to
the
SIG's
to
do
that
communication
and
say
these
are
here's
our
Charter.
This
is
what
we're
doing.
We
have
been
granted
authority
to.
You
know
manage
this
part
of
the
process
and
if
someone
kicks
up
with
us
and
says
how
on
earth
can
you
have
that
authority,
then
I
don't
think
it's
our
job
to
do
that?
I.
C
I
agree
that
should
be
the
case,
but
the
only
there
haven't
been
very
many
horizontals
where
that
has
been
established.
The
past,
like
the
release
team
I,
think
people
understand,
has
certain
powers
but,
for
example,
with
the
features
process,
some
people
felt
you
know
entitled
to
to
bypass
that
or
to
quibble
with
the
criteria
for
what
should
be
a
features.
What
should
not
mature
or
similarly
for
testing
when
owners
were
signed.
You
know
people
didn't
feel
like
it
was
their
responsibility
to
make
the
test
pass.
C
A
Was
just
not
to
beat
the
dead
horse,
but
I
feel,
like
we
have
said
this
repeatedly.
I.
Think
one
way
of
doing
this
more
organically
is
to
make
sure
they're
steering
committee
members
who
are
active
participants
in
all
six.
That's
the
codify
steering
committee
liaisons
for
SIG's
into
60ml
tasks
in
the
in
progress
column,
which
I
have
still
made
zero
progress
on
whatsoever.
It
kind
of
seemed
like
that's
something
that
should
wait
until
after
the
steering
committee
elections
have
concluded
and
the
mixed.
The
steering
committee
for
next
year
has
been
announced.
A
I
think
during
the
announcement
of
those
results
would
be
a
good
time
to
mind
everybody
just
briefly
that
we
expect
you
to
come
to
us
not
for
us
to
come
to.
You
then
probably
get
a
reminder
for
those
snakes
that
haven't
filled
out
charters
to
fill
their
charters
out
was.
That
was
something
where
I
had
asked
previously.
If
we
wanted
to
ensure
that
all
six
had
their
charters
by
the
time
this
next
election
cycle
rolled
around,
so
we
could
at
least
have
gotten.
A
The
steering
committee
has
granted
SIG's
authority
over
what
they
say
they
have
authority
over
and
we're
still
incomplete
there
so
I
think
addressing
those
meta
points.
It
probably
addresses
Quinton's
concerns.
I
was
just
trying
to
drive
us
on
the
documentation
requirements
issue
if
it
sounds
like
SIG's
ox
is
taking
this
over.
If
there's
a
specific
thing,
they're
doing
that,
we
need
to
help
them
with
or
if
it's
we
can
close
cuz
sig
docks
is
taking
care
of
it.
E
E
E
F
A
A
E
A
E
A
F
A
A
E
C
E
F
I
mean
maybe
just
to
canvas.
The
script
is
the
feeling
here
that
we
would
like
to
preview
the
results
we
possibly
excluding
the
people
standing
for
election
preview,
the
results
before
the
announcement
and
do
we
want
to
do
the
announcement
or
we
happy
with
delegating
that
to
the
election
committee.
I,
don't
have
terribly
strong
feelings
either
way
and
I
had
be
comfortable,
delegating
all
of
it
to
the
election
committee,
possibly
with
a
48-hour.
F
A
Committee,
announcing
with
the
results,
is
what
we
agreed
upon
as
we
iterated
up
on
these
docks
months
ago,
but
your
your
call
this
is
the
idea,
was
the
bootstrap
committee,
where
the
people
who
announced
it
last
year
since
the
bootstrap
committee
were
in
charge
of
putting
this
whole
process
together
and
the
idea
would
be
to
have
to
you
continuing
steering
committee
members
announced
the
results
for
this
year.
Yeah.
F
Like
I
said,
I,
don't
feel
very
strongly
and
I'm
just
trying
to
get
us
out
of
critical
paths
of
as
many
things
as
possible,
and
this
seems
like
one
of
those
things
we
can
get
rid
of
I'm
happy
to
go
with
whatever
the
majority
consensus.
If
we've
already
decided
it
and
everybody's
happy
with
that,
because
yeah.
D
C
F
E
E
D
D
A
E
E
G
G
I
can
see
the
concern
that
somehow
the
output
of
such
a
group
would
be
assumed
to
be,
in
you
know,
say
in
some
way,
endorsed
by
the
communities
project
and
that
we
want
to
be
careful
about
what
is
sort
of
an
endorsed
outcome
and
so
I
I
can
see
the
subtlety
there,
but
I
feel
like
there's
a
lot
of
examples
of
things
that
have
been
done
in
the
past.
That
I,
don't
think,
could
have
become
working
groups.
I.
Think
third
party
resources
is
the
primary
one.
G
C
G
G
Think
more
importantly,
I
guess
that
what
I
would
like
to
see
is
a
home
for
projects
that
people
want
to
pursue
and
discuss
that.
Maybe
don't
have
sig
endorsement
and
I.
Think
that's
been
going
to
be
an
important
part
of
the
project.
I
thought
that
was
in
some
ways
what
working
groups
are
for.
If
we
don't
say
that
if
we
think
that
working
groups
are
sort
of
aligned
very
tightly
to
SIG's,
then
we
probably
should
have
some
other
kind
of
grouping
that
is
not
I.
C
My
question
is
that
working
groups
should
be
the
opposite
like
if
it's
actually
just
winging
the
bounds
of
a
single
sig.
It
should
just
be
a
sub
project
of
that
sig
right,
like
sig
networking
has
ingress
and
it
has
DNS
and
has
several
other
things
and
those
are
efforts,
sub
efforts
or
sub
projects
that
are
just
within
sig
network.
They
should
be
working
groups.
We
have
many
working
groups
today
that
shouldn't
be
working
groups.
They
are
just
sub
projects
or
efforts
within
SIG's.
G
That's
fine
I
I,
don't
really
it's
not
the
one
or
many.
That
is
the
issue.
It
is
the
fact
that
there's
a
lot
of
language
in
there
about
how
it
has
to
be
effectively
endorsed
and
the
output
has
to
be
endorsed
by
sig
and
things
like
that.
That
I
think
are
that
they're
unnecessary
thing
kits
unnecessary
and,
second
of
all,
I
think
it
is
overly
restrictive.
Well,.
C
G
G
Because
it's
different
right
or
an
Associated
repos
is
birds
of
a
feather
like
I.
Think,
birds
of
a
feather
is
pretty
well
aligned
with
associated
repo
and
I
think
this
is
more
like.
How
do
you
explore
something
new
that
may
or
may
not
be
successful
and
may
or
may
not
be
important
in
a
way
that
the
outcome
could,
if
it
is
about
two
important
and
useful,
could
become
part
of
your
remedies
to
such.
C
G
C
G
G
A
Right,
like
so
six
edge
Alain,
there's
a
bunch
of
projects
out
there
that
are
taking
like
forking
the
scheduler
and
coming
up
with
interesting
ideas
or
creating
new
things,
and
when
they
come
back
to
the
cig.
There's
a
lot
of
you
know
like
here's.
How
we
did
this
we'd
like
to
do
this?
Some
of
those
are
successful.
A
Some
of
those
are
not
sick
scheduling
maybe
have
a
sample
because
they're
the
also
the
project,
the
least
the
most
uncompleted
items
across
the
SIG's,
but
there
at
least
is
a
model
where
they
have
a
fairly
active
set
of
people.
Bringing
ideas
and
networking
is
a
very
interesting
one,
because
networking
there's
like
a
thousand
flowers
blooming
there
and
the
fact
that
sig
networking
doesn't
endorse
any
of
them
hasn't
even
really
been
a
problem,
but
on
the
core
projects.
I
do
think
that
Brendan's
concern
is.
A
I
A
Agree
to
disagree
I'm
going
to
explore
in
a
way
that
is
a
part
of
the
project
without
you
know,
without
being
like.
Oh,
we
can't
talk
about
that
here,
because
that's
this
other
project
like
trying
to
create
a
space
for
those
does
feel
something
and
I.
Don't
it
doesn't
feel
like
working
groups
to
me,
but,
on
the
other
hand,
like
some
of
the
more
successful
working
groups
were
that
this
was
a
very
controversial
topic
like
resource
management
was
really
controversial
and
resource
management
brought
all
the
stakeholders
together.
Found
consensus.
A
Talk
through
some
very
thorny
issues,
resolved
very
serious.
You
know
disagreements
among
googlers
and
non-googlers
and
Intel
folks
and
Red
Hatters
and
chorus
people,
so
I
do
think
that
working
group
did
has
effect,
has
been
used
effectively
to
make
contentious
ideas
possible.
That
would
not
have
been
possible,
otherwise
yeah.
G
H
G
I,
don't
I
don't
see,
working
groups
is
doing
that
right,
I
mean,
maybe
that's,
maybe
that's
a
distinction,
and
maybe
that's
what
we
want
to
make
a
distinction
between
like
working
group
versus
proposal.
Group
I,
don't
know,
but
like
agree
that
if
you're
landing
tree
code
that's
different
than
if
you're
sort
of
trying
to
come
up
with
a
concrete
position
paper
that
people
could
vote
yea
or
nay
on
effectively
right.
G
B
I,
don't
think,
there's
enough
structure
in
place.
It
doesn't
make
a
lot
of
sense
to
have
that
kind
of
hierarchy
or
structure,
because
a
lot
of
the
working
groups
are
formed
via
a
need
and
they're
informal
and
they're,
usually
safe
stakeholders
that
are
involved
are
participants
in
those
working
groups.
So
if
they
want
to,
you
know,
develop,
take
take
an
idea
and
see
it
through
to
fruition.
They're
often
involved
back
in
the
cig
to
take
a
concept
and
drive
it
home
towards
you,
know,
adoption
and
I
think
that's
fine,
but.
G
C
Why
no
I
think
this
is
a
question
of
what
is
the
whatever
in
groups
for
like
I,
feel
like
a
lot
of
this
discussion
we
had
when
we
did
repositories
proposal
and
we
you
know
we're
trying
to
cut
scope
of
the
project
and
slow
down
illusion
of
the
core
and
create
well-defined
extension
points,
and
things
like
that.
So
we
went
through
the
process
of
defining
like
what
is
in
the
core
project
who
decides
out
what
is
in
kubernetes
SIG's?
C
Who
decides
that
encouraging
more
things
to
grow
as
associated
repos
if
their
new
efforts
working
groups
I
do
view
them,
as
you
know,
creating
proposals
or
driving
consistence
or
working
across
sig,
they
don't
own
the
end
resulting
code
that
is
owned
by
the
SIG's
where
that
code
lands,
but
the
SIG's
half
didn't
long
long
term.
So
I'm
not
really
sure.
What's
being
discussed
here
says
it
seems
to
cross
a
lot
of
those
I
guess.
G
F
I
agree
with
that
Brendan
and
I'm
I'm
wondering
whether
the
solution
to
this
isn't
advising
SIG's
on
on
what
their
role
is.
I
mean
this
word
endorsement
and
approval
and
whatever
is
a
pretty
fuzzy
edge
term.
That's
endorsing
a
working
group
mean
that
we
think
this
is
a
great
idea
and
we
want
them
to
like
build
the
stuff
into
the
core,
or
does
endorsing
mean
we
think
it's
okay
to
go
and
explore
this
idea
that
may
fail
so.
A
G
J
G
A
Merging
code
in
creating
code
are
different,
like
exactly
I,
think
everybody
in
this
project,
whether
they're
in
a
sig,
whether
it's
something
cross-cutting,
should
feel
very
free
to
go,
create
very
interesting.
Cross-Cutting
ideas
and
associated
repos
is
a
good
place
for
that
stuff
to
land,
but
creating
code
and
driving
driving
ideas
to
either
a
like
anything
that
crosses
sig
boundaries
almost
certainly
is
going
to
be
something
that
you
know
what
what
forum
do
you
have
it?
Where
do
you
have
meetings?
Where
do
you
publish
your?
Where
do
you
find
another
time?
I
do
feel.
E
H
H
A
sig
is
then
signed
up
to
sort
of
own
that
code
moving
forward,
but
they
never
actually
had
any
process
of
vetting
it,
and
then
users
end
up
starting
to
take
advantage
of
it
and
depend
on
it
right,
so
I
think
getting
more
formal
around
making
sure
that
it's
something
that's
in
line
with
the
folks
who
are
sort
of
involved
and
have
shown
that
sort
of
consistency
over
time.
I
think
that's
the
thing
that
I
want
to
see
so
that
we
don't
end
up
there.
H
Somebody,
you
know
if
the
folks
that
are
part
of
a
sig
have
shown
over
time
that
they're
committed
to
that
sig
and
they
say
hey.
You
know
we
think
this
is
actually
in
scope
and
something
that's
part
of
the
skid.
The
it's
part
of
the
the
sig
then
I
think
there's
a
level
of
acceptance
there.
What
we
don't
want
and
I
think
as
we
go
through,
and
we
do
the
sub-project
assignment
exercise
that
we
did
as
we're
getting
more
formal.
H
G
I
think
the
flipside
is
we've
seen
numerous
examples
where
people
who
own
SIG's
were
just
straight-up
wrong
right
and
there's
no
forum
for
for
that
to
be
proven
out
straight
up
wrong,
as
in
that
they
technically
would
let
go
look
at
the
comments
that
people
made
on
the
third-party
resources
proposal.
So
I.
H
K
L
Hey
great
thanks,
this
is
already
been
answered
in
the
discussion,
but
how
is
a
working
group
different
than
just
a
bunch
of
people
getting
together
and
doing
it
on
their
own?
Like?
Is
there
any
special
thing
imbued
in
that
or
endorsement,
or
is
it
just?
They
get
a
slack
channel
enough
discoverability
and
6:00
a.m.
oh
I.
E
A
There
are,
for
example,
working
groups
within
the
CN
CF,
like
the
conformance
working
group,
that
tangentially
discussed
things
around
an
area
of
interest
with
kubernetes,
but
are
not
themselves
part
of
the
kubernetes
project.
I
I,
guess
I'm,
trying
to
figure
out
like
what
boogie
men
are.
Scaring
us
in
this
case
first,
is
where
we
feel
like.
We
can't
necessarily
just
iterate.
C
Claim
did
you
never
hand
up?
You
click
the
button
I.
Did
they
even
go?
First
I
just
want
to
be
clear
about
distinguishing
working
groups
versus
repos
and
sub
projects,
because
the
mixing
those
things
up
like
if
people
want
to
have
discussion
groups
and
they
want
a
place
to
get
that
in
the
calendar
so
that
people
know
there's
a
discussion
group
like
any.
We
have
lots
of
mechanisms
for
that.
You
can
get
a
slack
channel.
C
You
can
have
meetings,
it
can
be
a
sub
part
of
some
sig
like
the
cluster
API
or
whatever
it
doesn't
have
to
be
a
working
group.
It
can
just
be
a
meeting
if
we
want
to
define
the
working
groups,
our
discussion
forums
and
here's,
how
you
get
one
and
what
you
do,
and
it's
very
lightweight
I'm.
Fine
with
that
I
think
it's
totally
orthogonal
to
code,
which
you
know
Brendon
and
I,
think
he
then
wrote
the
doc
for
the
different
kinds
of
repos
and
I.
Don't
see
a
reason
to
revisit
that
necessarily
and.
A
As
long
as
you
can
find
someone
on
one
of
those
SIG's
to
say
you
know:
ok,
like
the
artifacts
of
this,
for
the
purposes
of
the
working
group
will
get
really
much
of
an
issue.
It
is
an
issue
in
the
working
group
disbands
and
the
SIG's
like
there
has
to
be
a
way
to
like
to
not
create
the
problem
of
code.
That
then
comes
back
to
the
sig.
It's
you
create
the
code
with
an
intent
and
once
the
working
group
is
done,
we
can,
you
know,
purge
it
or
move
it
into
it's.
E
G
Is
that
I'm
thinking
a
lot
about
groups
that
try
and
move
forward
ideas
and
and
reach
some
degree
of
consensus
in
conclusion
that
probably
actually
doesn't
deal
with
code,
except
for
in
a
very
prototype
a
sort
of
phase
where,
as
I
think
Ryan
is
thinking
a
lot
about
like
a
literal
like
significant
code,
land
against
inside
of
the
sig
I
I?
Don't
think
that
I
actually
don't
really
prefer
that
we
didn't
distinguish
between
them,
because
I
think
we
don't
need
like
a
giant
list
of
different
kinds
of
groups.
But
you
know
it's
okay.
G
What
I
am
deeply
concerned
about
is
that
in
a
number
of
variety,
a
number
of
examples,
I've
seen
effectively
sort
of
petty
dictators
in
projects
act
as
a
chilling
effect
on
ideas
and
people
coming
in
and
participating
in
advancing
ideas
forward
and
I
and
I
and
I.
Don't
think
we
want
that,
and
so
I
think
we
want
to
be
as
welcoming
to
people
iterating
on
things
as
we
can,
and
the
working
groups
seem
like
a
very,
very
lightweight
lightweight
way
to
do
that.
C
I'm,
just
still
really
struggling
with
the
idea
of
calling
what
we're
talking
about
working
groups,
because
I
think
is
clear
that
we're
not
really
talking
about
what
had
previously
been
known
as
working
groups
that
were
really
talking
about
sub
projects
that
will
have
code
in
some
repo
and
we
have
a
structure
around
both
those
types
of
organizations.
We
have
the
repositories
proposal
which
outlines
three
types
of
repositories,
and
you
have
some
projects
that
are
subpart
of
six
and
they
can
are
free
to
have
their
own
meeting
times
and
whatnot.
C
So
it's
a
question
of
how
do
you
get
buy-in
a
cig
to
create
a
new
sub
project
and
that's
what
we're
trying
to
formalize
as
part
of
the
charters?
If
we
think
that
what
has
been
proposed
in
the
charters
in
the
Charter
template
doesn't
work,
I
think
we
should
fix
that.
But
otherwise
it
seems
like
we're
backtracking
on
the
repositories
proposal
to
say:
look,
things
should
really
start
an
Associated
repos
and
then
they
should
get
on
to
get
pulled
in
to
kubernetes.
H
Before
yeah
I
think
you
know
if
people
are
prototyping
stuff
and
it's
not
in
a
repo
with
kubernetes
anywhere
in
the
name
or
whatever
right,
I
mean
like
that's
fine,
that's
the
Associated
repro.
You
know,
there's
no
implication
that
kubernetes
is,
is
owning
or
taking
responsibility
of
that
code
and
nobody's
gonna.
Make
that
mistake.
If
we
see
petty
dictators,
that's
the
type
of
thing
why
the
steering
committee
exists.
F
I,
just
I
think
I
want
to
pretty
much
say
what
Brendan
and
Joe
said,
but
maybe
what
I
mean
we're
already
in
this
small
group,
we
were
a
little
confused
about
what
a
working
group
is
and
what
a
sub-project
is
and
what
the
responsibilities
of
cigar
and
do
they
block
working
groups
etc,
and
so
we
can't
realistically
expect
SIG's
to
do
the
right
thing.
So
what
what
we
presumably
need
to
do
is
my
opinion
is
that
there
should
be
almost
no
reasons
why
you
block
a
working
group.
F
If
some
group
of
people
want
to
get
together
and
the
auspices
of
kubernetes
discuss
a
topic
which
I
would
argue
most
of
the
time
requires
you
to
actually
go
and
prototype
some
code.
Otherwise,
as
the
discussions
are
kind
of
vacuous,
they
should
be
allowed
to
do
that
and-
and
they
should
be
a
very
limited
number
of
reasons
why
that
should
be
disallowed
and
assuming
that's
the
case,
then
a
next
phase
would
be
like
what
happens
to
that
prototype
code.
F
How
does
it
get
into
a
part
of
actual
communities
and
that
I
think
is
the
responsibility
of
SIG's?
And
if
you
can't
get
things
to
agree
to
incorporate
your
code
into
their
pieces
of
kubernetes,
then
you're
stuck
and
then
you're
going
for
Koopa
Denny's
or
do
whatever
you
want
to
do
to
you
know,
get
that
stuff
to
work.
E
E
Think
it'd
be
really
great,
though,
to
see
kind
of
a
proposal
about
what
your
perspective
on
a
working
group
and
a
discussion
group
would
be
just
to
compare
what
the
differences
are
with
what
we
have
right
now,
because
I,
don't
think
I,
don't
see
a
lot
of
differences
and
what
we're
talking
about.
There's
like
a
few
lines
here
and
there:
okay,
so
Brendan,
you're
next
and
then
Phil
after
that
did
I
miss
anyone.
I,
don't
think
so.
Let
me
know
and
chat
if
I
did
Brendan
then
go
Brendan,
you're,
muted,.
G
G
G
All
right
so,
like
I
think
it's
it's
it's
redundant
and
destructive
to
have
not
necessary
to
start
do,
but
it's
redundant
to
have
20
different
people
go
off
and
sort
of
build
roughly
the
same
thing,
and
so
the
having
an
identified
working
group
says:
here's
the
place.
If
you
want,
if
you're
interested.
K
G
E
E
Okay,
like
you,
just
threw
out
a
radical
idea:
okay,
oh
and
I
had
a
comment
Oh.
My
only
issue
with
that
PR
is
that
it
kind
of
convolute
slike.
What
is
a
working
group
and
the
governance
of
a
working
group
and
I
know
we
want
to
make
it
lightweight
and
that's
fine.
We
can
have
lightweight
processes,
but
I
think
those
two
should
be
separate,
but
but
if
we
merged
what
Joe
has
in
his
PR,
then
that
would
be
enough.
E
C
G
E
G
I
guess
the
only
other
medical
at
a
point
that
I
had
for
the
PR
is
there
were
places
where
I
felt
like
there
were
words
used.
I
couldn't
said,
endorsed
where
the
adjudication
of
who
would
decide
if
it
was
endorsed,
was
unclear.
Alright,
so
maybe
just
something
that
says
like
you
know
how
those
things
are
either.
E
E
C
I
can
do
that
I
think
it
sounds
like
a
high
level
goal
for
working
groups.
Is
that
they're,
primarily
just
a
forum
for
collaboration
to
unblock
collaboration
and
make
work
discoverable
right?
So
we
should
try
to
focus
on
that
and
make
it
clear
about
what
other
policies
coming
play
if
they
want
to
lay
in
code
just
to
clarify.
A
Tonight,
I
apologize
for
jumping
the
queue
Michelle
I
have
a
question.
That's
tangentially
related
to
this.
So
I
want
to
see.
If
that
sounds
like
you
can
answer
the
question
or
if
I
should
just
not
ask
this
for
another
month
until
we've
gotta
come
okay,
so
there's
an
ongoing
effort
to
move
the
kubernetes
infrastructure
over
to
the
CNC
F.
You
have
a
slack
channel.
We
have
a
github
team,
we're
calling
ourselves
the
kate's
infra
team.
We
decided
to
just
go
ahead
and
move
forward
with
Brandon
and
I
as
steering
committee
representatives.
A
Who
would
take
this
to
the
steering
committee
to
formalize?
What
is
this
thing?
Do
we
call
it
a
sub
project?
Do
we
call
it
a
working
group?
Do
we
call
it
a
brand
new
sake?
Do
we
consider
it
to
be
a
team
akin
to
the
product
security
team,
so
I
have
proposed
the
idea
of
it
being
a
working
group
because
it
involves
collaboration
across
multiple
states
such
as
release
and
testing
and
contributor
experience.
A
The
difficulty
is
that
there
does
need
to
be
code
written
and
landed
as
part
of
this.
So
there
was
concern
that
federating
this
code
into
sub
projects
owned
by
those
individual
SIG's
was
seen
as
too
confusing.
I
believe
Brendan's
counterproposal
was
what,
if
we
made
it
like
a
sub
project,
just
like
a
team
I
think
actually
was
a
team.
A
A
So
presumably
the
there's
also
the
question
of
whether
or
not
this
makes
sense
as
a
kubernetes
thing
at
all.
Maybe
it
should
be
a
CNC
F
working
group,
since
this
is
about
moving
infrastructure
over
to
the
CNC
F,
but
it
does
involve
pretty
much
nothing
but
kubernetes
contributors,
I'm,
also
fine
with
us
just
rolling
forward
until
we
figure
this
process
out.
I
think
the
important
thing
is
a
that.
The
steering
committee
is
aware
that
this
exists
and
B
that
we
don't
want
to
run
like
cowboy
for
too
long.
A
A
A
G
A
C
A
So
that
was
the
other
model
I
was
thinking
is
that
was
something
that
started.
There's
a
working
group
that
then
got
promoted
into
a
sig
when
it
was
clear
it
did
have
to
phone
code,
so
I
will
take
an
action
item
to
move
forward
with
proposing
a
new
working
group
and
I
will
work
with
Phil
to
make
sure
that
I
fit
whatever
definition
and
process
he
is
putting
together.
Okay,
thank
you
for
letting
me
jump
the
queue.
E
The
only
announcement
I
have
is
that
we're
having
a
code
of
conduct
committee,
knowledge
transfer
session
on
Monday
October
1st
from
12:30
to
1:30
I,
only
invited
to
see
any
members
that
have
been
active
and
I'm
helping
the
COC,
see
form
and
get
started.
But
if
you're
someone
on
the
steering
committee
that
didn't
get
an
might
already,
please
let
me
know
and
I'd
be
happy
to
have
you
join
in
on
the
call
and
we're
just
gonna
hear
what
we
know
and
and
also
like
answer
questions
and
just
informal
discussion.
H
E
A
E
Is
better,
those
are
both
really
good
points
I've
reached
out
to
Sara
haven't
gotten
a
response
back,
but
yeah
absolutely
would
reschedule
if
she
wasn't
able
to
make
it
and
I'll
just
invite
everybody
on
the
bootstrap
committee
as
well.
I'll
just
invite
everybody,
it's
fine,
oh
and
right.
Everybody,
okay
and
that's
all
I
have
that's
all
we
have
time
for
it.
We
have
two
more
minutes,
though,
so
does
anybody
have
something
that
they
want
to
discuss
before
we
before
we
adjourn
now?