►
From YouTube: K8s SIG Docs Meeting for 20230404
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
Alrighty
hi
everyone
welcome
to
the
sigdox
community
meeting
for
this
day,
Tuesday
the
4th
of
April
2023..
My
name
is
Natalie
vlatzko
I'm,
one
of
the
co-chairs
for
sigdocs,
and
because
this
is
a
community
meeting
under
the
kubernetes
project
as
part
of
the
cncf
I
do
want
to
remind
everyone
that
we
abide
by
the
kubernetes
and
code
of
conduct,
which
generally
means
that
we
want
to
make
sure
we're
respecting
everybody
and
each
other
and
being
nice
to
another
and
cordial
and
also
being
able
to.
A
You
know,
follow
a
lot
of
the
different
meeting
etiquette
that
we
have.
So
if
you've
got
things
that
you'd
like
to
chat
about
in
the
agenda,
please
feel
free
to
put
them
in
now
and
feel
free
to
make
room
for
others
when
we're
speaking
about
different
topics
and
things
so
that
everyone
gets
their
say.
Big
thanks
to
everyone
for
coming
today,
I
see
Vitale,
you
said
hi
in
the
chat,
hello.
A
A
If
there's
anyone
new
on
the
call
that
wanted
to
say
hi
I,
don't
believe
that's
the
case,
but
I
will
just
double
check
if
we've
got
any
new
folks
that
want
to
say
hello
once
twice:
Thrice,
okay,
if
we
go
through
a
couple
of
the
updates
and
reminders,
this
is
a
great
reason
why
we
have
these,
because
Nate
found
out
that
he's
the
pr
angler
this
week.
Thank.
A
So
that's
great!
So
yes
Nate
you're
our
PR
Wrangler
for
this
week.
Thank
you
in
advance
for
for
jumping
in
there
and
then
we've
got
Anna
young
who's
going
to
be
doing
our
PR
wrangling
for
next
week.
A
I
do
want
to
note
for
everyone
on
the
call
that
the
week
after
that
is
kubecon,
so
we
won't
have
a
Wrangler
on
the
agenda
for
kubecon
and
the
week
after
would
have
also
been
another
meeting
that
we'd
have
a
zoom
for
Sig
docs,
which,
because
a
lot
of
us
who
usually
host
will
be
a
cubecon,
will
actually
be
canceling.
A
That
meeting
and
trying
to
do,
let's
say
a
slack
thread,
possibly
instead
I'll
go
ahead
and
be
doing
that
after
after
today's
call,
but
this
is
our
last
in-person
Zoom
for
just
a
little
while,
at
this
specific
time
frame,
okay
and
again,
I've
just
got
the
color
contact
information
in
there
as
well,
so
feel
free
to
use
the
information
there.
If
you
feel
like
there's,
been
a
violation
as
well.
Okay,
jumping
over
to
the
agenda
that
we've
got
and
I've
taken.
A
Some
of
this
information
from
the
recent
release
team
meeting
when
it
comes
to
1.27
I've
got
the
current
status
for
docs
as
green
question
mark.
Given
that
the
burn
down
meeting,
unfortunately,
Mickey
wasn't
able
to
attend
that
or
wasn't
there
and
so
from
last
week's
meeting.
Docs
are
green,
but
that
could
be
different
this
week,
given
that
today,
as
noted
by
Tim
in
the
release
docs
Channel
earlier
is
today,
is
the
docs
review
and
completion
deadline.
A
I
went
through
and
also
had
a
look
at
the
Milestone
that
we've
got
in
the
in
the
repo
and
we
are
waiting
on
a
lot
of
tech
review
and
just
a
general
kind
of
follow-up
from
PR
authors
after
reviews
have
taken
place
mainly
from
docs.
Actually
so,
I
just
want
to
note
to
anyone
that
for
folks
who
are
available,
I've
also
kind
of
chatted
with
Divya
as
well.
A
If
she's
going
to
be
up
early
tomorrow
morning,
her
time
to
help
out,
but
we
we
might
be
getting
some
pings
here
and
there,
as
reviews
are
slowly
going
to
be
coming
through
the
rest
of
everyone's
days
for
today.
A
Of
course,
you
don't
have
to
put
yourself
out
of
joint
if
it's
way
out
of
your
hours
chatting
to
mainly
the
European
folks
on
the
call
for
that,
but
yeah
I
just
wanted
to
note
that
today
is
that
deadline
and
let's
hope
we
can
get
a
bunch
of
those
those
docs
PR
through
yes,
Nate
got
your
head
up.
There.
B
So
as
the
as
the
Wrangler
this
week,
would
you
folks
prefer
me
to
focus
on
release
related
PRS
or
yeah?
Okay,
the
the
regular
other
types
of
PRS
can
can
can
follow.
C
A
Okay,
great
any
other
information
on
the
release
that
that
anyone
wants
to
kind
of
bring
up
or
that
we
should
note
here
for
the
meeting
today.
D
I
saw
that
Mickey
just
posted
there's
five
PR's
or
five
PR's
that
are
open
for
the
127
release,
but
there
was
around
10
this
morning,
so
I'll
have
to
check
on
that.
Okay.
A
Right
could
we
will
be
checking
I'll
just
pop,
that
in
here,
okay,
great
and
then
just
to
come
to
check
with
you
Tim,
but
for
Nate
on
the
kind
of
PR
Wrangler
side
on
top
of
the
kind
of
release
work
we'd
also
want
a
bit
of
a
focus
on
the
blog
too,
for
release.
Is
that
correct.
C
So
I
actually
hadn't
noticed
that
I
think
the
schedule
is
different.
This
time.
Maybe
it's
been
wrong
different
before,
but
we've
been
good
at
we've
been
you
know,
we've
been
tighter
on
saying
you
know
hey.
We
want
people
to
get
their
their
articles
ready
for
review,
but
actually
we
don't
just
want
people
to
get
their
articles
ready
for
review.
We
want
them
ready
for
merge
and
as
of
right
now,
I
believe
we
don't
have
a
schedule
for
when
the
Articles
will
go
out.
B
C
To
do
is
balance
the
the
effort
between
release
dot.
You
know
docs
for
the
release
and
blogs
for
the
release
and
and
sacrifice
documentation,
because
I
I
believe
that
the
documentation
on
day
one
needs
to
be
great
and
the
blogs
you
know.
So
you
don't
go
out
on
day,
one
like
if,
if
we
go
for
a
flurry
of
blogging
of
well
at
work
at
kubecon
and
and
and
the
first
blog
doesn't
go
out
until
day,
one
of
kubecon
we're
okay,
like
it's,
not
the
best
outcome,
but
that
would
work.
B
C
So
the
big
surprise
to
me
was
like
oh
we're
actually
supposed
to
have
not
just
a
doctor
ready
for
this,
but
the
blog
articles
are
in
theory,
all
done
today
and.
F
C
A
A
good
point
and
I
think
when
you're
speaking
about
the
schedule
as
well,
I
also
noticed
that
there
was
a
bit
of
questions
in
a
couple
of
the
channels
around
what
would
be
the
usual
Cadence
and
I.
Guess.
I
think,
just
to
make
sure
that
we
can
kind
of
clarify
that
for
everyone
who
should
be
deciding
that
Tim.
C
A
Right
yeah,
I
think
I
I
also
agree.
I
saw
a
team,
you
put
your
hand
up
too,
if
I
wonder,
if
that,
if
that's
that
kind
of
you
know,
micro
bit
of
information
is
missing
from
some
kind
of
maybe
handbook
for
the
release
of
the
docs
team.
That
may
be
something
that
we
can
like
think
about
needing
to
put
in
that
they
would
own
that
release
Cadence
and
the
release
decision
around
that,
but
yeah.
C
I
would
so
yeah
I'm
I'm
I'm,
when
I'm
reviewing
docs
on
X
release,
I
I've
been
so
far
big
on
accuracy
and
big
on
style,
as
in,
if
you're,
if
you're
putting
docs
in
no
matter,
if
it's
alpha
or
whatever
I
want
things
to
follow
the
stargard.
If
it's
going
to,
if
it's
going
to
stable,
like
I,
you
know
have
previously
insisted
on
on,
like
you
know,
doing
things
by
the
start:
guide
I
don't
really
want
to
merge
new
docs
that
are
not
in
the
following
us
down
right,
I.
C
Think,
exceptionally,
you
know,
I've
got
a
different
view
given
we're
not
where
we
want
to
be
and
I'm
Nate.
You
know,
I,
think.
Your
opinion
here
is
important.
I
think
that
the
group's
opinion
here
is
important
for
all
of
us.
What
do
people
think
about
going
an
electric
and
being
being
much
more
loose
on
style
and
even
things
like
punctuation
and
spelling
like
if
someone
has
misspelled
kubernetes
wrong,
but
they've
explained
the
new
feature,
I
think
you
know
we
might
want
to
just
say:
let's
merge
it.
A
I'm
in
the
same
boat,
in
the
sense
that
I
agree
that
as
long
as
there
is
a
follow-up
almost
straight
away
and
that
we're
communicating
in
the
pr
itself
that
we're
noting
that
there's
a
bunch
of
follow-up
that
needs
to
happen
here
to
actually
adhere
to
the
style
guide
and
et
cetera,
et
cetera,
I,
think
and
actually
putting
that
message
in
there
too.
A
Rather
than
doing
so
in
a
way,
that's
kind
of
silent
in
the
pr,
because
then
that
could
actually
set
a
precedent
for
us
being
a
little
LAX
on
those
guidelines.
Then
I
think
that's
completely
fine.
But
as
long
as
we're
communicating
that
intent
in
the
original
PR
and
then
in
the
follow-up,
then
I
think
follow-up
issue
or
PR
I.
Think
that
I'm
generally
okay
with
it
too
but
I,
think
there's
also.
It's
also
worth
figuring
out
what
that
line
is
of
acceptance
for
some
of
that
strictness
there
as
well.
A
You
mentioned
spelling,
but
if
they're,
if
they're
describing
generally
the
feature.
But
if
there
is
I
think
incorrect.
The
links
to
things
like
things
that
will
actually
confuse
or
confuse
users
or
not
be
clear,
like
they
should
be
a
line
that
we
that
we
set
specifically
there.
A
Yeah,
that's
a
great
way
to
put
it
we
can,
we
can
be
lacks
on
certain
style.
You
know
rules
but
not
lacks
on
accuracy.
I
think
that's
a
great
way
to
put
it
Tim.
C
Yes,
sir
I
agree
with
you:
you'll
take
their
nap
paraphrased
as
not
on
accuracy.
We
are
short
on
good
first
issues.
We
have
people
saying
where
are
my
good
first
issues,
I
want
to
work
on
that
and
merging
a
PR.
That's
not
right
is
a
good
way
to
generate
them.
Like
you,
you
know
someone's
misspelled,
kubernetes
wrong
like
and
it's
on
the
dev
1.27
branch
which,
which
is
a
bit
more.
You
have
to
tell
them
hey
it's
not
going
to
be
the
main
branch
or
whatever,
but
you
know
on
release.
C
You
could
make
a
note
and
say:
hey
I'm,
going
to
remember
to
go
back
on
release
day
and
father
thing
and
say:
hey
someone's
misspelled,
kubernetes.
Everyone
knows
how
to
fix
that,
and
so
it
kind
of
you
know
it
kills
two
birds
with
one
stone.
We
get
the
docks
done
and
actually
we
get
a
supply
of
first
issues
which
we
are
you
know
which
is
a
resource.
It's
it's
not
just
a
liability.
It's
a
resource.
C
F
I
wanted
to
say
something:
I'm
gonna
play
the
contrarian
here
and
we
have
to
have
correct,
spelling
I
think
it's
lacks
in
in
so
many
different
areas,
we're
putting
together
some
first
class
documentation
for
probably
the
most
important
open
source
project
out
there
and
I.
Don't
think
it's
too
difficult
for
a
tech
writer
to
question
themselves.
Hey
you
know,
did
I
spell
kubernetes
correctly.
F
You
know
I
mean
we
have
automated
tools
for
that
and
these
these
you
know
these
editors,
so
I'm
going
to
say
that
we
do
want
to
have
PR
authors
or
reviewers
double
check,
spelling
and
I
think
you
know
following
up
with
an
additional
issue,
or
what
have
you
just
creates
more
work
that
is
probably
more
work
than
requesting
that
the
that
the
author
is
sort
of
reviewers,
hey,
use,
correct,
spelling
if
you're
unsure
check
the
spelling.
F
I'll
I'll
seed
the
floor
to
to
Tim
I,
guess.
C
Like
so
this,
this
is
something
I
learned
as
a
tech
lead
from
Zachary
Sarah
Kalisa.
Actually
it
is
more
work
and
the
thing
is
that
it's
valuable,
so
it's
easier
if
you're
like
you,
know,
contributor,
to
merge
it
and
put
your
own
PR
and
fix
it
or
or
to
use
the
suggestion.
Api
and
auto
merge
and
it's
easier
to
say,
hey
you've,
misspelled
kubernetes.
All
of
those
things
are
easier
than
logging.
C
The
issue
and
saying
hey,
there's
a
good
first
issue:
it's
just
merged
someone's
missed,
not
kubernetes,
but
the
value
is
there
like
log
in
good.
First
issues
is
more
valuable
to
the
project
than
doing
the
quick
fix
that
you
know
as
a
maintainer
to
do
and
I
had
I
had
to
learn
that
it
wasn't
obvious
to
me.
I
was
doing
all
these
little
fixes
and,
like
oh
yeah,
you're
right,
we,
you
know
I'm
I'm,
doing
easy
work.
That's
not
useful.
I
should
be
identifying
that
this
is
easy
work.
A
I
think
I
I
actually
do
empathizers
with
your
point.
Chris
I,
I'm,
actually
kind
of
agree,
but
I
think
also
there's
this.
A
If
we're
talking
about
a
possible
point
that
we're
at
let's
say
today,
where
we
add
a
deadline
to
try
and
make
a
release
as
a
bunch
of
docs
that
need
to
go
through,
and
we
need
to
let
a
spelling
mistake
here
or
there
through
to
meet
a
deadline
like
what
would
be
the
better
decision
versus
generally
having
that,
as
we
can
always
let
us
selling
misspelling
mistake
through,
like
I,
think
on
a
case-by-case
business.
A
We
can
assess
that
as
a
decision,
but
not
as
a
general
rule
of
what
we're
willing
to
be
lacks
on
would
be
how
I
would
be
comfortable
with
that
kind
of
thinking,
as
opposed
to
saying
spelling
mistakes
are
always
okay
to
go
through
like
I
would
never
want
to
have
that
ever.
A
But
if,
for
some
reason,
let's
say
as
an
example,
the
pr
also
happens
to
be
in
a
time
zone
where
they're
no
longer
online,
and
there
is
a
deadline
to
be
said
and
there's
like
two
spelling
mistakes.
I
would
Ur
on
the
side
of
getting
it
through
and
then
filing
that
issue
straight
away
afterwards,.
F
Okay,
my
Counterpoint
would
be
if
we
create
sort
of
a
you
know,
a
LAX
shortcut,
that's
one,
and
then
what
comes
next
starting
to
crank
out
you
know,
chat,
GPT
texts
that
you
know
may
not
be
correct
correct.
So,
if
something's
misspelled,
that
means
to
me
the
reader's,
like
you
know
how
what
is?
Is
it
correct?
F
I
I
see
your
point
about
getting
at
least
something
in
there,
but
I
don't
know
if
it's
too
much
work
to
ask
for
correct
spelling,
I,
don't
know
I'm
sort
of
you
know.
I
always
do
it
myself
in
everything,
including
the
text
messages
so
I'm,
just
that
correct,
spelling
guy
but
I
see
your
point
now.
I'll
certainly
take
or
accept.
Certainly
what
the
the
group
decides
here.
B
So
it
so
I
think
spelling
is
one
thing,
but
I
think
I
think
I
think
I
tend
to
agree
with
you,
the
spelling,
it's
an
easy
thing
to
make
sure
that
we
get
correct,
but
I
think
I
think
that
other
parts
of
the
style
of
diet
are
maybe
a
little
less
obvious
like
what
what
what
things
like
do
like
where,
where
and
when
do
we
capitalize
pod,
for
instance,
things
like
that
I
would
want
to
get
correct
on
the
first
go,
but
I
think
may
be
able
to
slide
in
in
this
situation
so
and
I
think
I
think
it
goes
back
to
somebody
mentioned.
B
We
should
figure
out
what
it
is
that
we
can
be
blacks
on
and
I.
Think
I
tend
to
agree
that
spelling
is
maybe
not
but
certain
other
things,
maybe
and
I,
don't
know
where
we
would
have
that
conversation.
If,
if
it's
even
too
late
to
maybe
we're
running
up
against
the
clock
here,.
A
I
wanted
to
jump
in
vital.
That's
a
great
question,
I
think
from
the
chat
they've
mentioned.
How
will
a
reviewer
decide
how
LAX
they
could
be,
for
example,
to
allow
a
PR
to
merge?
Is
it
based
on
experience,
or
should
there
be
some
general
guidance?
Great
question
I
think
we're
now
trying
to
figure
out
what
general
guidance
would
be
even
I.
Think
that's
what
the
start
of
this
conversation
is
yeah.
Anyone
else
want
to
jump
in
on
thoughts.
There.
A
F
C
C
Maybe
vital
I,
don't
I,
think
I,
hope,
you're,
saying
your
name
right,
maybe
you'd
be
willing
to
file
an
issue.
I,
don't
know
what
track
you'll
get,
but
you
can
file
an
issue
and
find
out
to
like
to
make
to
track
making
that
Improvement,
because
there
is
a
review
guide
and
it's
not
clear
on
this
point
and
that
kind
of
process
Improvement
issue
is
actually
quite
valuable
to
the
project.
You
know
you,
you
improve
one
page
and
it's
nice
documentation.
You
improve
the
review
guide
and
you
all
the
pages
get
better.
A
That
was
a
great
question,
thanks
for
raising
it
and
I'll
pop
in
here
that
your
you're
willing
to
create
an
issue
to
help
us
figure
this
out,
basically,
so
that
we
can
get
a
bit
more
consensus,
but
at
the
same
time,
I
think
my
own.
My
own
small
view
in
terms
of
what
guidance
they
should
be
I.
Do
want
to
note
that
us
openly,
obviously
talking
about
here
in
the
meeting
but
creating
issue
to
possibly
talk
about
how
LAX
do
we
want
to
be
for
certain
things.
A
Even
that
introduces
a
little
bit
of
maybe
non-desirable
behavior
in
terms
of
getting
things
right.
First,
go
what
you
when
you
are
trying
to
put
PR's
in,
for
example,
spelling
and
things
that
should
be.
It
should
be
correct,
and
so
I
think
it's
important
for
us
to
frame
this
as
if
we
are
in
a
situation
where
we
must
meet
a
deadline.
A
For
example,
what
is
the
guideline
of
what
we're
willing
to
kind
of
look
at
I
think
we
have
to
frame
it
in
the
the
case
that
we're
willing
to
be
lacks
in
versus
just
a
general
guideline,
because
that
can
be
that.
That
is
that's
a
that's
a
line
I'm
personally,
also
not
willing
to
cross
there
in
terms
of
having
it
as
a
general
thing.
F
Hey
just
one
more
comment
for
people
to
think
about,
and
that
is
this:
one
shortcut
could
lead
to.
You
know
a
chat,
gbt
output
and
then
you
know
other
things.
You
know
I
just
think.
If
we
hold
the
line
now
and
hey
it's
not
too
much
to
just
do
a
spell
check
or
something
then
we
can.
You
know
we
can
again.
You
know
protect
ourselves
from
other
shortcuts
that
that
may
arise
that
all
may
have
to
do
with
hey
getting
something
quickly
in
there
for
a
release
date.
F
And
I
bring
that
the
reason
I
bring
that
up
is
you
know
in
in
some
goofy
letters
you
know
separate
from
any
Tech
writing
we're
starting
to
see
folks,
you
know
crank
out
chat,
GPT
out
outputs.
A
Yeah
I,
don't
know
you
may
not
know
this
Chris
also
saw
you
note
there
Nate.
A
So
thanks
for
letting
us
know,
you
have
to
drop
we'll
see
you
in
the
in
the
slack
Channel
soon,
but
a
small
story
for
you
to
know
that
we've
actually
in
the
localization
side,
a
long
while
ago,
had
Italian
docs
that
were
done
by
a
Google
translate,
and
it
took
us
a
long
time
to
catch
that
so
to
speak,
because
also
there's
a
lot
of
that
work
that
is
based
on
trust
and
US.
A
Trusting
that
folks
are
indeed
fluent
in
the
localization
that
they're,
representing
and
working
on.
So
we've
definitely
had
that
happen
before
when
the
software
I
would
say,
wasn't
as
Advanced.
Let's
say
as
it
is
as
it
is
now
so
then
it
would
have
been
easier
to
let's
say
figure
out
as
opposed
to
current
current
work
in
that
field.
So
I
I
agree
with
you
as
a
general
thing
in
localization.
A
This
is
also
something
that,
in
our
docs,
we
also
say
we're
happy
for
translations
as
a
a
translation
kind
of
services
and
Bots
to
be
used
to
help
with
the
start
of
work.
But
human
review
is
actually
required
to
kind
of
finish
and
review
and
and
specifically
look
at
look
at
documentation,
so
keeping
that
standard
for
all
docs
is
definitely
something
that
is
not
going
to
go
away.
A
So
I
wanted
to
just
Echo
that
I
I
I
I
also
feel
what
you
fear,
and
we
kind
of
do-
have
to
stay
original
and
making
sure
that
a
lot
of
the
machine
translation
stuff
doesn't
come
in
without
any
kind
of
human
review.
Generally.
A
All
right,
just
following
the
chat
here,
sorry
definitely
can
be
used,
unfortunately,
not
so
in
a
not
great
way
on
the
University
side.
A
Yeah
thanks
for
thanks
for
adding
in
the
Star
Guide
too,
on
the
spelling
front,
there
Chris
as
well
any
other
outside
of
a
couple
of
links
that
I
add
into
the
I'll
add
into
the
agenda
here.
Any
other
notes
on
this
specific
topic.
A
All
right
I
do
want
to
get
us
through
the
rest
of
our
agenda,
which
is
this
short,
but
we're
at
the
issue
in
PR's
area
of
which
none
are
listed,
but
I
do
want
to
make
sure
that
we
are
looking
at
any
that
we
need
to.
Does
anyone
have
any
issues
or
peers
they'd
like
to
address
now.
A
No,
no,
no
okay
looks
like
no
fine,
then.
The
couple
of
discussion
points
that
I've
put
on
here
is
more
of
an
FYI
for
everyone.
Under
the
discussion
area,
our
seek
docs
annual
report
submission
has
all
been
reviewed
and
finalized.
So
that's
that's
gone
in
I
want
to
let
everybody
know
we
put
in
some
information
there
as
a
note
around
our
desire
to
create
this
issue,
Wrangler
role
that
we
had
kind
of
put
information
together
on.
That's
still
something
that
we're
looking
to
try
and
keep
working
on.
A
The
katakoda
removal
was
also
a
tutorial.
Removal
and
shutdown
was
also
noted
in
there
too,
as
well
as
your
great
work,
Chris
and
Tim
around
the
mermaid
diagrams
that
we've
put
in
as
well.
So
that's
all
in
on
the
annual
report.
A
We
I'm
still
needing
I
still
need
to
double
check
on
the
schedule
in
terms
of
when
that'll
actually
be
available,
I'm,
not
sure
if
anyone
in
the
call
knows
I'm
hoping
it
is
during
kubecon
but
I
think
that's
still
TBD
on
that
one
yeah
and
then
speaking
of
qcon,
that
Segway
our
cdocs
project
update
at
kubecon.
A
In
terms
of
the
small
video
update
that
we
submitted,
that
I
am
begrudgingly
recorded
myself
is
we
focus
specifically
on
localizations,
where
we
called
out
the
localization
sub
project
being
all
official
and
created,
and
we
call
that
a
few
localizations
that
still
need
help
in
terms
of
reviewers
and
contributors.
A
I
want
to
note
here
that
the
localizations
I
called
out
were
Ukrainian
German,
polish
and
Hindi,
and
so
those
are
the
ones
that
we
focused
on
specifically
for
the
kubecon
EU
audience,
and
we
also
given
that
there's
been
renewed
interest
in
localization
I,
also
added
in
a
kind
of
an
FYI
that
folks
who
want
to
begin
localizing
a
beginner
localization
journey
to
be
kubernetes,
org
members,
and
so
we
added
that
in
our
update
as
well
and
then
finally,
I'll
maintain
a
track.
A
Talk
for
Sig
docs
will
take
place
on
Friday
on
the
Friday
of
kubecon
at
at
2
p.m.
This
does
clash
with
the
Sig
meet
and
greet
the
Sig
meet
and
greet
happens
until
2
30
p.m,
so
it
is
very
likely,
and
on
top
of
that,
Ray
lohano
on
the
call
has
a
different
seek
talk
at
the
maintainer
talk
at
the
exact
same
time,
so
we
will
only
be
represented
for
the
first
half
at
the
Sig
meet
in
Greek,
because
we
then
have
our
maintain
a
track
talk.
A
And
that
is
it
for
my
agenda
items.
Does
anyone
else
have
any
other
questions
or
discussion
points
they
wanted
to
bring
up
today.
A
We
will
have
some
PRS
likely
to
look
at
very
soon
for
the
release,
so
getting
some
of
that
time
back
would
be
great
once
the
annual
report
is
available,
I'll
also
link
it
for
everyone,
so
everyone
will
be
able
to
take
a
look
but
big
thanks
for
joining
us
today,
thanks
also
for
abiding
by
our
kubernetes
code
of
conduct
and
the
thanks
in
advance
for
everyone,
who's
helping
out
with
the
release
in
terms
of
getting
PR's,
reviewed,
blogs,
reviewed
and
all
of
these
merged,
we'll
be
seeing
you
in
a
few
weeks
time
after
kubecon
for
the
next
round
of
our
Zoo
meetings
thanks,
everyone.