►
From YouTube: Kubernetes SIG Docs Meeting 20210209
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
Cool
looks
like
we're
all
good
to
go.
Welcome
everybody
to
the
weekly
sig
docs
meeting
today
is
february
9th
2021,
it's
10
30
pacific,
I'm
jim
angel,
one
of
your
co-chairs
for
sick
docs
and
before
we
get
started,
are
there
any
new
contributors
joining
us
today.
A
This
week's
for
updates
reminders
are
this
week's
pr?
Wrangler
is
irvi
and
next
week.
Pr
wrangler
is
myself.
So
I'm
aware
that
I
will
be
upcoming
wrangler
and
I
will
assume
those
duties
quick,
funny,
side
stories.
I
thought
that
I
was
wrangler
this
week
for
some
reason
it
must
have
just
came
up
when
I
was
updating
this
agenda
last
week
and
I
was
like
shoot.
A
I
didn't
do
my
wrangler
duties
and
I
I
jumped
in
the
dock
today
and
I
saw
his
erv
and
it's
like
all
right
next
week,
I'm
going
to
be
on
it
starting
sunday,
so
you
have
my
word
for
it
here
and
as
a
little
bit
of
a
relief
when
I
when
I
saw
that
and
as
always
pr
wranglers
make
sure
you
know
your
shifts,
there
is
a
link
in
the
agenda
which
I
will
paste
into
the
chat
here
and
moving
on
to
the
release.
121
updates,
divi.
Are
you
here?
B
Yeah,
so
our
status
is
green.
On
the
dark
side,
the
integration
branch
is
healthy.
Last
week's
branch
sink
to
merge.
The
master
branch
with
the
dev
1.21
was
that
p
hours
merge
today
is
enhancements
today,
so
they're.
Currently,
I
think
they're
now
they're
69
enhancements
being
tracked.
I've
already
assigned
the
announcements
to
the
docs
team
members
and
in
the
next
few
weeks,
we're
coordinating
with
the.
B
Team
on
comms,
with
the
enhancements
owners
also,
we
have
one
doc
pr
already
merged.
So
a
review
is
from
tim.
Thank
you,
tim
tech
reviews
already,
two
tech
reviews
already
given
I
thought
chi
ming
also
gave
a
review
on
it,
so
we
have
one
down
many
to
go.
So
an
answer
freezes
to
end
of
today,
so
we
are
likely
to
get
a
few
more
in
and
that's
it
for
me.
A
D
A
Awesome
vivian:
do
you
want
to
mention
the
pieces
you
you
put
in
the
agenda.
D
Yeah,
so
there
are
a
couple
of
updates
from
mine
and
thanks
to
savitan
tim,
firstly
for
discussing
the
psp
deprecation
block
on
the
six
security
talks.
Call
after
you'll
have
had
a
conversation
with
matt.
I
guess
I'm
not
really
sure
of
the
link,
but
I
guess
and
are
already
in
talks
for
a
follow-up
blog
to
the
existing
one.
That's
there
as
a
pr
in
the
talks
in
the
agenda
doc.
D
The
second
set
of
updates
that
I
have
are
around
the
feature:
block
and
release
blog
delivery
and
review
process.
So,
after
a
lot
of
back
and
forth
over
a
chain
and
sig
release,
we
sort
of
narrowed
down
the
feature
blog,
as
well
as
the
release,
block
delivery
and
review
dates.
Those
are
listed
on
the
docks,
so
anna
actually
sent
out
the
very
first
comms
around
it.
I
mean
it's
not
really
a
comms,
but
it's
more
a
sort
of
hey.
D
This
is
the
first
sort
of
deadline
that
you
all
have
so
march.
1St
is
the
march
1st
is
the
first
date
so
go
starting
this
process
starting
the
cycle.
We
are
going
to
have
an
opt-in
feature,
for
I
mean
opt-in
process
for
the
feature
blog,
which
means
that
we
don't
go
around
asking
people
hey.
Do
you
want
to
blog
for
your
particular
feature?
D
Instead,
we
actually
give
them
access
to
a
particular
sheet
which
I'm
yet
to
create
I'm
aware,
but
we
give
them
access
to
a
particular
sheet
and
have
them
list
down
whether
or
not
they
want
a
feature
block
for
that
particular
for
that
particular
enhancement.
Now
this
needs
to
be
done
by
march
1st.
That's
the
first
deadline,
then
marched.
25Th
is
the
date
when
the
release
comes
lead
and
that's
me
and
my
team
will
be
submitting
our
release
blog
for
review
from
you
folks.
D
So
that's
the
second
one
then
march
31st,
which
is
well
after
the
talks
are
merged.
I
guess
doc's
pr's
are
merged.
We
will
be
request.
I
mean
that's
the
deadline
for
the
comps,
the
comms
blogs
that
we
that
have
opted
in.
I
mean
the
six
that
have
alternate
for
flower
comms
blogs
to
actually
deliver
the
blogs
by
our
pr,
and
then
we
will
have
a
monday
wednesday,
friday
cadence
after
the
release
to
actually
publish
it.
D
So
this
this
was
a
process,
but
it's
not
really
pr
into
the
current
release
cycle
markdown,
which
is
there
on
gate
or
we'll
be
doing
that
over
the
next
couple
of
days,
and
there
will
be
more
details
coming
out
in
the
form
of
an
email
from
in
the
later
half
of
this
week
or
maybe
next
week
early.
A
D
D
That
would
be
great
because
I
wasn't
there
for
one
and
I,
regarding
the
feature,
blog
delivery
that
follows
this
one
not
feature
blog
the
blog
delivery
following
this
one,
this
pr
that
is
there
on
the
agenda,
I'm
not
aware
of
what's
the
thing,
so
I
would
not
be
able
to
do
complete
justice
to
what
they
have
discussed.
So
if
any
one
of
them
is
there
I'd,
rather
that
they
take
this
stage
and
explain
it
better.
E
I
can't
provide
it
just
hi
everyone.
It's
me
nawaz,
I'm
so
happy
to
see
you
all.
So
we
discussed
the
meeting
about
adding
a
seek
security
byline,
which
everyone
is
in
agreement
with,
and
there
was
also
a
conversation
of
having
a
follow-up
blog
to
talk
about
user
perspective
on
other
alternative
solutions
and
stuff,
and
they
have
been
some
volunteers
and
we
just
captured
them.
E
E
All
right
all
right,
so
that's
where
it
stands
now,
so
I
I
will
poke-
or
I
will
just
in
the
next
call-
maybe
I'll
just
bring
it
up
and
ask
for
status
and
I'll
I'll
get
back
to
seeing
dogs
in
the
other
the
coming
week
after
that
meeting,
whenever
that
is.
A
Cool
anything
else
related
to
the
release
or
some
of
the
upcoming
communication
changes
or
dates.
A
All
right
not
hearing
a
ton,
I'm
gonna
actually
take
a
step
back.
I
saw
in
chat
there
we
had
do
have
a
new
contributor
mike
might
be
screwing
up
the
last
name
here.
Togarin
togeran
feel
free
to
correct
me.
If
I'm
wrong
there,
a
few
actually
I've
seen
you
before
here
you're,
not
new
yeah,
I'm
not
new,
but
I'm
not
a
contributor,
yet
gotcha.
Well,
we're
happy
to
have
you
happy
to
help
out
like
we
tell
everybody
is.
A
A
Thank
you,
you're
welcome,
yeah
and
anyone
else
who
has
joined
since
we
got
kicked
off
here
this
new
contributor.
That
cares
to
introduce
themselves.
A
Awesome
thanks
nice
to
meet
you
jilton.
There
is
also
a
sig
docs
localization
meeting
that
happens
once
a
month
that
is
going
to
be
relative
to
all
the
localization
efforts
and
trying
to
come
under
one
roof.
That's
led
by
brad
tofu
is
also
on
the
call
here.
I
don't
brad.
You
want
to
mention
a
little
bit
about
that
meeting
and
and
a
little
bit
more
about
it.
I
guess
oh.
C
Absolutely,
and
and
welcome,
mike
and
and
and
gelton
we
meet
once
a
month,
the
different,
the
different
localization
teams
to
share
tips
and
tricks.
There's
a
couple
different
approaches
for
for
for
how
to
handle.
You
know
the
translation
and
you
know,
staying
in
sync
with
the
the
english
version
and
so
helpful
tips
and
tricks-
and
you
know
hopefully
I'll
put
the
I'll
put
in
the
link
to
where
you
can
find
more
information
on
that
on
that
meeting.
But
we
just
meet
once
a
month.
C
We
have
our
own
slack
channel
and
you
know
great
great
way
to
learn
more
about
the
the
translation
localization
process.
A
A
A
All
right
once
again,
not
not
a
ton
going
on
we're
flying
through
the
agenda
here.
This
is
this
is
moving
along
quickly
on
the
discussion
area,
abby
continued
from
last
week,
tracking
still
content
the
repo.
This
came
up.
We
had
a
great
discussion,
it
went
up
until
the
time
and
I
felt
like
we
still
had
more
to
discuss.
Maybe
we
don't,
but
if
you
don't
want
to
give
in
a
quick
recap
of
what
we
talked
about
last
week
and
we
can
go
from
there.
H
Yeah
sure
so
this
is
a
project
that
we're
trying
to
get
up
and
running
to
track
the
still
content
on
the
website,
and
that
is
basically
how
we
want
to
do.
That
is
to
get
a
script
that
will
check
the
repo,
the
the
documentation
section
of
the
repo
and
sort
of
check,
things
that
haven't
been
updated
in
about
a
year
or
so
more
and
we'd
like
to
roll
this
into
the
the
the
each
of
the
release
cycles.
H
So
the
stocks
lead
for
the
release
will
be
able
to
run
the
script,
to
get
sort
of
the
output
of
what
stale
make
a
github
issue
and
then
sort
of
work
with
different
things
to
get
that
content
either
updated
if
it
needs
to
be
or
somehow
removed,
which
will
have
a
lot
of
other
caveats
of
making
sure
things
aren't
removed
without
obviously
making
sure
people
aren't
using
it
anymore,
and
it's
really
no
longer
needed,
and
so
I
think,
last
week
we
talked
a
lot
about
different
ideas
of
things
that
could
be
implemented
and
there
is
a
link
in
the
doc.
H
If
you
want
more
suggestions,
this
is
sort
of
like
we're
just
putting
this
out
there
to
this
is
the
first
stop,
so
that
we
obviously
need
a
lot
of
communication
between
all
the
different
things,
and
you
know
sig,
release
and
everything.
So
this
is
sort
of
the
first
stop
to
get
ideas,
and
what
I'd
like
to
really
get
out
of
the
conversation
from
today
is
some
ideas
around
what
an
mvp
and
could
look
like,
and
what
sort
of
our
first
steps
poc
could
be.
H
I
thought
I
had
some
ideas
in
the
google
doc,
which
I
honestly
just
came
up
with
five
minutes
before
this
meeting,
so
they're
not
well
thought
out,
you
could
say
so
they're,
definitely
just
sort
of
ideas
of
what
more,
along
the
lines
of
what
I
like
to
get
and
that's
sort
of
within
an
mvp
like
make
sure
we
have
a
communication
plan
and
how
we're
gonna
roll
it
out
and
get
some
buy-in
from
at
least
sig
release,
because
we'd
have
to
take
some
resources.
H
Resources
from
the
release,
stocks
lead
to
work,
work
on
this
project
with
us
and
then
start
building
awareness
in
the
sig
docs.
Not
sick
dogs,
because
we're
sick
talks,
but
the
other
things
to
talk
about
that.
This
project
is
coming
up
and
then
sort
of
identify
one
or
two
cigs
that
we
could
participate.
That
would
be
willing
to
help
us
in
a
poc
to
sort
of
figure
out.
H
This
process
is
gonna
work
and
then
obviously,
coming
up
with
a
script
is
something
we
need
for
an
mvp
that
at
least
checks
things
in
the
repo
and
whatever
the
criteria
is
based
on
last
commit
date
or
if
there's
other
things
we
need
to
add
in
there
and
then
the
I
mean
the
goal,
I
think
will
be
getting
this
up
and
running
and
like
a
small-scale
poc
with
the
identified
things
that
are
willing
to
participate
in
the
next
release
cycle,
which
I
think
is
122,
but
I
like
completely
blanked
on
what
release
cycle
we're
actually
on.
H
So
please
let
me
know
if
that's
a
different
number,
so
those
are
sort
of
things
I
had
as
an
mvp
ideas.
But
if
you
guys
have
any
ideas,
if
you
all
have
any
ideas,
let
me
know
I
kind
of
went
through
that
quickly.
I
think
I
think
a
lot
of
people
were
on
this
call
last
week,
so
I
kind
of
went
quickly
through
the
project
scope.
I
Hey
yeah,
I
was
taking
a
look
at
building
the
script
and
running
that
just
locally.
One
thing
that
it
looked
like
was
that
the
commit
date
or
the
last
commit
date
might
not
be
the
best
criteria
on
its
own.
I
I
can
link
to
the
script
that
I
came
up
with
and
I
can
I
can
potentially
put
up
a
draft
pr
for
it,
but
the
the
files
that
were
being
identified
by
this
script
were
mostly
glossary
files,
with
the
exception
of,
I
think
there
were
four
additional
files,
including
the
cube
control
commands
like
hugo
short
codes.
That
sort
of
thing,
so
I
don't
know
if
it
would
be
helpful
to
maybe
outline
additional
criteria
for
identifying
what
would
be
the
the
stale.
H
Documents,
I
think
so
thank
you
for
doing
that.
That's
really
helpful.
I
haven't
had
a
chance
to
actually
test
anything
in
the
repo
to
get
anything
else,
so
I
think
that's
really
helpful
feedback.
I
know
tim
had
mentioned
last
week
about
going
through
old,
er
content,
older
github
issues
to
sort
of
identify
things
that
probably
should
need
refresh
based
on
the
issues
that
haven't
been
touched
in
a
while.
So
that
could
be
another
criteria.
H
F
Some
files
we
have
reviewers
and
we
could
look
for
what
what
the
it's
a
bit
hard
to
work
out
from
the
api,
but
we
could
look
at
when
any
of
those
reviewers
last
reviewed
a
pr
on
that
file,
which
was
probably
going
to
be
for
a
lot
of
things.
You
know
2015
or
something
a
long
time
ago,
but
it
does
give
you
a
clue.
A
Yeah,
I
I
know
that
we
talked
a
little
bit
about
potentially
leveraging
things
like
front
matter
and
the
whole
issue
with
that
is.
It
doesn't
exist
today
so
like
getting
to
the
state
where
we
do
have
that
data
to
leverage.
A
I
almost
wonder
if,
if
it's
possible
to
narrow
down
the
scope
for
what
we're
scripting
again
so
like
alright,
if
it's
a
glossary,
maybe
that
gets
shelved
or
ignored
in
the
script
or
if
it's
you
know,
we
ran
into
a
few
pages
that
are
older,
maybe
less
critical
and
we
find
out
those
sub
areas
or
subfolders
that
are
more
critical
to
you
know
remain
fresh
if
you
will,
but
I'm
almost
wondering
if
long
term,
it
makes
sense
to
start
including
a
full
page
review
date
in
the
front
matter
as
some
of
our
prerequisite
of
merging
a
pr
to.
A
I
think
it's
a
little
bit
of
busy
work
in
my
own
opinion,
just
because,
if
you
know
you're
putting
extra
burden
or
extra
work
on
the
contributors,
but
if
we
did
have
front
matter
of
the
last
time
the
page
is
fully
reviewed.
It
could
eliminate
some
of
the
you
know,
leverage
that
we
have
to
move
to
actually
make
the
script
work
and
be
effective,
but
but
open
for
other
folks's
thoughts.
Here
too,.
F
Tim,
I'm
going
to
come
right
back
and
say
we
can
prioritize
based
on
analytics
and
say
stuff,
that's
in
the
top
20
pages
that
are
popular,
that's
english,
that
doesn't
have
a
review
date
set
yet
and
where
one
of
the
six
involved
is
on
our
list
of
six,
that's
probably
only
three
pages,
that's
an
mvp!
I
think.
H
Yeah,
I
definitely
agree
keeping
cut
to
us
a
very
small
mvp,
to
kind
of
prove
that
what
we're
doing
makes
sense
and
then
also
like
get
a
little
victory
happening.
So
we
can
all
like
feel
good,
because
this
is
definitely
a
very
massive
project
and
has
the
potential
to
be
very
exponentially
big.
So
that's
why
I
want
to
try
to
get
something
small,
so
I
think
that's
a
really
good
idea
to
sort
of
use
the
analytics
as
like
an
initial
pass,
and
my
other
comment
with
adding
the
reviewers
front
matter.
H
A
Yeah
yeah,
I
would
agree
with
that
and
and
to
the
the
first
point
about
this
overall
kind
of
this
can
be
a
big
monster
to
muster
of
a
burden
to
take
to
take
on,
and
I
would
hate
to
see
this
get
bogged
down
in
politics
and
opinions
and
and
really
I'd
hate
to
see
this
lose
momentum
based
on
you
know
more
or
less
bike,
shutting
on
it
and
I
would
lean-
or
you
know
I
guess
I
would
I'd
be
more
apt
to
to
see
any
sort
of
progress
in
the
sense
of
you
know.
A
A
You
know
creating
that
script
or
the
initial
steps
there
it'd
be
great
to
see
what
we
can
do
to
to
generate
that
into
more
of
an
mvp,
and
if
there's
anything,
I
can
do
to
help
out
whether
that
be
generating
a
report
from
analytics,
whether
that
be,
we
change
some
of
the
requirements
for
front
matter
for
reviewers
to
follow
when
looking
at
pr's,
I
mean
things
like
adding
in
a
date
of
when
a
page
is
updated
in
front
matter,
almost
doesn't
harm
anything
at
all.
A
To
begin
with,
if
we
were
to
say,
okay
reviewers
is
required
to
add
a
date
in
the
front
matter
of
when
the
page
is
fully
reviewed.
He
has
a
little
bit
of
busy
work,
but
but
we're
not
going
to
change
the
site's
content,
there's
not
really
much
to
push
back
on
other
than
the
active
enabling
it.
So
I
would
be
completely
for
seeing
folks
encourage
that
type
of
behavior
and
maybe
at
some
point
it
becomes
more
of
a
formal
requirement
than
hey
nice
to
have
no
nudge
approach
and
sorry
tim.
F
A
Yeah,
I
don't
think
blockade's
gonna
be
the
the
best
way
to
win
people
over
with
this,
but
I
do
think
that
we
could
begin
asking
and
formalizing
what
it
looks
like
to
include
that
front
matter
in
a
page
kind
of
like
how
we
deal
with
squashing
prs
right
now.
A
For
those
that
don't
know,
we
request
folks
who
are
reviewing
a
pr
to
squash
it
before
we
merge
it
in
the
event
that
they're
unable
to
timing
is
of
the
essence
or
just
pure
pr,
velocity,
sometimes
we'll
apply
a
label
that
will
squash
the
pr
automatically
before
merging
it.
We
like
to
have
the
folks
who
create
the
pr.
Do
the
squashing?
A
It's
a
good
skill
to
have
it's
a
good
skill
to
know
at
the
same
time
we're
balancing
that
line
of
folks,
who
might
not
be
a
traditional
developer,
who
want
to
merge
in
their
code
changes
or
their
docs
changes
as
code,
and
we
don't
want
to
be
the
blocking
process
because
they
can't
merge
or
can't
squash
a
pr,
and
so
maybe
not
the
perfect
example,
but
that's
an
example
of
where
it's
kind
of
up
to
the
user.
The
approver's
judgment
when
reviewing
the
pr
of
what
goes
through
and
what
doesn't
you
know?
A
Is
it
really
quick
to
add
that
front
matter
it
might
be
worth,
including
as
part
of
the
review
criteria
and
then
start
to
formalize
that
with
other
reviewers
and
approvers,
but
initially
that
still
might
even
be
putting
the
cart
in
front
of
the
horse.
I
still
think
we
just
need
to
you
know.
A
I
said,
maybe
opening
up
an
issue
of
what
the
plan
of
attack
is
maybe
sending
out
the
communication
emails
like
I
said:
we're
not
gonna
ever
hurt
ourselves
by
over
communicating
this
change
and,
as
we've
seen
just
internally
with
sick
docs.
There's
a
lot
of
discussion
to
be
had
around
this
topic
for.
A
Sure
cool
any
other
thoughts
around
the
the
still
content
initiative.
F
Is
that
a
half
questions?
It's
me
again,
I'm
gonna,
I'm
gonna,
take
it
for
a
moment
yeah.
I
think
we
could.
I
reckon
we
could
use
some
lightweight
tooling,
the
kind
of
thing
to
say.
If
you're
gonna
set
a
review
a
reviewer
front
matter,
it
either
has
to
not
be
there.
It
has
to
look
like
this
format
and
that
will
be
a
failure.
F
So
if
it's
there,
it's
valid
that
kind
of
lightweight
thing
I'm
interested
in
what
people
on
the
call
feel
about
that.
Does
that
does
that
seem
like
useful,
or
is
it
too
early
for
that
kind
of
checking.
A
I'm
for
the
idea,
I
think
it
might
be
a
little
early,
but
there's
nothing
stopping
us
from
starting
getting
those
pieces
in
motion,
especially
if
we're
talking
about
more
of
a
default,
approve
and
fail
on
an
incorrect
format
or
date,
that's
approved
or
in
correct
format.
A
But,
like
I
said,
I
really
think
communication
opening
up
issues
with
plans
of
attacks
is
really
going
to
be
the
next
steps
here.
If
we
have
a
pr
in
flight
to
start
enforcing
things
like
this,
you
know
just
saving
some
work
down
the
road.
In
my
opinion-
and
I
guess
abby,
do
you
have
everything
you
need
or
feel
comfortable
moving
forward
with
this,
at
least
with
the
information
we've
gathered
the
past
couple
weeks.
A
H
Yeah,
I
think
I
have
a
lot
of
good
ideas
based
on
the
conversations
we've
had
of
what
to
look
like.
I
want
to
try
to
get
a
real
formalized.
You
know
formalize
as
much
as
possible
sort
of
mvp
and
then
maybe
move
it
into
an
issue.
If
that's
the
best
place
for
it
in
the
repo
and
open
it
up
and
sort
of
at
least
have
it
there,
so
we
can
kind
of
point
people
to
it.
H
So
if
that
sounds
great
to
everyone
here,
that's
probably
my
next
step
is
to
formalize
things
into
an
issue,
so
we
can
kind
of
raise
awareness.
How
I
do
have
a
question
about
how
analytics
is
run.
Is
that
something
that
you
have
to
you
have
to
hand
out
like
it's
not
available
to
everyone
right?
If
you
just
run
the
reports.
A
Access
that
we
give
by
default,
we
try
to
make
it
public,
but
there's
issues
with
making
google
analytics
data
public
based
on
how
you
can't
basically
click
a
button
saying
view
all
my
analytics
for
whatever
reason,
and
so
that
was
the
issue
there.
But
if
anyone
requests
access
to
our
our
analytics,
we
give
them
access.
Contributors
have
open
access,
there's
really
no
confidential
data
in
there
other
than
the
page
report.
So
I'm
happy
to
give
you
access
as
far
as
generating
reports
and
pdfs
and
things
of
that
nature.
A
A
H
A
Cool
all
right
moving
on
the
last
piece
of
discussion
we
have
here
is
our
quarterly
review.
In
this
case,
we
normally
will
do
a
review
of
a
single
quarter
and
we'll
start
planning
for
the
next
quarter
between
the
holidays,
the
winter
holidays
and
the
new
year.
We
kind
of
didn't
get
right
on
the
the
q4
review,
q1
planning,
so
with
q2
right
around
the
corner.
A
What
we're
gonna
do
is
hold
a
q4
review
and
then
we're
gonna
kind
of
squish
quarter
to
one
and
quarter
two
and
one
quarter
we're
gonna
plan
for
the
remainder
of
q1
and
trickle
into
q2
there.
So
I
apologize
for
the
alphabet
soup,
of
the
invite
that
says:
q1,
slash,
q2,
whatever
review
meeting,
but
that's
how
we
got
here
and
what
we're
gonna
do
on
a
february,
the
18th,
which
is
5
p.m,
pacific,
we're
going
to
review,
quarter
4
and
then
talk
about
what
we're
going
to
do
with
the
remainder
of
q1
and
q2.
A
A
I
can
always
use
more
bodies,
more
ideas,
more
opinions
and
help
deliver
on
some
of
these
objectives.
So
if
you've
been
really
chopping
at
the
bit
to
accomplish
something
a
little
bit
wider
than
some
of
the
pr's
that
we
see
in
flight
in
sig,
docs
or
if
you
want
to
jump
on
an
existing
project.
Those
are
that's
going
to
be
a
great
time
to
really
talk
about
that.
So
that's
really
all
I
had.
Is
there
any
questions
about
the
quarterly
planning
why
we
do
what's
going
on?
A
A
Cool
not
hearing
a
ton
of
feedback,
not
a
bad
thing.
Hopefully
I'll
see
a
lot
of
y'all
at
the
quarterly
planning.
I
know
it
can
be
late
or
really
early,
depending
on
where
you're
at
in
the
world
try
to
make
sure
it
suits
everyone's
time.
For
sure
and
that's
all
I
had
for
the
agenda.
Does
anything?
Does
anyone
have
anything
else
they
would
like
to
discuss.