►
From YouTube: 20210218 SIG Arch Enhancements
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
hello:
everyone
today
is
february
18th.
This
is
a
enhancement,
subproject
meeting
of
sigma
architecture.
This
is
a
meeting
that
will
be
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome
people,
so
we've
got,
we've
got
a
light
agenda,
but
I'm
sure
we
have
plenty
of
things
to
talk
about.
A
B
Hello,
everyone-
this
is
naveed
I
this
is
my
first
call
thanks
for
making
this
time
considering
the
call
time
this
is
friendly
and
I'm
looking
forward
to
work
with
the
city
of
architecture
and
getting
to
know
you
all.
Thank
you.
C
Because
I
think
this
is
my
first
time
in
this
meeting,
I'm
alana
hashman,
chair
of
sigma
instrumentation
member
of
signode.
C
A
What
are
you
gonna
do
anyway,
welcome
both
and
alana
looks
like
you
have
the
first
topic.
C
Wow,
that's
what
I
get
for
being
early
on
the
discussion,
getting
things
into
the
agenda
yeah.
So
I
was
chatting
with
a
few
people,
including
john
yesterday,
and
he
encouraged
me
to
attend
today
and
to
maybe
bring
up
some
feedback
about
the
121
cap
cycle
and
like
discuss,
process
improvements.
And
I
maybe
we
should
not
do
this
as
the
first
topic,
because
I
think
that
this
could
be
very
open-ended,
because
I
don't
have
like
a
specific
like
outcome
in
mind
or
anything
like
that.
C
I
have
a
bunch
of
things
that
I've
noticed
about
this
enhancement
cycle
and
areas
that
could
potentially
be
better
and
so
given
that
it
could
probably
easily
expand
to
eat
up
all
of
the
meeting
time.
So.
F
F
All
right,
so
this
is
part
of
a
long-term
effort
to
make
kubernetes
better
process
wise
alignment,
wise
responsiveness,
wise
among
the
different
sig
leadership
and
just
how
they
how
the
cigs
are
running
and
how
they're
working
together
so
I've
gotten
some
feedback
on
this
cheat
sheet.
F
I've
started
putting
it
into
a
pull
request
as
well,
but
it's
basically
a
guide
for
how
to
run
major
aspects
of
your
sig
process,
so
starting
with
a
ways
of
working
agreement,
jumping
down
to
meetings
and
giving
some
tips
there
triage
and
triaging
tools
which
are
important
for
this
group,
because
if
we
jump
down
to
cups,
if
are
charging
cups
and
preparing
their
backlogs
in
advance
at
the
beginning
of
the
cycle,
it
makes
everything
a
lot
smoother
going
forward
through
the
rest
of
the
cycle.
F
F
F
Get
insights
and
broader
insight
from
the
group
around
what
caps
are
being
pushed
in
the
cycle
have
folks
be
responsible
for
those
caps
speak
on
behalf
of
those
caps
when
they
interact
with
the
release
team.
You
know,
there's
all
sorts
of
positives
that
can
happen
if
sigs
make
some
minor
process
adjustments
in
the
area
toward
delegation,
so
that
would
be
a
hope.
A
success
outcome
for
this
another
potential
user
of
this
would
be
a
product
manager
who
wants
to
get
involved
in
kubernetes,
but
just
doesn't
know
how.
F
I
see
this
project
as
being
like
the
ellis
island
of
product
managers.
If
they
want
to
get
on
board
with
kubernetes,
they
could
come
here.
They
bring
the
expertise
around
driving
user
stories,
roadmaps,
prioritization
techniques
and
ideally,
they
could
go
and
embed.
F
A
few
levels
if
they
get
that
experience
now,
so
there's
all
sorts
of
ways
that
this
could
be
used
and
it
can
be
used
for
the
benefit
of
enhancements
in
the
process
itself.
So
I
just
wanted
to
bring
it
here,
because
I
know
some
folks
have
provided
some
feedback
on
it
from
this
group.
If
you
haven't,
you
should
because
your
feedback
makes
this
more
concrete
and
makes
it
more
real,
because
you've
all
seen
situations
in
your
years
with
a
project
that
this
document
may
treat.
F
You
idealistically,
so
bring
your
hard-won
experience
to
make
this
quite
crisp
and
concrete,
and
that
will
make
it
more
viable
for
other
sig
leads
who
have
been
in
the
same
position
as
you.
You
know
we
have
a
little
bit
of
a
maybe
a
skepticism
in
some
areas.
That
process
can
be
improved.
I
think
that's
changing,
as
many
of
you
have
adopted
improvements
in
your
sex
and
have
shown
that
process
can
get
better
if
you
stick
to
it,
but
there's
still
more
to
go,
there's
still
some
more
guiding
folks
along.
F
So
ideally
this.
This
will
help
that
process
and
then
I
think,
if
we
pair
it
with
a
number
of
other
mechanisms
in
the
project
from
the
steering
committee,
for
example,
like
what
are
the
roles
and
responsibilities
of
a
sig
lead,
because
I
think
that
when
you
have
ambiguous
roles,
then
it's
just
really.
It
becomes
unclear
who
does
what
and
then
also
who
is
responsible
for
what?
F
So
I
think
that
if
we
paired
this
with
more
visibility
for
the
roles
and
responsibilities,
chair,
lead,
etc,
then
that
could
actually
be
quite
powerful
and
helping
helping
along
our
efforts
and
then
also
this
this
part
of
the
process,
because
if
a
sig
chair
doesn't
realize
that
they
actually
have
to
be
responsive
to
the
release
team,
I
mean
I
think
they
do,
but
if
they
don't
realize
the
impacts
of
that,
then
then
they
may
just
not
respond.
They
may
not
yeah
things
ensue.
F
F
C
F
C
Yeah
well
yeah.
I
have
some
thoughts
on
how
difficult
it
is
right
now,
so.
C
Some
of
them
are,
and
some
of
them
might
not
be
like
some
of
the
stuff-
are
definitely
like
node,
specific
sort
of
we're
in
this
point
in
time,
but
some
of
them,
like
I,
don't
see
them
as
like
transitional.
A
C
I'm
gonna
paste
a
bunch
of
stuff
in
the
dock,
because
these
are
my
things
and
then,
if,
if
you
want,
I
can
jump
into
discussion
whenever
we're
ready.
C
I
am
so
I
just
sort
of
threw
a
bunch
of
notes
in
here
for
just
things
that
I've
gone
through
this
kept
cycle
and
like
as
a
as
a
sig
chair
and
as
somebody
who's
been
tracking,
something
like
20
plus
caps
for
this
cycle,
to
try
to
make
sure
that
everything
is
accounted
for.
There's
a
bunch
of
different
areas
that,
like
potentially
there
could
be
improvements,
and
I
sort
of
like
put
a
bunch
of
bullets,
and
I
try
to
order
them
somewhat
in
terms
of
priority.
C
So
we
don't
get
too
too
caught
down
in
the
weeds,
but
the
the
first
two
main
things
that
are
a
little
concerning
to
me
is
that
the
kep
process
has
gotten
very
heavy
weight
to
the
point
where
like
and
we
don't
really
differentiate
between
different
kinds
of
things.
So,
for
example,
I
worked
on
a
kept
the
cycle
to
basically
fix
a
bug
with
like
how
probes
work
with
termination
grace
period
seconds,
because
there's
a
coupling
that
doesn't
make
any
sense.
C
In
order
for
me
to
get
that
bug
fix
fully
graduated,
it
will
take
me
three
full
release
cycles
and
so
as
a
result
of
that
kind
of
thing,
because
in
this
case
there's
a
compatible
api
change
because
of
that
kind
of
requirement
within
the
process.
Right
now,
there
are
like
lots
of
organizations
that
end
up
using
alpha
features
in
production,
and
I
don't
think
that's
what
the
alpha
beta
graduation
was
initially
targeted
for,
but
now
that
that's
kind
of
how
the
cycle
works
within
the
cap
process.
E
If
I
can
jump
in
for
a
second
I
I
question
that
a
little
bit
because
I
think
before
caps
were,
I
think
people
have
been
using
alpha
features
in
production
for
a
long
time
now.
I
agree
that
what
I
do
agree
with
the
general
principle
you're
saying
that
if
we
make
the
process
too
hard,
people
will
not
use
it,
they'll
circumvent
it,
and
I
think
that's
a
valid
point.
I'm
not
sure
that
here
that
the
existing
use
of
alpha
in
prod
is
anyway,
maybe
that's
the
pedantic
point.
Yeah.
C
Well
so
like
to
use
this
sort
of
as
like
a
case
study,
so
we
have
like
a
bug
and
it
requires
the
best
way,
probably
to
fix
it.
The
most
explicit
way,
the
least
breaking
way.
All
of
that
jazz
requires
a
compatible
api
change.
That's
going
to
take
a
year
to
hit
graduation
give
or
take,
like
maybe
nine
months,
certainly
like
a
full
cycle
of
releases
as
we're
currently
doing
them
and
like
that
had
to
go
through.
C
I
had
to
spend
you
know
like
a
couple
of
full
days
working
on
this
cap
in
order
to
even
like
propose
the
thing
and
like
that,
you
know
doing
the
design
dock
and
the
feature
proposal.
All
that,
like
that's
fine,
but
I'm
gonna,
have
to
do
that
for
two
more
release
cycles,
and
I
can't
even
have
this
thing
turned
on
by
default
for,
like
you
know,
another
release
cycle
to
fix
this
bug
and
to
compare
that
to
something
like,
for
example,
you
know
swap
support
on
nodes,
which
totally
makes
sense
to
me.
C
It
would
take
like
a
year
to
kind
of
phase
in
versus
oh
oops.
We
have
a
bug
in
how
like
liveness,
probe
timeouts
work,
the
fact
that
they're
sort
of
in
the
same
like
cycle
and
require
the
same
amount
of
paperwork
and
the
same
amount
of
oversight.
C
Absolutely
I
have
gotten
feedback
from
a
number
of
people
like
well,
let's
avoid
doing
a
cap
because
it's
going
to
be
so
hard
to
do
a
cap.
Let's
just
do
the
bug
fix
thing:
let's
just
do
the
hacky
thing
to
avoid
the
api
change,
like,
I
don't
think.
That's.
A
What
we
want,
that's
not
incentivizing
the
right
yeah,
so
I
mean
this
doesn't
feel
like
kept
stop.
This
is
that
you,
you
hit
the
api
review
process
and
you
hit
the
like.
That's
that's.
That's
a
big
part
of
it
right
if
it
was,
if,
if
you
were
delivering
an
enhancement
that
had
nothing
to
do
with
an
api,
it
would
be
a
different.
You
know
it
would
be
a
different
time
frame.
C
Well,
maybe
because
a
lot
of
the
stuff
we're
asking
to
always
put
behind
an
alpha
and
a
beta
feature
flag
now
like
regardless
of
what
it
is.
So
in
this
case
there
happens
to
be
compatible
api
change
and
we're
using
you
know
alpha
beta,
etc,
feature
flags
but
like
I
could
have
fixed
this
in
another
hacky
way
that
maybe
could
have
gone
slightly
faster,
but
we'd
still
require
the
feature
flags,
and
so
I
don't
know
that
that
would
actually
make
it
go
any
faster.
E
Yeah,
I
think
I
think
what
you're
getting
at
is
like.
What's
the
threshold
for
when,
when
the
cap
is
needed,
and
right
now,
you're
saying
that
you
get
the
feedback
you
got
from
from
the
probably
from
the
api
reviewer
team,
I
guess
was,
if
there's
an
api
change,
it
needs
a
cap
and
then
the
question
is
like
and
and
what's
I
think,
there's
two
questions
in
this
example.
E
E
E
I
remember
a
year
or
two
ago
we
had
the
same
thing
in
in
sig
network,
although
maybe
this
is
a
counter
example
to
yours,
because
we
we
said,
oh,
we
just
want
to
add
this
one
field,
and
just
just
you
know
it's
just
one
field
and
let's
just
maybe
we
can
go
straight
from
alpha
to
stable,
but
then
actually
we
went
into
alpha
and
then
we
decided
to
kill
the
whole
thing
so
like
I
guess
it
doesn't.
Necessarily
that's
it's
like
we
were
talking
about
skipping
the
beta
phase.
E
C
C
Oh,
we
needed
a
design
proposal
and
we
needed
to
make
sure
everybody
was
aware
of
this
sort
of
breaking
change
before
we
made
it
happen,
but
like
we
don't
need
to
phase
it
in
across
multiple
releases,
but
there's
there's
definitely
a
lot
of
cases
that
are
not
being
caught
by
that
and
when
we
say
like
the
bar
generally
is
alpha
beta
graduated
and
you
have
to
use
a
feature
flag
and
you
have
to
phase
it
into
this
way,
the
bar
to
like
those
contributions
and
what
what
one
may
have
to
like
you
know,
override,
essentially
or
use
judgment
to
avoid
that
initial
investment
right
up
front.
D
But
that
sounds
like
a
good
argument
for
saying
that
perhaps
what
you
want
to
do
isn't
suitable
for
a
cap
but
for
some
other
to
be
determined
process,
because
I
also
think
like
when
I've
heard
you
talk
about
it
and
you're
like
it's,
a
bug
fix
with
an
api
change.
It's
like
well
at
the
heart
of
a
kept
like
that's
not
like
the
purpose
of
a
cap
like
really
like.
That's
not
like
the
thing
that
the
kept
is
intended
for,
and
maybe
this
indicates
that
there
needs
to
be
some
kind
of
process
that
has
review.
D
Obviously,
that
is
more
suited
for
those
types
of
of
changes.
Of
course,
I
don't
know
who
owns
that
process,
because
you
just
can't
like
make
it
like
it.
There
obviously
needs
to
be
review,
but
perhaps
like
the
kep
format
filling
out,
the
entire
cap
might
not
be
the
best
thing
you
might
need
like
the
pr
or
you
might
need
some
other
bits
of
information.
But
I
think
that
that's
like.
A
E
Well,
you
said
it
in
one
of
the
you
you
at
least
you
rendered
your
opinion,
or
I
don't
know
if
it
was
a
definitional
thing
or
in
one
of
the
comments
recently,
I
tend
to
think
of
a
feature
as
right:
adding
new
functionality.
E
A
It's
a
unit
of
work
that
can
be
executed
within
the
scope
of
a
single
release.
An
enhancement
can
couple
multiple
features
right.
An
enhancement
may
span
multiple
releases,
but
a
feature.
It
sounds
like
what
we're
talking
about
here
is
a
feature
that
could
have
just
been
done
without
a
cap
or
associated
to
some
long-term
improvement
that
was
attached
to
a
cap.
A
F
I'm
gonna
suggest
that
maybe
we
think
about
well,
we
have
the
glossary
right.
This
is
part
of
our
documentation
needs.
We
might
wanna
spend
some
time
trying
to
handle
some
of
these
old
lingering
questions
around.
Like
there's,
I
was
just
looking
for
the
github
issue
like,
should
I
make
a
kept
for
a
policy
change?
F
Probably
not
right
because
of
this
discussion.
We
don't
want
to
add
weight
to
the
process
we
don't
need
to.
So
perhaps
we
should.
D
F
The
process
sees
that
will
make
sense
in
terms
of
rigor
and
weight,
and
I
think
we
have
probably
most
of
the
nuts
and
bolts
in
place,
and
I
think
it's
just
a
matter
of
refining
those
to
come
up
with
come
up
with
some
clear
guidance
around
what
people
should
do
and
from
a
process
standpoint
for
these
different
needs.
A
So
I
think
this
tags
into
the
the
discussion
about
scopes,
which
I
just
linked
in
the
chat.
Not
everything,
needs
a
cap
or
not.
Everything
is
well
shaped
for
the
release
type
process
kept
right.
Some
some
things
are
some
things
are
in
tree.
Some
things
are
out
of
trade
right.
Some
things
like
release
team
doesn't
need
to
review
some
enhancement,
sub
project
owners.
Don't
really
care
about
right
like
we
don't
need
to
have
our
paws
on
it,
so
to
speak
right
and
then
there
are
policy
changes
that
may
affect
the
entire
community
right.
A
H
A
The
the
any
of
the
pr's,
unless
they
are
specifically
tagged
for
area
enhancements
yeah,
so
we
so.
I
think
that
I
I'm
trying
to
do
the
code
bits
of
this
to
remove
some
of
those
requirements.
I
know
that
they
suck
right
now
for
for
a
lot
of
people,
especially
if
your
thing
doesn't
fit
neatly
into
something
that
needs
to
be
delivered
for
the
release.
Specifically,
I.
C
Think
that
node
is
gonna
run
into.
Like
I
mean
node
is
just
one
example,
but
node
is
going
to
run
into
this
sort
of
thing
a
lot
because
users,
like,
unfortunately,
one
of
the
problems,
is
that
people
have
ideas
of
how
things
should
work
and
even
if
it
was
like
a
bug
like
they
consider
the
bug
a
feature
and
then
it
requires
very
deliberate,
like
you
know,
changes
to.
E
I
mean
I
think
people
are
are
saying
using
are
saying
this
needs
discussion
and
documentation
and
we
need
it
an
agreed
up.
We
need
agreement
about
the
number
of
people
and
the
process
we
have
for
that
now
is
a
kept,
and
what
you're
suggesting
is
that
there
are
classes,
and
maybe
the
scope
is
the
right
way
to
do
it,
that
there
are
parts
of
the
cap.
E
That's
only
that's
what
the
like
the
original
caps
or
design
proposals
pre-caps,
that's
what
they
were
right
and
then
over
time,
we've
added
things
to
the
caps
fit
the
standard,
shape
thing
big
thing,
and
maybe
we
need
a
kept
light.
That's
like
really
just
where
we
document
the
design
decisions
we
make,
but
we
don't
need
all
the
other
aspects,
but
and
then
then
we
need
guidance
and
material
for
when
you,
when
you
do
each
yes.
F
So
I
mean
this
is
this:
is
an
exercise
on
engagement
at
the
moment
and
I'd
be
happy
to
lead
this,
but
I
think
that
you
need
it's.
You
know
think
of
jiras
right.
We
don't
use
jiras
here,
but
you
you
do
have
types
of
work
and
so
to
steven's
point.
I
think
the
scope
type
is
really
great
because
that
is
actually
pulling
us
into
this
discussion
about
what
is
the
size
of
this
thing?
What
is
the
impact
and
complexity?
So
I
think
we
want
to
create
a
hierarchy
of
these
things.
F
Policy
changes
affecting
the
whole
project
enhancements
feature
bug.
You
know,
there's
I'm
trying
to
go
down
the
list
from
big
to
look
to
small,
but
you
want
to
have
specific,
clear,
simple
processes
as
simple
as
you
can
get
for
each
of
those
stages
to
reserve
the
complexity
for
the
things
that
require
the
most
critical
eyes.
Most,
you
know
slowing
things
down
the
most
attention,
so
what
I
can
do
is
we
can
set
up
some
sort
of
table
a
draft
this,
and
then
we
can
talk
about
that.
F
A
Just
get
started,
I
want
to
call
out
that
we
are
over
time
right
now.
Okay,
for
anyone
who,
if
there
is
an
issue
that
does
not
exist,
that
you've
checked
our
project
board.
Please
drop
it.
If
you
have
notes
about
this
scope
type
topic,
please
drop
them
on
the
issue
that
I
linked.
We
will
catch
you
at
the
next
one.
Thank
you
all
for
hanging
out.
Take
it
easy.
Thank.