►
From YouTube: 20220721 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
Laughs,
this
is
the
Fig
architecture,
enhancement
sub
project,
meeting
on
Thursday
July
21st
at
10,
A.M
PT,
I'm
Kirsten,
your
host,
and
this
call
is
being
recorded
and
subject
to
the
kubernetes
code
of
conduct
be
nice
to
each
other
and
if
you
have
any
problems,
feel
free
to
contact
me
offline
and
don't
forget
to
sign
in
on
the
doc
about
who's
here.
Joseph
I
think
is
the
only
one
who
isn't
on
the
dock
right
now
and
I
reordered
a
little
bit
so
I
guess
I'll.
A
Let
Priyanka
go
first
I
think
she
has
and
release
team
update
for
us
go
ahead.
Priyanka.
B
Oh
hey.
Thank
you
question.
So
it's
a
follow-up
update
from
the
async
discussion
we
had
last
week
or
maybe
multiple
weeks
back,
so
this
is
regarding
migrating
from
using
GitHub
Google
spreadsheet,
for
enhancements
tracking
purpose
to
a
GitHub
project
beta.
B
As
discussed
I
created
a
issue
under
k,
Community
for
just
tracking
the
GitHub
project.
Data
creation.
I
have
created
a
board.
It's
a
test
board
that
we
are
using
to
just
test
our
automation
scripts.
B
So
I'll
link
the
issue
there,
six
seven
three:
five,
which
is
tracking
the
board
creation.
Then
the
board
is
also
linked
there.
There
are
also
some
scripts
that
we
have
raised
PR's
for
they
will
go
under
Sig
release,
repo
and
I've
linked
the
one
for
enhancements,
alternated,
Automation
and
I'm.
I
need
help
with
reviews
and
feedback
on
that.
So
I'm
not
sure
if
someone
from
sub
project
should
be
reviewing,
it
are
sick
release
leads
should
be
reviewing
it.
I.
A
Think
it
makes
sense
like
I,
think
Bob
and
I
are
aware
of
it.
But
I
think,
since
this
is
more
of
a
release,
team
thing
like
you're,
going
to
want
them
to
kind
of
review
the
nuts
and
bolts
of
whatever
sort
of
request
you're
making
for
like
all
of
the
GitHub
access
stuff.
B
Okay,
so
I
I
added
to
the
next
six
release
meeting
agenda,
then
so,
just
to
just
to
give
a
brief
overview
of
what
is
there
in
that
PR?
It's
it's
adding
a
bash
script,
which
is
just
using
GitHub
CLI
to
authenticate
with
GitHub
and
and
grab
some
information
from
K
enhancement
repo
and
put
it
to
the
put
it
on
the
the
project
board
that
I
just
created.
So
yeah,
that's
what
we
are
doing
there
and
for
that
we
require
a
GitHub
token.
B
So,
when
I'm
doing
it
locally,
I'm,
just
creating
one
token
of
my
own
from
my
own
GitHub
account,
but
we
are
proposing
that
we'll
run
this
script
as
part
of
a
proud
job,
periodically
maybe
running
every
three
or
five
hours
we
are
still
discussing
on
that.
B
But
yeah
we'll
require
a
GitHub
token
created
from
maybe
a
board
or
something
that
have
a
those
that
have
a
set
of
permissions
which
are
linked
in
that
issue
and
we
need.
We
would
require
that
GitHub
token
to
be
added
as
a
secret
in
the
brow
infrastructure,
Google
infrastructure,
where
this
brow
job
will
run
so
I
had
created
an
issue
for
that
and
it
was
moved
to
K
org,
but
I,
don't
know
after
this
who
should
I
reach
out
to
for
creating
that
GitHub
token
and
helping
us
with
that.
B
That
GitHub
token
will
be
added
as
a
secret
in
the
brow
cluster-
okay,
okay,
somewhere
in
wherever
we
are
running,
one
of
the
problems
in
Google
infra
will
need
to
add
it.
There.
B
Yeah
I,
okay,
yeah
I,
need
help
to
basically
understand
where
should
I
reach
out
to
for
that
GitHub
program.
A
Okay,
okay,
we
can
follow
up
for
that,
find
out
who
has
to
help
you
but
yeah,
and
so
so
ideas
like
you're
you're,
moving
everything
over
from
1.25
and
you're
gonna
see
how
it
goes
and
then
are
you
changing
anything
like
for
the
actual?
A
Are
you
teaching
anything
for
1.26,
or
are
you
like
test
driving
it
1.26
or
I?
Guess?
What's
what's
that
about.
B
Okay
yeah,
so
this
is
what
I
was
thinking.
We
can
just
have
it
running
as
a
parallel
board
in
1.26
and
if
the
lead
and
the
Shadows
during
that
release
cycle
feel
it's
good,
then
maybe
we
can
add
documentation
around
this
board
for
1.27
during
1.26
release
cycle,
and
then
we
can
really
move
away.
A
B
The
spreadsheet,
but
then
there
is
not
much
changing
as
well
with
this
board.
The
board
is
exactly
same.
I
can
maybe
share
my
screen
after
this,
but
just
wanted
to
mention
one
bit
that
sorry
I'm
forward.
So
the
board
is
exactly
same
just
that.
B
Yeah,
so
there
is
one
one
broker
there
that
this
we
can't
clone
and
duplicate
these
boards.
So.
A
B
Every
standard
GitHub
project
there
is
a
option
available
that
you
can
clone
of
or
duplicate
a
board
from
whatever
you've
got
you
already
have
and
and
then
you
can
just
have
a
copy
of
that
and
change
the
name
of
that
to
1.,
maybe
two
six
and
then
use
it
further.
But
that's
not
the
case
with
GitHub
project
beta.
There
is
no
clone
or
duplicate
option
available.
B
There
is
a
issue
open
for
that,
but
I
have
not
seen
any
progress
on
that
so,
which
means
number
one
thing
that
any
lead
who
will
be
using
this
as
part
of
a
release
cycle
would
need
to
spend
maybe
a
couple
of
hours
having
one
board
open
on
one
side
and
taking
one
bit
at
a
time
from
the
board
and
adding
it
to
a
new
board.
So
I
was
hesitant
on
that.
One
and
I
wanted
to
understand.
B
What
do
you
all
feel
about
that,
because
I
would
not
want
a
lead
to
be
doing
that
at
creating
every
bit
in
the
board
manually.
There
is
no
way
to
so.
We
can
create
a
board
using
GitHub
apis,
but
there
are
still
not
project
V2
apis
which
are
not
available
for
creating
columns
it.
It.
B
A
Are
available,
I
think
we're
getting
I
think
we're
getting
a
little
too
into
the
Weeds
on
like
how
the
release
team
is
going
to
like
duplicate
boards
in
the
future,
but
it's
also
a
beta
project.
So
by
the
time
you
know
you
want
to
use
it
for
one
two
1.27
they
very
well
might
actually
have
that
feature.
You
know,
but
it's
also
not
unheard
of
for
the
enhancement
team
lead
to
have
to
like
do
extra
work.
A
Prep
work
on
the
front
end
of
a
release,
so
it
seems
within
the
scope
of
the
role
like
I
was
enhancements,
lead,
and
that
seems
totally
within
the
scope
of
the
role
to
like
have
to
spend
a
few
hours
prepping
everything
to
get
it
ready.
So
it
doesn't
really
feel
like
a
blocker,
but
that
also
feels
more
like
a
release.
Team
question:
I,
wouldn't
let
that
block
you
from
from
going
forth
with
this
and
it's
beta,
so
it'll
probably
get
sorted
out
in
the
future.
B
Yeah
I
I
was
going
to
talk
to
Bob
and
maybe
some
other
people
from
GitHub
staff
team
whosoever.
We
have.
We
are
currently
talking
to
and
maybe
figure
out
if
there
is
a
way,
but
right
now
we
might
get
some
apis
to
to
actually
create
columns,
but
at
this
moment
they
are
not
available.
So
the
board
creation
bit
is
manual
at
the
moment.
Yeah,
that's
a
one-time
thing,
but
still
it's
Marvel
so
wanted
to
put
that
out
here
as
well.
B
A
Yeah,
thanks
for
the
update
like
for
the
most
part,
I,
think
everybody's,
who
needs
to
be
cc'd
on
those
PR's
is
cc'd
and
if
you
have
trouble
getting
reviews
like
we
can
poke
people
to
help
you
and
I
think
State
release
can
probably
also
help
you
like
a
release
team
thing,
but
yeah.
It's
interesting.
C
A
A
C
Or
you
don't
have
to
I
just
see
that
you're
here,
yeah,
hey
I'm,
one
of
the
Shadows
for
the
enhancement,
sub
theme
of
this
release,
so
I
thought
I
would
just
drop
by
and
see
what
typically
gets
discussed
during
this
meeting
silver
for
all
different
topics.
C
A
Cool
and
yeah,
just
as
a
note
like
the
release
team
stuff,
is
not
usually
in
this
meeting
at
all
like
it's
just
because
if
we
were
discussing
this
like
in
a
couple
other
meetings
so
like
that's
more
of
like
a
release,
team
thing
and
I
just
want
to
make
sure
that
all
of
this
has
kind
of
visibility
for
like
stick
release
and
not
the
enhancements
of
project.
So
just
like
I
guess,
he's
out
of
mind
like
but
I
think
it's
great
to
get
the
updates
and
things
and
I
know.
C
Gotcha
thanks
and
then
I
have
something
on
here,
but
I
was
just
wondering
if
anybody
else
has
any
other
topics
that
they
wanted
to.
A
Discuss
like
because
there's
just
mine,
that's
left
on
the
agenda:
Xander
Ray
Joseph,
no.
C
Cool
yeah,
so
I
was
basically.
A
C
A
Anyway,
summary
for
whoever
ever
listens
to
this,
if
anyone
ever
does
basically
like,
we
have
a
lot
of
people,
not
a
lot,
but
we
have
a
not
trivial
number
of
people
who
use
the
kept
template
for
process
changes
so
like
maybe
how
a
Stig
does
things
or
a
policy
change
that
affects
like
a
project
like
you
know,
thinking
of
like
the
Cadence
cap
and
the
existing
cap
doesn't
really
doesn't
really
work
for
that
right,
because
it's
like
very
much
for
technical
changes
to
the
KK
repo,
as
opposed
to
like
process
and
policy
changes.
A
So
I
was
taking
the
first
pass
of
that
just
to
like
think
it
through,
like
kind
of
clean
out
the
cap
template
for
things
that
didn't
necessarily
make
a
lot
of
sense
for
process
caps,
because
there's
just
like
a
lot
of
stuff.
That's
like
not
applicable,
like
you,
don't
like.
A
There's
no
testing
there's
no,
this
there's
that
but
I
guess
the
thing
that
I
was
also
thinking
about
was
graduation
criteria
because,
like
on
one
hand,
it's
like
yeah
sure,
like
you're
saying,
is
life
memorializing
a
process
change
right
like
that's
great
and
you
don't
necessarily
like
it
would
go
straight
to
GA
like
because
maybe
it's
just
like
I,
don't
know
like
sick
enhancements,
has
decided
to
I.
Don't
know
what
we're
going
to
decide
to
do.
A
But
then,
when
we
think
about
things
like
the
Cadence
cap,
where
we
change
the
from
a
team
to
like
you,
know
the
kubernetes
Cadence
from
four
to
three,
something
that
really
concerned
me
was
that
it
kind
of
went
straight
to
GA,
without,
like
necessarily
like
a
formal
like
commentary
period
and
like
kind
of
ensuring
that
those
large-scale
project
changes,
get
circulated
for
a
minimal
amount
of
time
like
in
the
community
before
they
go.
Ga
I,
don't
know
so.
A
C
A
A
A
I'm
just
scrolling
through
this
really
quickly
but
like
I
I,
took
out
some
things
that
you
know
like
I,
think
I
have
to
clean
that
up.
But,
like
a
summary,
like
you
know,
a
motivation
seems
fine
goals
and
on
goals.
That's
fine,
I.
C
A
A
section
that
was
scope
and
impact,
because
that
was
something
that
I
think
came
up
a
little
bit
like
who's
actually
affected.
You
know
like
if
you're
in
I
don't
know
Sig
testing
and
you're
documenting
a
process,
and
it's
only
really
affecting
your
group.
It's
like
not
a
completely
big
deal
right,
but
if
you're
in
should
release
and
you're
changing
telling
this
like
for
everybody,
then
you
know
like,
let's
indicate
who's
actually
affected,
so
people
can
kind
of
skip
it
and
not
pay
attention.
A
We
can
highlight
whether
or
not
like
end
users
are
affected
if
it's
like
a
multiple
stake
thing,
if
it's
a
specific
Sig's
internal
process
whatever
or
the
whole
Community
like
the
current
process,
like
you
know,
you're,
like
are
you
changing
your
process?
Are
you
creating
one
so
like
if
something
already
exists
and
if
so
like?
What
is
that
thing?
I
added
that,
because
I'm
thinking
you
know
like
most
people,
don't
necessarily
have
processes
written
down.
A
So
it's
also
a
way
to
kind
of
memorialize
what
they're
doing
and
to
have
people
who
are
reviewing
it
have
like
a
full
context.
I've
taken
out
the
user
stories.
I
think,
but
so
in
the
graduation
section
I
guess
like
I'm
saying,
like
the
criteria,
should
really
depend
on
the
scope
and
the
impact
right
like
I.
A
Don't
think
that
we
want
to
do
away
fully
with
the
total
idea
of
graduation
criteria
simply
because
there
could
be
changes
that
are
very
large
and
I
I'm
thinking
in
terms
more
of
communication
and
being
able
to
communicate
and
have
iterative
time
on
those
changes
seems
really
important
for
large
changes
and
that
could
be
part
of
the
graduation
criteria
so,
like
I
thought
of
it
at
the
time,
especially
three
buckets
like
a
process
change
that
goes
into
effect
immediately.
Maybe
you're
documenting
a
current
process,
or
maybe
it's
just
something.
A
That's
really
straightforward
process
change.
It
goes
in
into
effect
and
extra
lease.
It
might
be
like
something
like
you
know:
hey
we're
going
to
do
things
differently
on
the
relief
team
or
we're
gonna
may
not
release
team,
but
you
know
like
we're
going
to
do
something
differently.
A
As
of
this
release,
so
like
we
want
to,
you
know,
let
everybody
know
ahead
of
time,
and
then
you
know
something
where
maybe
it's
just
like
a
really
big
change,
and
so
it's
not
necessarily
the
next
release,
because
we
want
to
have
time
to
have
like
you
know.
The
commentary
want
to
have
time
to
iterate,
and
then
we
want
to
have
time
to
actually
let
everybody
know
and
I
think
like
for
some
extremely
large
changes
like
the
letting
people
know
and
prepare
for
those
changes
might
might
make.
A
It
might
make
sense
to
have
some
future
release
date.
So
that's
kind
of
what
I'm
thinking
about
for
graduation
criteria
and
I'd
be
kind
of
interested
like
when
I
put
just
like
work
in
progress
PR
to
to
kind
of
like
read
the
room
on
what
other
people
are
thinking
just
because
I
feel
like
the
process.
Cap
like,
on
one
hand,
is
stripped
down,
but
on
the
other
hand
like
it
still
needs
to
have
some
standards
of
like.
When
does
this
test
go
into
effect
and
what
has
to
happen
before
it
goes
into
effect?
A
A
Maybe
we
need
to
make
sure
that
there's
some
documentation
in
place
somewhat
community-wide
like
feedback
mechanism
in
place
where
we
really
try
to
solicit
some
some
input,
Etc,
so
I,
don't
know
I'm
just
trying
to
think
through
the
graduation
criteria
instead
of
strictly
letting
people
do
whatever
they
want,
because
I
think,
like
the
biggest
thing
about
process
caps,
is
the
communication
part
and
getting
the
comment
and
also
understand
and
impact
to
other
people.
A
So
I,
don't
know,
I,
don't
know
what
other
people
think
I
know
they're
all
like
kind
of
involved
on
the
team
and
things
so
yeah.
That's.
That
was
something
that
I
was
like
fully
around
with.
It
would
be
nice
to
I.
Think.
C
I,
like
this
changes,
a
lot
I
think
those
are
great
sections
to
add.
I
agree
with
you
that
something
that
is
that
affects
the
whole
Community
should
be
GA
did
in
the
feature
release.
Maybe
we
could
set
some
guidance
and,
like
you
know,
if
this
affects
whole
Community
I,
think
the
it
should
be,
should
Target
a
feature
release
instead
of
right,
yeah.
A
Yeah
like
to
be
able
to
say
like
hey
as
of
like
okay,
like
I'm,
proposing
this
massive
Community
UI
change,
and
what
are
we
in
125
and
125,
and
I'm
gonna,
get
like
a
bunch
of
feedback
Etc
like
I,
don't
know
like
it
kind
of
would
feel
weird
to
say:
okay!
Well,
it's
in
effect
in
126,
when
it
could
just
like
the
whole
feedback.
A
This
is
like
the
new
thing
like,
depending
on
the
scale
of
course,
but
I
think
it's
like
having
those
communication
like
kind
of
mandating
a
certain
amount
of
communication,
depending
on
the
scope
of
the
of
the
change
I.
Don't
know
because
I
think
some
changes
are
really
big
and
they're
really
hard
to
I.
Don't
know
circulate
in
One
release,
whereas
others
might
not
be
right
and-
and
other
people
might
have
circulated
it
already
so
I
think
it
just
depends,
but
I'm
totally
rambling.
C
I'm
really
tired
today
so
I'm,
sorry
for
everybody
having
to
listen
to
me
that
well,
I
always
feel
like
it
takes
a
while
to
get
knowledge
or
information
of
a
process
change
out
and
comprehended
by
it,
but
but
by
people,
not
the
message
out,
but
like
people
actually
reading
it
and
taking
note
of
that
change,
even
though
you've
emailed
kdev
a
few
times
but
I
feel
like
it
always
takes
a
little
bit
of
time.
So
I
think
it's
great
to
to
have
some
kind
of
guidance
to
hey.
C
A
And
I
was
thinking
like
you
know,
like
we
can
kind
of
think
through,
like
the
different
levels
of
scope
and
it's
kind
of
like
ensuring
like
a
minimum
quality
of
communication.
You
know
as
well
to
be
able
to
say
like
okay
like
well.
This
is
a
small
thing,
but
you
know
I
assume
that
you've
sent
something
to
your
slack
Channel.
You
put
it
in
your
meet.
You've
bought
it
up
in
a
meeting.
You've
updated
your
GitHub
docs,
like
maybe
that's
all
that's
needed,
but
for
other
people
it's
like
okay.
Well,
maybe
you
need
kdev.
A
A
Maybe
we
need
to
make
sure
that
there's
like
I,
don't
know
a
tweet
or
something
you
know
like
just
kind
of
like
setting
the
minimum
amount,
the
minimum
amount
of
communication
that
certain
changes
need
to
make
just
to
ensure
that
everyone
kind
of
knows,
especially
like
end
users,
if
it
impacts
end
users
or
something
it's
like
they're,
not
reading
slack
they're,
not
reading
KW
yeah,
like
maybe
it's
working
with
the
comms
team
and
other
people,
so
yeah
I
was
just
thinking
of
incorporating
that
into
the
graduation
criteria
along
with
there's,
probably
other
things
that
will
come
up.
A
I'm,
not
sure
but
like
documentation,
seems
really
important.
You
know
like
okay,
you
have
this
new
process
and
it's
an
account.
But
did
you
update,
like
your
your,
like
big
docs
or
whatever
formal
docs
exist
like
that?
This
would
be
applicable
to
like
that
would
be
something
that
at
least
in
my
mind,
would
be
necessary
for
it
to
be
GA.
Even
if
the
ga
is
like
in
One
release.
A
I
would
want
to
see
if
you
know
the
pr
where
you
updated
that
somewhere
so
yeah,
okay,
cool
I
just
wanted
to
make
sure
I
wasn't
like
crazy.
Like
kind
of
with
this
idea,
it
seemed
good
at
the
time
with
it.
I
thought
it
might
have
been
bad.
A
So
that
was
the
the
main
thing
I
was
working
on
just
because
people
have
been
asking
for
it
and
it
seems
like
something
that
can
probably
get
done
in
the
next
I.
Don't
know
before
the
next
release,
and
that
would
be
a
nice
thing
to
have,
and
obviously
like
I,
don't
think
that
we're
creating
like
a
ton
of
rules
or
anything
but
I,
think
people
will
try
using
that
cap
instead
of
the
existing
Captain,
we'll
get
feedback
on
it
as
people
use
it
as
well.
A
Just
because
I
don't
think
the
apparent
cap
format
really
works.
Well,
so
yeah
does
anybody
have
anything
else,
I'm
totally
babbling.
Now
any
more.
C
A
C
A
C
Or
no
I'm
good
I,
just
so
long
to
listen,
I'm,
gonna
kind
of
Scamper
off
to
get
some
more
coffee
as
well.
I.
Think.