►
From YouTube: Steering Committee Meeting 20180117
Description
Recording of the Steering Committee meeting. See also:
https://github.com/kubernetes/steering
Chat transcript:
00:07:23 Michelle Noorali: We definitely have it together ya’ll <3
00:07:35 Aaron Crickenberger: https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit#
00:19:28 Timothy St. Clair: Sounds like visibility and taxonomy.
00:23:05 Michelle Noorali: I have a question about the OWNERS file when we have a second
00:24:57 Aaron Crickenberger: https://docs.google.com/document/d/1FHauGII5LNVM-dZcNfzYZ-6WRs9RoPctQ4bw5dczrkk/edit#heading=h.aptlokk78hrh
00:26:01 Timothy St. Clair: I honestly think sub-projects help to further the repo effort.. It gives a home for some of the work to get out of the kubernetes org.
00:36:05 Timothy St. Clair: Don’t forget though… this is a volunteer army.
00:39:13 Michelle Noorali: Thanks Joe
00:44:03 Michelle Noorali: Was there an announcement in SIG Apps by any chance?
00:50:23 Michelle Noorali: +1
00:51:13 SIG CLI: We have 10 minutes left
00:52:07 SIG CLI: Please email the links to steering@
00:52:17 Michelle Noorali: ^ +1
00:52:26 SIG CLI: fejta-bot has made github notifications worse than useless for me again
00:52:26 Joe Beda: They are in the notes
00:52:30 Michelle Noorali: thanks
00:52:30 Joe Beda: https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit
01:01:17 Michelle Noorali: No objection from me
01:01:26 Timothy St. Clair: No objection.
A
B
C
C
Was
boasting
for
the
last
two
meetings?
I
was
posting
for
the
last
three
meetings
before
last
two
meetings
before
that,
so
we
could
probably
find
it
to
rotate
down
to
the
next
person
which,
since
we
were
going
alphabetically
by
first
game,
first
name
actually
would
be
Brendan.
Okay,
I'm
totally
open
to
somebody
just
volunteering
if
they
I.
E
C
D
D
A
Instead,
from
that
we
got
some
pretty
cool
takeaways
like
I.
Think
a
big
one
is
there's
like
a
really
big
diversity
of
needs,
where
some
sakes
are
perfectly
happy
without
additional
organizational
structure.
Another
sake
seem
to
really
want
it
once
the
eggs
already
have
a
lot
of
organizational
structure,
for
example
with
testing
there's
a
stat
are
like
we
don't
really
have
a
plan
for
keeping
and
passing
some
sakes,
have
a
uncle
rotation
and
some
things
and
manage
to
make
it
work
without
a
lot
of
structure.
A
The
next
piece
one
thing
that
came
out
of
that
was
request
to
send
something
to
the
community.
You
can
get
feedback
from
them.
Another
survey
for
the
community.
This
is
a
different
style.
It's
a
multiple
choice,
questions
which
a
lot
the
answers
to
be
aggregated
and
we
just
get
a
feeling
for
what's
important
to
people
and
not
asking
for
specifics.
A
G
G
One
pull
open
was
just
documenting
what
we
discussed
in
our
last
meeting
around
major
changes
to
charter
or
process
and
I
tried
to
write
down
what
a
lazy
consensus
approach
would
be,
which
was
nice
to
give
me
a
changes
to
governance
of
this
committee
would
have
a
PR
posted
to
the
steering
committee
repo,
a
notice
sent
out
to
the
steering
committee
mailing
lists.
If
no
objection
is
made
within
four
weeks,
it's
just
Auto
accepted.
E
G
Basically
say
that
the
wider
community
doesn't
have
a
voice
and
that
they're
going
to
vote
with
their
feet
so
I
don't
know
I,
think
if
we
send
it
to
widely
out
people
will
think
it's
going
to
be
used
more
often
than
it
is
so
I
think
we
all
agree
that
this
is
pretty
sparing
few
other
ways
and
I
have
no
problems.
Just
maybe
someone
else
can
review
what
I
wrote,
because
I'm,
not
the
best
lawyer
and
and
otherwise
I
think
it's
disgust,
yeah.
H
I
had
to
look
at
it,
your
document
looks
good
I,
don't
think
we
have
much
I
mean
if
we're
gonna
change.
The
Charter
I
think
we
should
probably
just
let
the
community,
which
is
essentially
what
this
is.
We
should
let
the
community
know
that
that's
happening
and
and
how
and
why
and
I
think
your
message
is
pretty
clear:
I,
don't
imagine
there'll
be
too
many
major
objections,
but
I
might
be
proven
wrong.
I,
don't
think.
E
H
E
Okay,
so
how
do
I
make
this
suggestion?
How
about
we,
we
add
a
ratified
on,
and
we
put
a
date
there
or
something
like
that,
and
then
we
have
everybody
on
the
steering
committee
in
github
sort
of
sign
off,
saying
plus
one
at
that
point.
We
go
ahead
and
we
merge
it
to
the
point
where
there
is
sort
of
a
paper
trail
that
we're
all
okay
with
this
and
we've
all
read
it
and
that's
something
worth
worth
calling
attention
to
it
since
when
there
is
less
compromise,
that's.
C
E
I
do
wonder
we
whine
a
little
bit,
I
mean
just
for
the
for
the
sake
of
posterity
and
the
recording
the
whole,
like
the
community
doesn't
have
a
say
in
this
I
mean
they
very
much
do
have
a
say
if,
like
there's,
a
large
outcry,
we're
going
to
listen
to
that.
It's
some,
it's
the
type
of
thing
where
we're
not
going
to
turn
a
deaf
ear
to
it
and
the
you
know
the
the
power
for
the
committee
in
general
is
going
to
be
through
cigs
and
there's
this
whole
effort.
That
was
the
last
topic
about.
D
E
C
This
is
me,
is
Brian
presence
at
all,
no
great
awesome,
so
he
did
a
nice
job
of
explaining
the
rationale
behind
all
these
things
that
he
put
forth
this
proposal
of
decoupling,
a
couple
things
and
trying
to
create
a
formal
concept
of
a
sub
project
and
then
telling
a
bunch
of
owners
files
together
everywhere.
There
are
a
lot
of
things
in
this
talk.
I
feel
like
the
most
important
thing
to
accomplish,
first
and
foremost,
is
to
add
a
formal
concept
of
a
sub-project.
C
Or
more
pointers
to
owners
falls,
so
this
captures
the
case
where
there's
like
a
single
repository,
that
is
a
sub-project,
for
example,
hell
as
owned
by
say,
gaps,
and
this
could
also
cover
the
sub-project
say
the
workloads
API,
which
is
scattered
amongst
a
bunch
of
different
sub
directories
of
kubernetes
kubernetes,
there's
a
bunch
of
other
stuff
in
this
doc.
That
I
think
makes.
C
Of
tying
things
together,
I
want
to
just
start
the
discussion
of.
Do
we
have
the
authority
to
have
a
good
list
of
what
all
the
sub
projects
are.
If
you
have
one
place
to
sort
of
have
that
discussion
and
get
that
information
before
we
start
tying
everything
back
alright,
so
going
back
to
you,
the
meeting,
that's
well
I.
D
C
One
of
some
of
the
stuff
that
might
be
missing
from
that
concept
of
a
formalized
sub-project
is
projects
also
seem
to
have
recurring
meetings.
I
know,
helm
has
its
own
meetings,
intense
attend
meetings
and
Tim.
St.
Clair
is
trying
to
set
up
sort
of
a
more
test,
centric
sub
projects
or
testing
comments,
or
something
within
to
test
some
habits
on
meeting
so
I
feel
like
we
should
have
some
level
of
metadata.
There.
I
have
a
straw
man
of
this
implementation.
It's
just
the
topic
rate
right
now.
C
D
C
E
C
D
E
E
So
if
you
want
to
make
a
change
to
a
piece
of
code,
Oh
has
it
kind
of
gone
Brian?
Is
here
sweet?
So
if
you
want
to
make
a
change
to
a
piece
of
code-
and
you
want
to
know
who
do
I
engage
with
to
do
that,
can
we
shift
that
engagement
from
being
a
person
which
becomes
a
bottleneck
and
creates
these
sort
of
like
super
users
across
the
project
that
can
skirt
around
stuff?
E
Or
do
we
shift
it
such
that
ownership
ends
up
being
this
egg
and
you're,
like
oh
I,
want
to
make
changes
to
this
code?
I
engage
with
this
SIG
and
then
there's
a
larger
community
that
you
engage
with
I
think
by
drawing
clear
lines
of
ownership.
We
change
the
the
social
construct
to
be
one
of
engaging
with
sig's
versus
engaging
with
specific
people.
E
E
That
you
have
superpowers
in
kubernetes.
You
know
who
to
talk
to
you
know
which
sings
to
go
to
you
understand
that
hey.
You
know
what
I'm
like
on
a
top
level.
Zoners
I
can
always
show
up
some
stuff
through
right,
like
you
have
those
superpowers
a
lot
of
other
folks,
don't
have
that
superpower
and
so
creating
clear
lines
of
sights
to
which
groups
to
talk
to
about
which
pieces
of
code
above
and
beyond
just
individual
changes.
I
think
makes
a
ton
of
sense.
Yeah.
D
E
Actually,
I
think
it's
the
type
of
thing
where
I'm
looking
at
code
I
want
to
make
some
changes.
Is
it
a
big
change
or
it
a
small
change
who
do
I
engage
with
who
are
gonna?
Where
am
I
gonna
find
a
mentor
to
help
me
get
this
change
through
the
first
time.
Right,
as
we
start
like
what
I'd
love
to
do
is
say,
no,
you
identified
you
wanted
to
make
a
change
in
this
piece
of
code.
E
You
can
look
it
up
the
owners
file
and
you
can
then
see
which
sig
that
belongs
to
okay,
now
send
email
to
their
mailing
list.
If
you
have
questions
or
join
their
slack
channel
or
go
to
their
meetings
and
that
that
helps
people
find
the
tribe
around
the
thing
that
they
wanna
that
they
care
about
without.
G
E
I
mean
so
some
of
this
is
comes
down
to
how
do
we
structure
and
use
owner
files
moving
for
and
I
think
this
is
going
to
be
on
a
sig
by
sig
basis,
I
think
for
a
lot
of
SIG's.
It
would
make
sense
for
the
sig
across
sort
of
large
swaths
of
the
database,
for
them
to
actually
sort
of
have
owners,
aliases
and
then
have
all
the
owner
files
point
to
that,
so
that
there's
actually
a
clear
set
of
ownership.
C
A
A
What
yeah,
right
now
there
we
have
multiple
issues
like
a
contributor
ladder
being
too
complicated,
not
having
a
clear
notion
of
tiel's
for
anything
not
having
having
this
totally
different
mechanisms
for
organizing
people
around
SIG's
and
organizing
code
and
decisions
around
code
with
the
owners
files
so
and
the
proposal
intended
to
address
those
things
to
some
degree
and
a
few
other
things
basically
by
creating
this
formal
notion
of
sub
project,
because
mini
cigs,
especially
the
larger
ones,
do
have
multiple
independent
efforts.
Sometimes
they
have
overlapping
people.
A
Sometimes
they
don't
as
I,
felt
that
it
didn't
always
make
sense,
for
example,
to
have
an
official
tech
needed
the
whole
Sigma
sig
level,
so
I
started
well.
Let's
just
we
know
what
kind
of
the
discrete
working
areas
are.
Let's
formalize
that
notion
of
sub
project.
Sometimes
we're
gonna
try
to
align
some
projects
more
with
repos,
but
the
reality
is
today.
We
have
a
lot
of
stuff
in
mono
repos,
especially
kubernetes
kubernetes,
so
it's
not
always
going
to
line
up
with
repos.
A
So,
let's
just
formalize
this
idea
of
sub
project
and
then
the
sub
projects
we
need.
People
need
to
be
able
to
find
all
the
code
and
also
if
they
find
some
piece
of
code,
they
kind
of
need
to
know.
What's
the
project
it
rolls
into
and
I
think
that
will
enable
things
like
accountability
where
we
can
create
stats
about
whether
issues
are
getting
addressed
or
whether
tests
are
failing,
or
things
like
that.
I
So
think
this,
this
helps
to
also
further
the
document
that
you
created,
because
if
you
break
out
your
sub
projects,
there's
almost
a
natural
correlation
between
many
of
the
repos
and
several
of
the
sub
projects
that
exist,
and
if
you
follow
that
sort
of
taxonomy
of
and
hierarchy,
where
would
eventually
end
up
living
allows
it.
It
becomes
a
natural
one-to-one
fit
right.
So
then,
if
we
started
shedding
the
main
kubernetes
repo,
this
taxonomy
helps
to
have
a
natural
landing
page
where
people
could
feel
like
they
understand
it.
A
For
example,
cute
proxy
right,
it's
a
sub
project
effectively
of
well,
we
can
argue
about
what
the
exact
sub
project
is.
Is
services
or
is
a
cute
proxy,
but
Q
proxy
is
part
at
least
of
a
discrete
sub
project.
That's
under
sig
networking.
It's
actually
seems
like
relatively
low
hanging
fruit
to
move
it
to
its
own
repo,
whether
that
has
benefits
one
could
debate
about,
but
just
using
it
as
an
example.
Sig
network
has
multiple
sub
projects,
services
and
queue
proxy
being
kind
of
one
that
you
could
carve
off.
A
I
use
that,
as
an
example,
I
think
it
holds
up
very
well.
I
could
go
across
the
entire
project
and
try
to
categorize
everything.
I
might
miss
a
few
things,
but
you
know
I've
done
the
thought.
I
saw
at
least
a
couple
of
times
and
I
haven't
found
any
major
problems
with
this
concept
see
gaps.
Similarly,
there
are
things
like
hell
and
workloads,
api's.
E
E
E
Think
the
discussion
in
the
comments,
at
least
my
thinking,
was
that
the
the
disbursed
owners
files
are
the
canonical
answer
for
which
source
code
and
then
we
build
tooling
that
adds
it
into
something
in
community
that
actually
brings
all
this
stuff
together
and
then,
along
with
that
tooling,
we
can
also
find
pieces
of
the
code
that
are
essentially
unclaimed
and
on
own
and
over
time
we
can
work
to
actually
reduce
the
amount
of
unknown
code.
You
know
and
and
so
I'm
sorry
Aaron
cuz.
You
spent
a
ton
of
time
pulling
this
stuff
together.
It's.
A
C
Right,
that's
what
I
was
trying
to
get
is
I.
Think
all
of
the
things
in
Brian's
dock
are
things
that
we
could
do,
but
I'm
trying
to
do
this
a
pebble
at
a
time
instead
of
a
mat
in
the
head
of
time,
and
so
the
first
pass
to
me
seemed
to
have
one
canonical
location
where
we
could
create
that
taxonomy.
It's
both
in
a
machine,
readable
format,
and
it
is
the
natural
place
that
every
person
can
use
a
member
of
the
state
goes
to
look
for
their
sakes
information
anyway.
A
C
Hang
on
ethics-
oh
let's
that
will
get
us
to
tens
thing
about
pushing
changes
down,
seems
to
be
kind
of
the
controversial
thing
in
this
project
when
it
comes
to
the
idea
of
the
enforcement
of
the
policy,
so
I
just
want
to
say:
I
just
want
to
get
some
variation
on
that
so
I'm
working
on
a
straw.
Man
for
the
proposal,
I
think
it
makes
sense
to
also
add
like
if
that
sub
project
has
additional
meeting
info
or
whatnot
that
we
make
that
filled
in
there
may
be
a
description
field.
C
I,
don't
know
elaborate
on
that
and
then
Brian.
What
I
need
from
you
is
that
taxonomy.
So
if
that's
a
separate
table
doctor,
if
that's
everything
around
the
full
request
or
whatever
makes
sense,
and
then
I
need
to
make
sure
that
this
is
shopped
in
front
of
the
community
right.
So
whether
that's
me
just
walking
through
this,
whether
it's
a
kubernetes
staff
meal,
I,
don't
know
but
I.
This
can't
be
a
volatile
sort
of
tool.
E
I
think
the
saying
that
hey,
you
can
optionally
now
tag
these
sub
projects
and
they'll
actually
show
up
and
they'll
be
a
way
to
actually
see
it
is
more
of
an
opt-in
thing,
that's
something
that
we
can
do
a
software
all
out
on
and
then
we
can
sort
of
socialize
that
over
time,
I
think
you
know.
This
leads
in
the
next
discussion.
Any
time
where
we
change
the
day-to-day
process
of
how
how
a
repo
or
a
cig
works.
C
C
C
So,
let's
merge
them
into
one
role:
let's
call
it
owner
right
now:
maintainer
is
denoted
by
presence
and
the
team
called
foo
maintainer
z',
which
gives
you
direct
right
access
to
that
repo.
The
owner
is
denoted
by
presence
in
an
owner's
file
with
hash
tag.
Donor.
Next
to
your
name,
I
think
we
need
to
merge.
Those
two
I
would
like
Brian
to
take
the
lead
on
pushing
that.
F
G
A
So
I
would
actually
like
to
move
to
a
mechanism
of
specifying
it
that
looks
exactly
like
approvers
and
reviewers,
which
is
an
owner's
list
in
the
owners
file,
top-level
owners
file
for
some
leaf,
subtree
other
sub
project,
and
that's
an
addition
to
adding
this
up
the
information
about
which
sub
project
the
owners
file
corresponds
to.
We
can.
H
A
Over
time
like
whether
the
lists
are
unified
or
spread
out
and
multiple
owners
files
or
whatever
I,
don't
care
about
that
as
much
right
now,
it's
somewhat
dispersed,
so
it
would
start
where
we
are,
but
just
add
it
there
side
by
side
wiki
with
the
kind
of
top-level
approvers
for
that
sub
projects
there,
just
because
of
the
volume
of
github
pull
requests,
there's
pressure
to
add
approvers
that
are
broader
than
the
set
of
actual
leads
and
right
now.
The
situation
is
that
it's
implicit
about
who
among
the
approvers,
are
the
actual
deciders
right.
A
So
I
want
to
make
that
explicit
and
formalized.
So
we
can
have
you
know
if
there's
an
important
design
proposal
or
whatever
for
a
sub-project.
The
owners
can
decide
who
to
delegate
approval
of
that
of
that
cap
or
design
proposal
to
you,
just
as
an
example,
responsibility
and
authority
of
an
owner.
Once
we
have
that
I,
don't
think
there
is
a
need
for
maintainer
x',
especially
as
we
move
to
more
tiny
scope.
Tree
pose
and
I
want
to
decouple
github
permissions
from
the
community
ladder.
E
A
E
I
think
it's
a
very
subtle
thing
from
from
the
point
of
view
of
github
permissions,
that
doesn't
mean
anything.
It's
it's
more
of
a
social
construct,
I
think
as
we
look
at-
and
this
is
something
I
think
so
I
agree
with
the
goal
and
I
think
it's
a
good
way
of
saying
it
that
we
own
online
sort
of
like,
like
code
structure
with
people
structure
right.
E
E
But
I
also
think
that
there's
the
idea
of
that
within
a
cig
or
a
sub-project
there's
going
to
be
different
hats,
different
roles
that
people
can
fill
owner
or
tech
lead
is
an
all-encompassing
thing
and
I
think
that
there
might
be,
depending
on
the
cig,
depending
on
the
sub-project.
There
might
be
roles
that
don't
fit
neatly
into
that.
One
description.
F
Thanks
yeah
I
was
debating
whether
to
raise
my
hand
on
that
on
this
particular
topic,
because
I
don't
want
to
do
rail.
So
let
me
know
if
this
is
a
derail
in
conversation,
but
we've
got
a
we've
got
to
know
about
our
job
of
communicating
out
to
repo
maintainer,
Xand
or
owners
or
whoever,
but
the
changes
that
were
making
and
there's
not
really
a
good
way
to
do
that.
F
Currently,
because
we
don't
have
like
mailing
lists
associated
with
maintainer
zand
owners,
and
so
I
was
wondering
if
we've
considered
adding
emails
to,
in
addition
to
github
IDs
to
the
owner,
what
whatever
our
names
are
in
the
owners
file.
So
we
can
automate
me
creating
those
and
maintaining
those
mailing
lists
and
communicating
changes.
E
A
C
A
I
C
So
in
terms
of
and
attempting
to
map
the
organization
that
we
have
to
date
code,
one
of
the
things
I
was
trying
to
do
was
update
the
owners
alias
file.
Gonna
keep
in
the
repo,
as
I
touched
it
to
include
the
list
of
so
let's
say
the
recos
called
foo
I
tried
to
add
food
admins
and
food
containers
as
English's
as
a
human
being
pretending,
as
though
some
day
in
the
future,
we
could
sink
from
those
github
teams
down
to
those
files
or
vice
versa,
and
then
I
gave
both
of
those
teams.
C
C
A
I
Canarian
is
out
to
the
broader
org
right
and
what
are
the
boundary
lines
by
which
we
do
this
right.
Anything
in
the
credits
org
makes
perfect
sense
of
fair
game,
but
we
haven't
sucked
out
what
exactly
will
live
in
the
kubernetes
org,
so
I
think
like
waiting
until
we've
done
the
taxonomy
and
then
splitting,
and
then
defining
policy
and
strategy
for
how
we
do
want
to
do.
It
makes
a
lot
of
sense,
because
that
way
we
can,
you
know
we
can
develop
a
way
to
communicate.
I
So
that
way,
there
isn't
this
weird
problem
that
occurs
where
it's
a
surprise
to
folks
right
or
it
feels
like
we're
forcing
I
think
once
we've
trimmed
the
kubernetes
org
I
think
that's
like
a
first
step,
what's
inside
the
governor's
org
and
then
then
being
mindful
of
how
we
do
our
rolling
strategy,
which
I'm
totally
open
to
any
interpretation
on
and
how
people
think
is
the
best
way
to
go
forwards.
So.
E
Let
me
restate
that,
and
you
can
tell
me
if
I
got
it
or
not,
because
I
just
want
to
make
sure
I
heard
it
right.
So
I
think
what
you're
saying
is:
let's
decide
sort
of
what
our
end
goal
is
and
then
figure
out
the
right
way
to
actually
sort
of
stage
that
out
and
get
understanding.
So
so
we
actually
sort
of
put
a
stake
in
the
ground
of
like
when
everything
is
done.
Things
should
look
like
X
and
then
you
know
and
then
give
give
people
sort
of
that.
E
A
C
Coming
and
asking
us
about
it,
and
then
I
was
choosing
single
person's
to
repost
such
as
ours
and
the
features
we
both
and
the
sick
release
repo
and
the
tracks
repo.
So
like
people
who
were
familiar
with
film
would
say:
apps,
like
I've,
already
experienced
what
owners
can
do
for
them.
I,
never
like
developed
a
phased
rollout
plan.
I,
never
brought
me
announced
this
I
never
said
this.
Is
it
we're
doing
this
going
forward?
C
It
was
purely
like
still
attempting
to
continue
the
canary
process
so
I
totally
like
mayor
Copa
for
not
doing
a
formal
thing.
I
think
they're
people
with
a
lot
of
history
with
this
project
who
have
gotten
used
to
just
being
able
to
roll
something
out
to
maintain
agility
and
innovation,
and
that's
not
necessarily
the
world
we
operate
in,
but
I
want
to
be
careful
that
we
don't
have
every
automation,
related
change
that
could
potentially
affect.
I
That's
the
reason
for
doing
the
shedding
of
the
repose
first.
If
it's,
if
the
policy
is
maintained
within
the
org,
what
happens
outside
of
the
inside
of
the
sinc
structure?
That's
completely
up
to
them,
like
policy
should
be
enforced
in
the
mean
org.
That
makes
perfect
sense,
but
once
you
get
outside
of
that
domain,
that's
up
to
other
folks
to
decide.
So
that
way
they
can
dictate
and
define
their
own
policies
right.
D
D
As
an
example
says,
you
know
what
we
don't
want,
your
top-down
stuff.
We
want
to
do
our
own
thing,
then
they
become
an
Associated
repo
and
and
that's
the
right
blend
for
them,
right
and
and
so
I
think.
That's
I
think
that
trying
to
apply
the
process
uniformly
across
all
these
different
projects
when
they
are
clearly
different
projects
that
have
different
aesthetics
and
different
desires
is
going
to
lead
to
this
kind
of
heartburn
and
that's
why
splitting
it
up
by
association
versus
core
versus
sig
was
the
right.
First
move.
C
F
Think
in
this
instance,
I
was
a
bit
of
a
communication
issue
too.
From
what
I
understand
some
of
the
processes
were
just
destructive,
and
it's
not
the
first
time
that
you
know
BOTS
have
been
turned
on,
and
things
have
been
changed
in
the
home
repo
and
so
first
it
was
mainly
on
communication
concern
too,
and
so
for
what
it
is
right
now.
I
think
we
should
also
be
announcing
these
things,
and
the
signaling
was
where
it's
appropriate.
C
A
C
A
Process
can
start
simple
and
then
we
could
elaborate
it
over
time,
like
just
looking
at
some
of
the
rollouts
people
liked
the
to
factor
off
roll
out,
but
they
didn't
like
the
roll
out
of
all
the
sig
related
teams.
For
example,
right
I
mean
definitely
something
I've
learned
is.
There
is
absolutely
no
way
to
reach
everybody
who's
going
to
be
impacted,
it's
just
completely
impossible.
Like
we
notified
every
kenhub
ID,
we
say
emails
for
all
the
emails
we
could
find.
We
say
mail
to
every
group.
It's
an
email,
security
staff.
A
C
D
I,
take
a
step
back
again.
I
think
that
we
should
be
very
careful
about
these
things
because
very
rapidly,
we've
seen
repeatedly
that
when
you
empower
SIG's
like
this
to
do
cross
project
stuff,
they
become
petty
dictatorships
and
and
the
same
thing
is
I-
think
people
need
to
opt
in
or
opt
out
explicitly
right
and
so
I
think
that
we
need
to
be
upfront
with
people
first
and
say:
hey
we're
going
to
this
we're
going
to
turn
these
people
into
the
arbiters
of
how
your
project
is
shaped.
D
C
D
D
E
C
E
C
Yeah
I'm
confused
if
any
part
of
what
I
was
doing
was
saying
that
shout
I
was
trying
to
offer
and
it
kind
of
seems
like
I,
walked
away
from
that
community
meet.
Yes,
gonna.
Try
move
on
here
with
feedback
to
continue
trying
to
reach
out
to
people
and
encourage
them
to
try
this
out,
but
if
it's
plenty
they
prompt,
if
you,
you
stop
they're
kind
of
mandating
stuff,
please
let
me
know
in
drive
this
forward
with
some
substance
of
concrete
examples.
C
You
have
a
pull
request
out
there,
that's
documenting
what
are
all
of
the
github
organizations
that
make
up
the
kubernetes
project
today,
and
then
we
have
another
poll
request
out
against
the
kubernetes
template
project,
trying
to
make
that
a
living
example
of
these
standards,
to
which
repositories
that
are
part
of
the
kubernetes
project
are
expected
to
adhere.
This
is
more
guidelines
and
trying
to
document
the
state
of
the
world.
C
I
really
appreciate
the
steering
committees,
review
of
that
pull
request
and
then,
finally,
as
discussed
over
and
over
in
the
contributor
experience
sake,
a
lot
of
newcomers
to
the
project
are
really
confused
about
the
difference
between
the
outside
collaborator
bowl
and
the
memorable.
If
you
really
think
that
like
it
would
just
be
easier
to
go
straight
to
member.
I
We
have
a
document
that
outlines
what
are
all
the
tools
and
processes
in
like
some
type
of
hierarchical
model,
of
what
it
means
to
be
part
of
the
or
because
somebody
it's
like
I
mentioned
earlier.
We
haven't
even
settled
on
what
is
in
and
out
of
the
org.
We
have
ideas
and,
like
charts,
is
an
example
of
one
of
those
things,
I
firmly
state.
You
know.
C
I
Don't
care
about
the
tools
they
care
about,
the
UX
so
can?
Can
we
define
the
entire
UX
that
they
should
experience?
You
know
like
from
both
from
labels
all
the
way
through
to
like
owners
files,
what
what
is
required
for
them
to
be
part
of
the
org
eventually
or
like
what
it
means
to
buy
into
this?
What.
D
C
D
I
think
that's
right,
because
I
think
the
top-level
things
for
people
to
say
it's
like
the
the
meta
point
is:
if
you
choose
to
be
in
Corps,
we're
gonna
top
down
you
we're
gonna
top
down
dictate
to
you
just
the
way
it
is
get
ready
for
it.
We're
gonna,
be
nice
and
we're
gonna
be
friendly,
but
we're
gonna
top
down
dictate.
And
if
you
don't
want
that,
here's
the
here's
the
way
out
right
and
I
and
I
think
that
that's
that's
enough
of
a
decision.
C
D
C
D
C
E
Okay,
I
was
just
going
to
say,
I
think
I
think
it
would
be
useful
in
that
categorization
document
when
we
say
hey,
if
you're
going
to
be
in
core,
you
have
some
rights
and
responsibilities,
one
of
those
responsibilities.
Consistency
here
are
something
examples.
This
is
not
exhaustive.
We
will
add
to
these
modify
and
redefine
these
things
over
time.
A
I,
don't
doesn't
sound
to
me
like
there
are
conflicting
goals
here:
they're
kind
of
orthogonal
in
terms
of
enumerated
what
is
owned
by
the
project
for
now
I'm
fleshing
out
details
about
some
projects,
the
newest
and
whatever
versus
saying.
Okay,
we
need
this
different
kind
of
categorization
and
we
need
it
out
for
things
that
don't
want
to
be
top
gun
to
control
Adam.
You
know,
I
think
both
of
these
things
can
be
preceded
in
parallel.
Looking
at
the
new
repo
process,
doc,
there
were
some
comments
and
points
being
on.
D
Else
should
I'll
take
a
run
through
again
today,
I
I
think
that
the
only
thing
is
we
should
I
think
that
there's
no
problem
in
the
taxonomy
taxonomy
work
I
think
the
when
we
start
actually
making
changes
to
repos,
that's
probably
where
people
and
it
is
where
people
got
a
little
upset
right.
So
I
think
we
should
pursue
the
taxonomy
in
parallel
and
the
owners
files
work,
maybe
in
parallel.
But
if
we
go
around
modifying
people's
stuff,
then
we
should
maybe
talk
with
them
and
get
them
to
volunteer
first
yeah.
A
A
A
C
But
I
mean
just
just
as
an
example
again
and
that
to
me
is
just
to
try
and
highlight
that
there
might
be
if
we
were
to
flip
on
automation
and
turn
off
the
teams.
There'd
be
a
lot
keyword,
people
who
had
right
access,
just
documenting
the
look
but
I
hear
you.
Okay,
we
have
four
minutes.
Do
you
think?
Is
it
worthwhile
to
present
Brendan's
at
a
community
meeting
to
roll
it
out
to
kubernetes?
Don't
get
like
a
feedback.
A
Yes,
you
could
I
think
it
is.
You
know,
in
terms
of
some
of
their
questions,
I
think
there
was
some
unresolved
issues
like
associated
repositories,
we're
not
clear
to
me.
They
can
make
sense
from
a
legal
standpoint.
I
don't
know
if
that
was
vetted
with
PNC
F
for
people
were
not
aware,
since
you
have
now
has
a
thing
called
the
service
desk,
which
is
make
me
a
way
to
file
a
request
through
JIRA
for
the
project.
Ask
for
help
or
clarification
things
like
that.
A
So
I
would
like
to
actually
try
to
exercise
that
yeah
but
specific
question.
For
example,
we
could
ask
you
know:
does
it
make
sense
to
have
a
repository
that
has
a
scene
CF
PLA
that
uses
the
scenes
you
have
code
of
conduct
but
isn't
really
considered
part
of
kubernetes
or
in
some
some
way
shape
or
form?
Does.
A
A
Could
file
the
ticket
and
ask
this
question:
I
did
start
the
discussion
with
Dan
about
our
concept
of
having
some
tea
and
see
how
cool
Newton
Brown
for
projects
which
would
be
less
once
not
necessarily
marketed
or
treated
in
the
same
way
as
the
existing
classes
and
projects,
and
they
were
receptive
to
that
idea,
so
it
could
potentially
fit
in
that
whether
it
could
be
entirely
self
selected
projects
bill
not
entirely
clear.
If
there's
any
kind
of
notion
of
liability
involved.
A
D
E
E
E
C
A
I
think
there
are
some
I'll
follow
up
on
that.
There
are
reasons
why
we're
gonna
want
to
do
it,
since
EF
is
gonna,
try
to
start
marketing
projects
at
different
levels
of
maturity
in
different
ways,
and
certainly
as
the
flagship
project
for
the
CN
CF
CN
CF
once
kubernetes
to
graduate-
and
you
know
if
you,
depending
on
your
bar,
we
could
be
perceived
as
meeting
the
requirements,
but
it
will
set
a
precedent
for
other
projects.