►
Description
Kubernetes Public Steering Committee Meeting for 20230206
A
Hello,
everyone
and
welcome
to
the
February
6th
steering
public
meeting
as
a
journal
reminder,
these
meetings
are
recorded
and
we
post
on
the
Germany's
YouTube
channel
sometime
later,
and
we
all
about
cncf
code
account
which
essentially
boils
down
to
please
be
excellent
to
each
other.
A
We
do
have
four
out
of
the
seven
string
members.
We
can't
actually
hold
the
beating
with
that.
Let
us
roll
right
into
the
topics
to
kick
it
off.
Kristoff.
If
you
have
an
update
regarding
the
annual
reports.
B
Yeah,
so
a
couple
things,
the
first
is:
there's
been
a
bunch
of
improvements
to
the
generator
special
shout
out
to
practice
sagu,
who
did
some
bunch
of
stuff
to
kind
of
automate
a
few
more
steps.
B
Everything
looks
good
for
us
to
cut
those
and
start
pushing
forward
with
annual
reports
for
the
2022
year,
I
linked
an
issue
that
we
had
for
from
last
year.
As
far
as
annual
report
feedback
I
wanted
to
ask
if
anybody
else
had
had
a
chance
to
review
it,
if
there's
anything
else
that
we
want
to
change
before
we
actually
like
cut
and
push
out
and
Report
stuff.
A
I
can
speak
for
everyone
else.
It's
it's
been
a
little
bit
since
I
looked
at
the
issue,
so
we'll
give
it
at
least
one
more
look
over,
but
ideally
we
do
want
to
at
least
get
the
generating
the
stuff
out
before
Thursday.
C
A
Thursday
is
the
first
chair
and
TLS
meeting
of
February
foreign.
B
I'll
put
a
specific
call
out
for
folks
in
particular
steering
committee
members
to
take
another
look
at
that
feedback,
see
if
there's
anything
else,
we
want
to
incorporate
as
far
as
changes
to
questions
the
template,
Etc
and
then
I'll
pick
the
action
item
to
generate
and
push
all
that
stuff
out
by
Wednesday.
A
Cool
does
anyone
else,
have
any
comments
or
thoughts
on
the
inner
reports
at
this
time.
A
Okay,
we
will
move
right
along
and
Kristoff.
You
have
the
the
first
big
block
of
all
the
things.
I
think
it
was
carry
over
from
the
the
last
meeting,
with
the
cocc
updates.
B
Yeah
I
specifically
wanted
to
ask
their
I
was
going
through
some
stuff
and
there
was
still
an
open
issue
about
steering
cscc
conflict
resolution.
I
want
to
ask
Tim:
did
you
have
any
updates
on
where
we
are
with
that?
If
that's
being
pushed
forward.
D
A
I,
don't
think
anyone
else
has
any
other.
Does
anyone
else
have
other
comments
on
that,
or
should
we
just
continue
to
move
through.
E
B
Okay,
we're
moving
right
along
I'll,
go
into
the
next
one.
I
wanted
to
Ping
about
formula
they
another
issue
that
was
like
open
in
the
steering
repo,
because
I
was
last
month.
I
was
kind
of
looking
through
okay.
What
are
what
are
action
items
that
we
had
previously
said?
We
were
going
to
do
make
sure
we're
following
up
on
those
another.
B
One
was
formalizing
thesis
report,
letters
into
our
documentation,
I
think
Ben
wrote
an
issue
about
it,
but
I
don't
know
that
we
actually
formally
assigned
out
that
somebody
would
would
take
care
of
that.
I
wanted
to
see
if
we
had
any
updates
that
I
had
missed.
A
I,
don't
believe
anyone
did
take
it.
We
have
some
of
the
this,
like
various
bits
and
pieces
like
in
the
steering
private
shared
drives
and
the
other
places
as
a
starting
point.
Just
hasn't
really
moved
beyond
that.
F
Yeah
I'm
gonna
take
it
I,
wasn't
sure
if
we
had
definitely
agreed
to
that
yet
because
I
don't
think
it
came
up
in
a
meeting
agenda.
I
think
it
was
like
in
when
Abra
and
I
were
looking
through
backlog
stuff
when
we
joined
and
I'm
not
sure
where
we'd
want
to
put
it
I
think
the
intent
there
was,
as
Bob
mentioned,
in
steering
private
locations.
We
have
the
starting
pieces
for
this.
It
seems,
but
it's
entirely
by
guess
or
Word
of
Mouth,
that
you
would
think
to
ask
for
it.
F
C
D
A
somebody
who's
looking
to
build
their
their
packet
visibility,
so
they
would
understand.
Oh
hey!
This
is
a
body
that
I
might
want
to
ask
for
some
supporting
documentation.
Would
this
be
like
a
kind
of
a
sentence
somewhere
in
one
of
our
top
level,
docs
saying
that
that's
something
that
we
are
open
to
doing?
Are
you
thinking
more
than
that.
F
Yeah
I'm
thinking
I,
don't
know
I'm
just
thinking
about
it
somewhere
now,
I
think
maybe
it
might
be
worth
putting
something
like
in
steering
stocks
a
brief
note
about
it,
but
maybe
more
importantly,
PSA
to
the
community
so
that
there's
more
people
in
the
project
that
are
aware
that
if
they
hear
that
someone
has
this
kind
of
problem
that
they
that
they
know
that
this
is
a
thing.
I'm,
not
sure
how
often
people
go
read
really
any
particular
part
of
our
docs.
If
we
want
something
to
be
really
widespread
known.
A
So
there
there
are
a
couple
places
where
you
might
build,
but
that
we
actually
have
a
list
of
services
on
and
resources
on,
keats.dev.
So
at
least
when
people
go
there
and
punch
something
in
it
comes
up
in
search.
F
I
feel
like,
though
you're
probably
not
searching
for
it.
I
think
I
think
if
I
think
about
how
it
would
spread
better.
So
far,
people
have
learned
because
I've
heard
someone
else
has
done
it
or
something
like
that.
But
I
think
if,
like
you
know
our
chairs
and
teals
and
broader
Community
know
than
if
they're
talking
to
someone,
and
it
comes
up
that
they're
working
on
a
Visa
package,
they
might
think
to
mention
steering
I'm,
not
sure
how
likely
it
is
that
people
are
gonna
like
search
for
it.
Okay,.
A
Yeah
I
think,
honestly,
we
just
picked
the
location
where
we
want
to
potentially
like
have
a
public
policy
on
it,
and
then
you
know
work
on
socializing.
It.
F
My
best
guess
would
be
this:
the
steering
repo
then
just
like
some
mark
down
there,
yeah
I,
don't
think
we
need
to
go
into
a
ton
of
detail.
I
feel
like
we
just
need
to
mention
that
we
do
do
this,
and
we
should
probably
highlight
that.
You
know
that
you
need
that
you
that
you
know
steering
can
only
provide
context
on
this,
that
you
need
to
be
like
a
major
contributor
or
something
because
I
don't
want
to.
F
It
seems
like
it
would
be
detrimental
if
we
made
it
sound
like
we're
just
handing
them
out
to
literally
anyone
that
asks
yeah,
but
we
don't
want
to
make
it
sound
like
that.
So
I
think
I
feel
like
that's.
Probably
the
extent
of
the
text
we
need
is
just
something
that
clarifies
that
home
we're
providing
evidence
of
the
of
the
we're
helping
clarify
the
large
amount
of
impact
that
people
have
as
a
reference
for
that,
but
you
still
have
to
have
it.
F
I
just
want
to
mention
it's
really
cool.
That
string
has
put
all
this
effort
into
this
previously
already
and
that
it
was
something
that
I
didn't
realize.
Steering
was
doing
until
I
joined.
So
that's
another
reason.
I
want
to
document.
Is
it's
nice
to
see
an
example
of
steering
being
able
to
do
something
helpful
instead
of
just
you
know,
sorting
out
policy
and
drama
and
things.
C
A
Next
thing
is
a
doc
that
was
sent
to
the
steering
list
for
us
to
review
the
SRC
member
selection
process
and
some
updates
to
what
they
want
to
do.
There
specifically
I
want
to
call
it
that
they
are
looking
to
get
rid
of
the
SRC
associate
role.
A
Change
accounts
there's
a
couple
other
things
in
there,
but
they
there
is
a
TL
sort
of
like
overview
of
the
changes.
A
I
have
looked
at
the
document
briefly,
I,
don't
know
how
many
other
people
have
gotten
a
chance.
I
know:
Christoph,
you've
you've
dropped
a
few
comments
on
there.
B
Yeah
I
I
read
through
it
and
reviewed
as
a
as
a
whole.
The
document
and
I
I
I
agree
with
kind
of
the
reasoning
that
the
the
SRC
is
is
kind
of
going
through.
There
I
think
they're
both
trying
to
like
they.
They
clearly
lay
out
a
couple
of
their
goals,
one
being
that
they
want
to
reduce
the
chance
of
nepotism
or
conflicts
of
interest
and
like
the
SRC
nominating
itself
and
having
no
kind
of
oversight
over
how
the
SRC
is
is
nominating
folks
in
there's.
B
You
know,
there's
part
of
me
that
goes
like
oh
we're
dropping
an
Associates
program
like
that's.
That's
not
good,
like
that's
the
the
initial
kind
of
gut
reaction,
but
when
you
kind
of
look
through
and
read
through
some
of
the
thought
process
behind
it
of
like
why
the
associates
program
as
it's
currently
designed
has
not
been
effective.
B
It
all
all
of
it
kind
of
makes
sense
in
in
its
in
its
Collective
nature
so
like.
If
this
is
something
that
the
SRC
wants
to
move
forward
with,
I
am
like
I'm
in
agreement
with
it
personally,
I
don't
have
any
objections
to
to
what
they're,
what
they're
proposing
here
and.
B
Go
ahead,
I
was
just
gonna,
say
and
hopefully
that
it
will
be
able
to
kind
of
look
and
see.
Does
this
change
the
process
have
the
intended
impact
on
SRC
membership
and
participation
and
all
that
kind
of
stuff.
D
A
Yes,
all
right:
I
I
forgot
to
unmute
my
physical
mute
button,
so
I
think
as
a
action
item
for
steering
as
a
whole.
Can
we
try
and
like
review
this
and
come
to
consensus
on
it
within
the
next
two
weeks.
F
I'm
happy
to
do
that.
I
I
previously
met
with
Tim
about
this,
and
we
discussed
some
of
the
basics.
I
think
that
La
I
need
I
mostly
need
to
look
at
that.
That
open
question
I
also
I,
agree.
I
feel
like
this
is
a
very.
This
is
actually
a
pretty
straightforward
change
and
like
well
argued
for
and
should
be
a
positive
Improvement
to
the
security.
A
Response
committee,
yeah
I'm
I'm
generally
in
support
from
what
I've
read
the
main
thing
is
just
to
give
a
chance
to
the
other
steering
members
that
you
know
aren't
here
on
the
call
or
have
been
busy
lately
to
do
sort
of
a
final
review
and
sign
off.
B
C
B
A
public
meeting
last
month
so
pushing
this
one
forward.
I
don't
want
it
necessarily
for
us
to
be
the
bottleneck
here.
If
it's
a
positive
change.
F
E
A
Okay,
does
anyone
else
have
any
thoughts
or
comments
on
this.
E
Existed
for
a
long
time,
so
I've
forgotten.
What's
in
this
dock
versus,
what's
in
my
head
in
case,
there
are
any
concerns
around
like
access
to
sense
of
information.
E
The
SRC
did
make
changes
already
that
give
the
associate
members
access
to
the
bulk
of
the
private
information
like
they
might
not
be
able
to
change
as
many
things,
but
they
can
read
enough
things
that
there's
not
really
a
big
distinction
between
Associated
and
regular
versus
being
on
call
or
not
so
I
think
we
we
combined
two
things.
One
is
that
we
we
wanted
more
oversight
on
the
membership
process
for
the
committee,
because
it
is
very
much
just
been
internally
regulated
and
I.
Think
we've
done
an
okay
job
there,
but,
oh!
E
This
is
kind
of
the
thing
that
in
our
head,
staring
exists
for
these
are
these
are
not
like
technical
problems.
These
are
human
problems
that
should
have
some
oversight
on
them
and
then
yeah,
so
I
I,
like
I
personally,
don't
have
any
concerns
about
like
an
associate
being
able
to
see
something
or
do
something
that
would
meaningfully
change
by
that
role.
E
Disappearing
and
as
just
at
least
one
anecdotal
point
of
evidence
for
myself
when
I
went
from
associate
to
full
member
was
really
kind
of
jarring,
because
I
went
from
like
no
access
to
tons
of
access
and
I
just
really
didn't
know
how
to
do
anything
with
any
of
it.
So
I
I
found
the
at
least
the
existing
associate
role
to
just
not
be
very
helpful
and
I
think
it'd
be
much
better.
A
E
It's
fine
and
Rita's
here
too.
If
Rita
has
any
thoughts
but
yeah
I,
I,
I,
I,
I,
I,
I
guess
nobody
else
from
the
SRC
was
able
to
join,
but
I
was
like
I'm
gonna,
I'm
gonna.
Join
that
way.
Okay,
questions:
Rita!
Did
you
have
anything
yeah.
A
No
thanks
for
sharing
the
associate
experience.
Yes,
Echo
Plus
One
on.
D
E
Okay,
cool
well,
yeah,
I,
don't
have
anything
else.
If
anyone
has
any
questions,
you
know
I'm
happy
to
answer
as
soon
as
I
can.
A
A
Okay,
next
thing
is
something
I
wanted
to
sort
of
bring
to
the
attention
from
steering,
because
we've
had
a
lot
of
things
going
on
related
to
this,
and
that
is
regarding
the
gcp
credits
and
cost
reduction
potential
options.
A
Something
that
has
come
up.
Ben
has
more
specific
details,
but
we
are
definitely
on
a
path
to
to
surpassing
what
we
consumed
last
year.
F
F
F
The
biggest
multi-regional
storage
thing
we
have
is
the
registry,
the
other
really
big
one
we
have
is
binary
downloads,
but
that's
those
are
actually
served
off
of
Google's
internal
spend
so
that
price
went
up
a
lot
too,
but
it
isn't
reflected
on
this
bill,
but
on
our
bill
we're
way
way
over
budget
even
worse
than
last
year.
F
We
need
more
measures
to
for
things
like
getting
people
to
actually
move
over
to
a
new
registry.
It
does
have
uptake,
but
it's
still
only
a
fraction
of
the
old
registry.
Okay,.
A
Yeah,
so
one
of
the
the
options
that
has
come
up
in
discussion
is
potentially
a
policy
around
aging
out
old
content.
Instead
of
holding
on
to
everything
forever
like
there's
people
apparently
pulling
stuff
down
still
from
when
it
was
Google
containers
still
pulling
that
stuff
down
today,.
F
To
be
fair
was
still
Google
containers
until
sometime
in
2020
I
think,
but
there
are
people
pulling
images
that
are
from
like
the
early
days,
yeah
I
I
also
I
want
to
clarify
before
people
jump
too
deep
on
bike
shedding
this
one
I
think
this
is
an
important
topic
for
the
project,
but
I
don't
actually
expect
aging
out
old
images
to
have
significant
cost
impact
because
it's
just
kind
of
the
long
tail.
Anyhow
it's
more
of
a
like.
F
We
don't
we're
getting
into
like
10
years
of
the
project
or
something
at
this
point,
and
we
don't
have
a
policy
for
ever
retiring
hosting
things,
and
so
our
hosting
is
always
just
ever
expanding.
And
besides
the
like
any
costs
associated
with
old
artifacts,
the
infrastructure
tooling
itself,
having
a
pinned
only
storage
is
causing
some
problems.
F
The
image
promoter
needs
to
go
through
and
sign
all
images,
and
our
set
of
images
only
expands
so
as
we
also
add
more
locations
that
we're
storing
images
for
cost
reasons,
the
time
to
promote
images
has
exploded,
and
we
can
do
some
engineering
work
around
that.
But
it's
also
worth
looking
at
I
mean.
Do
we
want
to
still
be
hosting
some
random
image?
Someone
pushed
eight
years
ago,
I
think
there's
some
real
trade-offs.
There.
F
But
one
that
I
only
just
thought
of
the
other
night
that
I
need
to
add
to
that
issue
that
I
want
to
put
on
people's
minds.
Is
that,
due
to
the
nature
of
container
images,
as
we've
shifted
towards
hosting
our
own
base
images,
if
we
remove
those,
then
building
the
project
at
an
old
commit
becomes
more
challenging
foreign.
C
F
I
think
this
is
something
the
project
should
be
discussing,
even
if
it's
not
the
highest
priority.
The
cost
issue
this
year
should
be
relatively
pressing,
but
this
probably
isn't
the
angle
to
fix
it.
F
A
Or
what
it's
worth
I
am
you
know
broadly
and
supportively,
defining
some
policy
of
setting.
You
know
how
long
we
want
to
retain
images
around
and
sort
of,
even
if
it
doesn't
necessarily
match
the
cost
reduction
stuff.
But
like
saying
something
whether
it's
you
know
two
years
three
years
five
years,
I
still
think
that'd
be
a
good
sort
of
thing
to
set.
F
Yeah,
our
other
point
is,
as
the
project
has
moved
over
to
the
new
community,
controlled
registry
domain
and
infrastructure
is
trying
to
reset
some
expectations
there.
This
is
a
good
opportunity,
prior
to
there
being
a
lot
of
adoption
to
to
set
the
tone
for
what
people
can
expect
from
it.
We've
already
said
that
you
can't
depend
on
the
implementation
details
on
the
back
ends
other
than
it
looks
like
oci
it
would.
That
would
be.
The
only
reason.
I
would
say
that
this
is
a
more
immediate
thing.
F
Is
we
have
a
Time
window
here
where
we
can
reasonably
say
we're
setting
expectations
up
front
for
how
this
infrastructure
is
going
to
be
used?
You
know
telling
people
not
to
expect
things
permanently
and
that's
another
reason
they
should
be
looking
at
mirroring
foreign.
C
A
I
guess
we'll
leave
discussion
to
that
issue.
It
might
also
be
worth
sending
out
just
a
general
FYI
to
kdev
to
get
wider
Community
discussion
on
that
going.
A
F
Yeah,
it
came
up
in
chairs
and
techniques
before
I
think
that
generally
people
are
okay
on
the
concept.
The
hard
part
is
the
actual
policy
like.
How
long
would
you
set
it
and
what
sort
of
rules
would
you
set?
The
other
thing
is
I
think
it
actually
specifically
needs
to
be
brought
to
release
engineering
because
there's
some
technical
blockers
I'm
up
until
this
point,
we've
intentionally
said
that
you,
you
know
you
cannot
delete
things
that
there
isn't
a
mechanism
by
Design.
F
So
if
we
decide
to
start
aging
out
content,
then
that,
like
that,
actually
needs
some
thought
right
now,
all
the
images
are
checked
into
the
digests
are
checked
into
git
and
it
yeah
it's
going
to
be
confusing
to
actually
implement
this,
so
I
think
we
should
probably
get
their
input
first,
Kristoff.
B
So
I
know
that
steering
cares
about
this
from
the
perspective
of
you
know,
making
sure
that
we
are
not
actively
harming
users
as
well
as
its
budget
impacts
with
the
cncf,
but
as
far
as
the
like
specific
technical
discussions
and
that
kind
of
stuff
I
want
to
make
sure
that
we're
having
those
in
the
right
place.
Where
is
the
right
forum
for
those
technical
discussions?
F
Then
so
generally
for
infrastructure
things,
it
would
be
Kate's
infra,
but
in
this
case
release
engineering
owns
the
tooling
that
promotes
images
and
the
whole
life
cycle
around
them.
So
the
technical
blockers
are
going
to
be
on
that
side
and
we
need
to
have
a
discussion
with
them,
I've
cc'd,
on
the
issue,
but
we
probably
also
need
to
take
that
discussion
to
their
meeting.
F
But
in
terms
of
having
a
discussion
around
like
you
know,
if
we
were
okay
with
a
policy,
I
think
that's
a
broader
Community
input
and
it
it's
also
okay,
I
think
if
we
communicate
out
sort
of
an
intention
and
don't
necessarily
meet
that
right
away,
because
I
think
the
one
of
the
biggest
time
blockers
is
before
we
start
deleting
things
we
want
to
tell
people
that
we
intend
to-
and
this
is
what
it's
going
to
look
like.
F
I
just
want
to
make
sure
that
it's
grounded
at
least
grounded
in
being
remotely
practical
before
we
do
anything
and
people
who
work
on
the
image
promoter
have
not
commented
yet,
so
we
need
to
bring
them
into
it
before
we
get
too
far.
With
this.
F
And
I
do
think
steering
should
be
aware
just
because
this
will
have
impact
on
how
people
use
things
and,
at
the
same
time,
I
also
think
we
should
be
helping
make
sure
that
efforts
related
to
the
the
cost
issue
and
and
for
our
driven
for
whether
or
not
we're
directly
involved
in
technical
conversations.
F
A
One
other
just
general
thing
on
you
know
if
we
can
come
to
it
against
a
consensus
on
a
policy
at
least
announcing
that
policy
to
a
wide
user
base
would
be
ideal.
If
we
could
come
to
that
sort
of
conclusion
by
kubecon,
because
I
know
we
could
get
it
mentioned
at
on,
like
the
keynote
stage
and
I'll
sort
just
to
hit
a
wider
audience
to
communicate
that
this
is
happening.
Not
even
necessarily
you
know.
F
Yeah
I
think
I'd
like
to
Hope
release
folks
and
then
from
their
repo
chairs
and
tech
leads
and
kativ.
C
D
But
maybe
if
we
acknowledge
that
sooner
than
later
we
could
highlight
that
this
may
be
a
change
coming
in
a
way
that
it's
a
request
for
stakeholder
input,
because
we
we
know,
we
have
a
lot
of
people
out
there
doing
odd
things
and
if
we
haven't
have
10
000
people
sitting
at
you
know
audience
that
might
be
a
way
to
get
them
to
actively
give
us
our
more
feedback.
So
we
understand
some
things.
We
might
end
up
breaking
through
a
choice.
Yeah.
A
If
we
do
want
to
do
that,
I
would
say
we
definitely
want
a
issue
or
form
or
something
to
direct
them
towards
just
so.
It's
not
happening
like
all
over
the
place.
A
Okay,
we
will
move
to
the
the
next
thing,
and
this
is
something
we've
talked
about
in
steering
a
few
times
and
has
come
up
in
the
chair
and
tech
leads
meeting
now.
Multiple
times
is
the
idea
of
actually
defining
a
sub-project
lead.
A
We
sort
of
have
like
sort
of
the
idea
of
sub-project
owner
sort
of
matches
to
what
a
lead
would
be,
but
at
this
point
they're
tends
to
be
just
like
you
know:
a
sub-project
might
have
multiple
owner's
files
and
various
people
across
the
board
in
there,
but
there's
usually
only
a
couple:
people
that
are
an
actual
point
of
contact,
that
sort
of
have
the
full
knowledge
of
that
sub-project
and
both
for
them
being
a.
A
So
say
someone
happens
to
be
a
sub-project
lead
over
multiple
sub-projects
in
a
Sig,
then
you
know
it's.
It
would
be
pretty
obvious
that
they
might
make
a
good
candidate
for
a
TL
and
there's
been
General
support
of
something
like
this
from
the
other
chairs
and
TLS,
and
the
other
meetings.
So
I
just
wanted
to
to
bring
it
here
officially
to
talk
about
it
and
sort
of
think
of
potential
next
steps.
If
it
is
something
we
want
to
go
with.
C
B
B
I
think
is
a
positive
change,
because
I
think
it's
unclear,
I
think
to
some
folks
of
like
hey
I'm,
an
approver
where
do
I
go
from
here?
How
do
I
go
and
continue
to
build
influence
in
the
project?
How
can
I
go
from
being
like
a
an
approver
or
a
sub-project
owner
into
Sig
leadership?.
B
So
I
think,
like
the
concerns,
like
the
problem
statement,
that
that
is
happening
here
like
I
I,
see
it
as
like
a
clear
problem
statement
and
a
a
real
problem
and
I
think
the
proposed
solution
of
adding
this
extra
rung,
defining
it
as
a
a
named
role
and
then
allowing
sigs
to
roll
that
out
as
they
see
fit,
I
am
yeah
I'm
I'm
in
support
of
of
all
that,
I
think
it
as
far
as
next
steps.
B
It
would
seem
to
me
that
it
would
be
like
a
a
PR
to
our
government
stocks
with
specific
language
and
then
setting
a
consensus
period
and
requesting
feedback
and
in
particular
from
that
chairs
and
TLS
kind
of
group
of
like
hey.
If
we
had
a
role
defined
as
this,
would
you
find
that
useful?
Would
that
be
something
that
you
would?
D
I
wish
we
still
had
Mo
but
I'm
curious
if
Rita,
if
any
of
this
kind
of
resonates
relative-
oh
wait,
you
are
still
there
most
all
right.
Zoom
was
not
showing
your
your
picture.
E
E
So
yeah,
let's
one
of
the
pieces
of
feedback
I
got,
is
much
easier
to
like
promote
someone
if
they're
like
working
in
a
targeted
space,
because
you
can
be
like
like
look
at
all
these
things
that
are
like
related
and
they
make
sense-
and
you
can
say
okay,
this
person's
done
a
ton
of
work
with
certs,
so
they
can
probably
approve
certain
related
changes
to
kubernetes
or
something
you
know.
Something
like
that
so
having
it
in
like
sub
projects,
probably
would
be
really
meaningful
and
helpful.
E
There
I
think,
yeah,
and
so
like
read
this
writing
and
chat.
You
know,
being
pro
I'm,
assuming
you
mean,
like
secret
CSI
store
driver
like
I,
think
that
helped.
C
E
Ramp
up
but
yeah,
we
at
least
didn't,
say
God.
We
we
do
have
a
pretty
significant
deficit
of
people
that
we
could
reasonably
promote
so
yeah
I'm,
all
for
having
more
structured
and
documentation
and
details
for
how
we,
how
we
do
this
in
a
way
that's
sustainable
over
time,
because
I
mean
eventually,
people
will
leave
right.
It's
sort
of
inevitable
yeah.
A
C
Yeah
I
I
didn't
like
this
change
because
it
solves
this
problem
of
only
two
TLS.
According
to
governance,
documents
should
be
on
Stig,
I
mean
two
or
three
I
think
has
a
current
suggestion
is
and
in
signals
like
signal
is
huge
and
we
have
various
areas.
So
we
have
few
candidates.
We
want
to
recognize
somehow,
and
this
definitely
will
help.
C
One
question,
though,
is
what
would
be
the
is
there
anything
we
can
do
on
enhancement
repository
like
even
today
we
have
this
discrepancy
between
chairs
and
c
and
TLS.
We
allow
all
Sig
leads
to
approve
caps,
so,
like
current
structure,
doesn't
differentiate
between
shares
and
TLs,
but
at
the
same
time
Charter
doesn't
like
I.
Think
according
to
Charter
is
not
supposed
to
be
shared.
C
It's
supposed
to
be
only
CLS,
approving
enhancements
and
same
with
CEOs
of
sub
projects,
since
we
don't
have
any
clear
differentiation
which
sub
projects
is
enhancement
belong
to.
We
cannot
Grant
permissions
to
approve
sub-project
enhancements
as
well,
so
maybe
some
thinking
can
be
done
there
to
improve
the
structure
of
enhancement,
folder
or
enhancement
folder
structure.
A
Can
I
get
in
quick,
Ben
yeah
you?
You
actually
got
your
hand
back
up.
First,
okay,
one
quick
time.
The
part
of
the
reason
why
chairs
and
TLS
both
have
approved
in
there
is
because
technically
right
now,
in
the
absence
of
a
TL,
all
responsibilities,
roll
up
to
the
chair,
this
is
something
we
do
want
to
split
off.
We
want
to
make
them
explicit,
named
roles.
A
It's
that
way
you
know,
chairs
are
one
thing
and
TLs
are
another
just
because
they
tend
to
get
conflated
together
quite
a
bit
and
one
other
thing
that
I
have
encouraged
I
know
others
have
encouraged,
but
is
rarely
done,
is
one
of
the
reasons
for
breaking
caps
and
enhancements
into
their
own.
Folder
is
because
that
folder
can
then
have
its
own
owner's
file.
So
as
a
Sig
lead,
or
you
know,
as
a
TL.
A
If
you
want
to
fully
delegate
a
specific
enhancement
to
another
team,
you
could
do
that
through
the
owner's
file
or
you
know,
if
you
don't
want
to
necessarily
do
approvers
you
can
at
least
you
know,
set
the
you
know
the
sub-project.
You
know
future
sub-project
leads
or
whatever,
as
the
first
stage
reviewers
for
that
group
before
potentially
bumping
it
up
to
a
TL
for
final
review.
B
A
Can
that
can
be
done
today,
just
no
one
I've
only
seen
I
think
I've
only
seen
it
done
once
where
someone
has
created
an
owner's
file
in
the
specific
enhancement
folder
for
a
specific
enhancement
and
I
I
really
wish
that
more
leads
would
take
advantage
of
that
and
just
being
able
to
delegate
work
well
again.
They
don't
necessarily
have
to
approve,
but
at
least
being
able
to
delegate
some
some
of
that
Ben.
F
It'd
also
be
worth
double
checking.
I,
don't
think
we
have
any
significant
blockers,
possibly
no
blockers
today,
to
if
a
Sig
wanted
to
have
like
folders
for
sub
projects
within
their
Sig
folder
and
put
in
owner's
files
there
and
then
put
kept
folders
underneath
that
I
think
that's
I
think
that'd
be
fine.
F
The
only
thing
that
is
kind
of
centralized
in
kept
is
having
the
production
Readiness
review
metadata
and
that's
in
like
a
separate
folder,
we
might
have
to
check
the
like
prr
lender,
to
make
sure
it
supports
having
additional
nesting
but
I
think
if
any
changes
would
be
required,
it
would
be
pretty
small
and,
as
Bob
mentioned,
we've
already
had
very
limited,
but
precedent
of
people
putting
in
their
own
owners
I
also
want
to
address.
F
The
number
of
leads
you
can
have
more
and
in
our
case
we
do
for
the
moment
and
I
think
it's
useful
for
sigs
to
to
to
try
exploring
the
boundaries
a
little
bit
and
see
what
works
so
like
if
signode
is
interested
in
having
some
projects,
owners
approve
keps
separately,
like
that's
something
that
you
could
go
try
and
we
can
see
if
that's
something
we
want
to
suggest
more
generally,.
A
No
one
other
just
because
I
have
to
address
here,
comment
in
chat
or
in
the
doc.
It
has
been
brought
up
to
the
chair
and
tail
meeting
several
times
now.
I
just
don't
know
if
it
needs
to
become
like
a
recurring
item
that
we
put
on
the
top
to
be
like
hey,
you
can
do
this
hey.
You
can
do
this.
B
Yeah
I
was
capturing
Tim's,
suggestion
and
chat,
but
it
that
it'd
be
brought
up
again
but
yeah.
It
might
be.
Even
if
there's
I,
don't
know
if
there's
like
a
Sig
chair,
TL
tips
and
tricks
guide
that
we
have
somewhere
because
as
I
I
think
there's
a
few
things
that
kind
of
fall
into
that
category
of
like
we
know
they're
there,
but
every
so
often
we
still
get
a
question
about
like
hey.
Can
we
do
this,
but
the
functionality
is
already
there
so.
D
A
Actually
one
other
just
general
comment
and
I
I've
said
this:
before
too,
we
are
not
doing
a
good
job
of
taking
advantage
of
the
reviewer
role.
A
A
lot
of
places
it
is
the
the
reviewer
is
both
in
a
reviewer
and
approver,
like
the
list
is
exactly
the
same
and
like
I
I
have
encouraged
in
out-of-band
conversations
the
chair
and
tales
meeting
that
we
should
be
using
that
more
people
shouldn't
be
afraid,
like
if
a
person
has
been
fairly
competent
and
they've
reviewed.
Other
PRS,
like
I
I,
don't
see
a
blocker
to
adding
them
as
as
a
reviewer.
A
It's
just
not
something
like
I
see
it
as
just
a
general
problem.
I
think
it's.
F
A
little
bit
harder
in
caps,
but
yeah,
like
generally
great
you
know,
I,
have
a
change
coming
probably
this
week
that
we
approved
for
the
workflow
and
I'm
planning
to
put
a
PSA
out
to
that
effect.
The
community
is
very
rarely
actually
using
the
reviewers
field
at
this
point
and
that's
one
of
the
ways
I
feel
like
the
latter
was
drawn
up
behind.
F
You
start
contributing,
you
become
a
reviewer,
then
after
you've
had
a
fair
bit
of
reviewing
and
some
contributions
you
become
an
approver
propose
that
at
some
point,
maybe
you
become
a
lead
somewhere
that
that,
like
second
step
after
you
start
contributing
or
you
become
a
reviewer
I,
almost
never
see
that
happening
anymore
and
instead
I
see
a
lot
of
like
after
someone
somehow
manages
to
become
extremely
trusted
in
a
Sig.
F
They
join
like
Sig,
whatever
review
approve
Alias
and
are
suddenly
an
approver
in
like
50
places,
and
that
makes
people
really
hesitant
to
add
them.
I
think
it
I've
seen
that
it's
both
been
really
rare
to
do
scoped
owners
anymore,
and
it's
been
really
rare
to
just
toss
people
and
reviewers.
If
they're
interested
and
recognize
that
you
it
doesn't
actually
deem
any
power
other
than
getting
spammed
by
GitHub,
you
have
the
same
LG
TM
power,
any
member
of
the
community.
F
F
A
A
Okay,
one
other
thing
that
the
idea
of
having
a
named
role
is:
it
actually
helps
with
employers
and
justifying
things,
because
it's
no
longer
like
hey
I'm,
just
this
owner
in
these
various
things,
it's
kind
of
hard
to
justify
time,
and
things
like
that,
for
you
know
the
actual
like
lead
the
importance
of
it,
but
named
roles
like
if
you
can
say
explicitly
that
you're
a
sub-project
lead
and
can
point
to
something.
A
F
I've
also
had
back
before
that,
sometimes
when
people
are
working
on
things
in
open
source,
it
can
be
really
hard
to
condense
without
participating
yourself,
like
who's,
actually
leading
this
sort
of
thing,
and
someone
can
be
highly
involved
and
just
have
no
evidence
that
that
they
can
really
definitively
say,
like
I've,
been
leading
this
I
think
as
much
as
possible.
We
want
to
put
out
chariots,
like
this
I
think.
A
Does
anyone
else
have
thoughts
or
comments.
A
Okay,
that
takes
us
to
the
end
of
our
agenda.
Is
there
any
other
items
that
people
want
to
talk
about?
Maybe
we
have
seven
minutes
left.