►
From YouTube: K8S SIG Docs Meeting for 20220308
Description
For more info see https://git.k8s.io/community/sig-docs
A
Hey
folks
welcome
everyone.
Welcome
to
the
Sig
docs
meeting
bi-weekly
Zoom
meeting
on
today
is
March
8th,
2022
I'm,
your
host
Ray
lojano
I,
do
want
to
remind
everyone
that
we
are
an
official
kubernetes
sick
meeting,
so
we
do
by
by
the
cncf
code
of
conduct,
which
boils
down
to
just
to
be
nice
and
be
excellent
to
each
other.
So
anyway,
I'm
going
to
share
my
screen
here
share
the
meeting
agenda.
I
should
probably
link
this
in
the
chats.
A
Start
off
with
any
new
contributors
or
any
new
attendees
to
this
meeting,
if
you'd
like
to
introduce
yourself,
please
go
ahead.
B
I'm
new
attendee
to
this
meeting
I
had
an
agenda
item
to
introduce
myself,
but
I
can
do
it
here,
too.
I'm
Mark,
Rossetti
I'm,
the
co-chair
for
Sig
windows
and
I
do
most
of
the
doc
updates
for
Windows
related
changes
and
wanted
to
discuss
some
bigger
changes
too.
Here
so
yeah
hi.
A
Welcome
mark
s
once
anyone
else
pick
it
off
and
layer
faces
there
are
faces.
We
haven't
seen
in
a
while
all
right,
updates
and
reminders.
This
week's
PR
WR
Wrangler
is
Taylor
only
Dole
and
next
week's
PR
WR
Wrangler
is
Victor.
Aka
Pi
Victor.
Please
make
sure
to
sketch
to
to
check
the
schedule
for
your
PR
Wrangler
shift
as
well.
Let's
start
off
with
the
release
for
the
agenda
with
the
release:
1.24
Chris
negus.
C
Yeah
our
status
is
green,
has
not
been
much
movement
since
our
last
reporting,
our
next
deadline
coming
up
is
March
31st,
which
is
a
deadline
to
have
the
placeholders
for
the
place
of
the
PR's
all
in
place,
as
as
note
says,
there's
been
some
discussion
about
trying
to
get
maintainers
to
do
some
to
get
some
the
PRS
entered,
because
we
again
there
hasn't
been
much
movement
in
that
area.
C
Integration.
Oh,
so
there
is
an
easy
CLA
error.
Nate
can
probably
speak
to
that
after
I've
gone
through
the
the
basics
here
in
the
integration
brand.
C
Otherwise
our
our
we're
tracking
63
caps,
no
PRS.
Yet
for
52
of
them
we
have
drafts
for
six
of
them.
Two
are
ready
to
view
three
completed
and
five
no
docs
required.
Did
you
want
to
say
something
about
the
integration
Branch
Nate.
D
Just
again
we're
running
up
against
the
fact
that
easycla
is
now
a
merge,
blocker
I'm,
not
too
concerned
about
the
the
error.
I
just
need
to
go
in
maybe
talk
with
Mr
Bobby
tables
and
figure
out.
What's
going
on
going
on
there,
so
not
too
concerned,
but
I
wanted
to
bring
it
up.
A
Okay,
thank
you.
This
is
quite
a
big
release.
63
cups
tracked
so
far,
just
for
historical
context,
so
we
generally
do
not
get
a
lot
of
traction
for
docs
place
over
PRS
until
the
week
of
which
we
always
try
to
get
more
play.
Solar
PR
started
earlier,
but
it
tends
to
be
the
pattern
for
for
releases.
A
Yeah
I
also
want
to
make
a
note
that
we
do
plan
to
have
a
a
blog
post
on
a
removal
and
deprecations
around
March
31st
as
well,
and
also
another
blog
about
the
Dr
Shim
removal.
So
those
are
a
few
things
kind
of
attached
or
they
are
attached
for
the
release
that
are
also
up
and
coming.
C
A
C
The
doc,
a
lot
of
the
Dr
Shim
PR's
and
issues
are
not
also
tracked
as
part
of
our
release.
You
know,
so
those
numbers
don't
reflect
all
the
docker
shim
work
either.
That's.
D
That's
correct
one
of
the
things
I
was
thinking
about
this
time.
Last
cycle
we
went
from
Green
in
week
nine
to
yellow
in
week
10
because
we
had
about
this
many
PR's
without
drafts.
D
A
Yeah,
what
we
see
is
that
we
see
contributors
wanting
to
get
their
code
PRS
in
merged
before
they
start
on
a
doc
PR.
So,
even
though
it's
a
place
over
PR
and
it
only
takes
a
five
minutes
or
so
to
create,
but
that's
what
the
pattern
we've
seen
even
though
we're
going
to
Yellow,
we
might
go
to
Yellow
next
week.
It's
not
of
a
big
concern
yet,
but.
D
Yeah
just
to
Tim's
question
the
three
colors
for
docs:
it's
not
super
scientific,
but
essentially
it's
a
concern
level,
green,
yellow
and
red
red,
meaning
that
we've
got
a
potential
blocker
situation,
yellow,
meaning
that
we
are
starting
to
be
concerned
about
some
of
the
work
that's
being
done
and
green,
meaning
that
everything
is
is
moving
along
good
or.
D
Yeah
I'm
not
I'm,
not
sure
right
right
now,
I
I
think
that
the
the
blocker
concern
was
actually
the
dockershim
stuff
and
I
think
that
the
docker
shim
removal
work
has
actually
been
moving
along,
pretty
well.
I
think
that
it's
been
moving
along
better
than
the
the
rest
of
the
docs
work
and
I
think
that
is
because
of
the
community.
Here
saying
this
is
something
we
need
to
get
sort
of
done
so
in
terms
of
of
actually
blocking
like
the
whole
release.
I,
don't
think
any
individual
other
than
the
dockershim
stuff.
D
I
think
that
there
I
don't
think
that
there
is
any
individual
docs
cap.
That
would
block
the
whole
thing.
But
if,
if
we
got
to
a
point
where
we
had
several
or
a
significant
percentage
of
them,
because
they
they
will
block
into
if
they
don't
have
docs
in
that,
could
block
a
feature
from
being
a
part
of
the
release.
So
docs
aren't
that
important.
So.
A
Don't
think
anyone
else,
anyone
from
the
comms
1.24
team
is
here,
but
did
paste
the
links
to
the
removable
and
deprecations
tracking
sheets
as
well,
and
that's
going
to
be
used
for
the
removable
and
deprecations
blog,
also
the
feature
blog
tracking
sheet
as
well.
So
that's
in
the
agenda.
A
E
Well,
do
I
have
to
use
a
Google
sheet.
My
diagrams
are
broken,
not
broken,
but
there's
like
a
workaround,
but
people
don't
know
that.
There's
a
workaround,
so
they're
pretty
broken
and
I
want
to
call
this
out
really
as
a
thing
that
would
welcome
people
to
look
at
it
and
fix
it.
E
Hey
Tim:
do
you
have
a
a
PR
for
that
or
an
issue
I?
Well,
the
issue
is
linked
to
in
the
agenda.
I
can
stick
in
the
chat
as
well.
Okay
and
the
pr
is
something
that
the
person
who
works
on
it's
going
to
produce.
I
have
not
worked
on
this.
E
I'm
happy
to
give
people
guidance
on
how
I
how
to
work
on
it.
I
think
the
issue
actually
basically
has
the
germ
of
the
fix
it.
What
it
needs
is
the
attention
and
that's
why
I'm
mentioning
it.
F
It's
been
a
minute
since
I've
been
involved
actively
with
the
docs.
So
I
wonder,
is
there
what's
the
current
state
of
triage?
Is
there
any
need
to
go
through
and
triage
issues
that
haven't
my
God
English
I
do
English
for
a
living?
Is
there
any
need
to
go
through
the
issue,
backlog
and
triage
things.
A
Personally,
I
always
feel
like
there
is
a
need
to
triage
issues.
E
E
E
E
Ideally,
we
want
to
have
the
idea
that
someone's
actually
thought
about
prioritization,
whether
that's
to
say
well,
this
doesn't
really
need
a
prioritization
or
to
say.
Actually
this
is
an
important
issue
and
it
does
need
doing
if
you're,
a
kubernetes
member,
if
you're
a
reviewer
for
zigdocs,
if
you're
participating
in
sick
docs,
then
I
would
encourage
you
to
look
for
issues
awaiting
triage
and
to
help
out.
G
Yeah,
just
one
one
quick
thing:
I'll
add
too
and
Zach.
It's
awesome
to
see
you
here
great
surprise
for
today,
they're
looking
good.
G
What
I
think
we
could
use
a
lot
of
help
with
from
the
repository
from
a
repository
perspective,
is
really
I.
Think
there's
a
lot
of
old
stale
issues
that
that
lack.
Somebody
saying
we
need
to
take
action
or
close.
This
issue
and
I
think
that
that
could
free
up
a
lot
of
tree
as
issues
triage,
PR's
I,
think
you
know
it's
a
very
friendly
and
welcoming
environment.
G
Nobody
wants
to
play
the
I'm
going
to
close
your
issue,
role
and
I
think
that
that
would
be
a
huge
help
to
to
wear
that
hat.
If
you
do
have
some
bandwidth
to
take
a
look
at
that
stuff,
you
know
I
think
it's
always
worthwhile
to
you
know,
set
some
sort
of
established
deadline
of
when
you
can
close
something
and
then
clean
up,
because
I
was
looking
right
now
we're
around
1
210,
open
PR's
rotating
about
530
issues.
A
C
A
There
is
a
stale
there's
labels
secret
that
the
bot
adds
if
it
hasn't
been
touched
or
triaged
in
90
days,
I
believe
and
there's
three
levels
of
of
Stillness
I.
Don't
know
if
it'll,
officially
close
it
I,
don't
think
it
does,
but
I
think
it
adds
those
still
labels.
E
Is
that
correct,
yeah
piano's
got
a
long
grace
period
unless
you
actually
get
a
a
less
of
a
grace
period.
Yeah
I
think
something
like
180
days
of
completely
untouched
means
an
issue
closes.
We
have
a
label
for
that.
E
We
have
a
label
for
not
having
that
happen
which
is
frozen,
and
my
opinion
personally
is
that
we
should
be
fairly
liberal
with
frozen
anything
that
we
know
that
we
definitely
want
to
fix,
no
matter
what
we
should
freeze,
even
if,
even
if
it
takes
two
years
three
years
whatever
I
would
I
would
freeze
every
issue
that
we
we
we
don't
want
to
forget
about
now
again
my
opinion.
There
are
other
issues,
I've
opened
issues
and
they've
been
except
people
said.
E
That's
a
reasonable
thing
to
do,
and
they've
been
open
for
like
a
year
and
no
one
touched
it
and
then
it
closed
and
a
little
bit
of
me
a
little
bit
dies
when
that
happens,
but
that
you
know
the
whole
of
me
regenerates
and
goes
well.
Maybe
it
wasn't
that
important,
a
thing
to
file,
and
but
you
know,
the
project
moves
on.
F
So
not
to
immediately
jump
in
and
throw
an
elbow,
Tim
I,
don't
know
if
I
agree.
If
something
is
going
to
be
open
for
two
or
three
years
at
what
point
at
that
point,
it's
like
serving
as
a
form
of
documentation
really
more
than
a
set
of
priorities
right.
F
So
might
that
not
be
better?
Might
everyone
not
be
better
served
instead
of
having
to
negotiate
an
open
issue
list
to
find
out
what
long-term
priorities
are
to
instead
have
like
a
document
called
long-term
priorities
that
consolidates
them
nicely
and
if
you
want
to,
you
know,
really
have
the
best
of
both
worlds.
F
I
suppose
you
could
like
link
to
closed
issues
from
that
sort
of
centralizing
document,
so
I
guess
I
I
here
in
a
firm
that
that
issues
are
helpful
because
they
serve
the
purpose
of
visibility
and
that
they
serve
a
sort
of
documenting
purpose
in
the
record,
but
to
the
point
where
they're
staying
open
for
two
or
three
years
with
no
action.
F
That
seems
less
like
a
a
statement
of
priority
and
more
like
a
statement
of
this
is
a
hard
word
to
use,
but
and
I
don't
mean
it.
This
way,
but
neglect
because
it's
clearly
not
a
neglected
repository
but
I,
think
it
sends
mixed
messages.
So
I,
wonder
I
wonder
if
there
is
a
better
way
to
accomplish
the
goals
that
you
set
out,
to
which
I
think
are
are
noble,
good
and
right,
without
also
muddying
the
water
of
like
discoverability
and
a
well-curated
set
of
issues.
E
I'm
gonna
I'm
gonna
suggest
something
I'm
gonna
tell
you
what
you
know:
I've
imagined
what
might
come
about
if
we
took
if
we
took
Zach's
idea
and
and
move
forward
with
it
the
way
I'm
picturing
and
that
is
there'd,
be
maybe
two
or
three
pages
of
issues,
because
right
now
there
are
hang
on.
Take
a
click,
21
or
something
22
pages.
E
Maybe
two
of
them
are
important
to
have
open
right
now,
because
those
are
the
ones
we
prioritized
and
the
thing
is
people
don't
look
at
page
22
of
our
issues
list
to
find
things
to
work
on
so
I'm
imagining
a
world
where
people
do
look
at
the
end
of
that
list,
because
it's
that
short
that
at
best
the
important
long
longer
term
meteor
stuff,
is
on
page
two
where
people
might
well
look
how
we
get
there.
I'm
I'm,
something
along
the
lines
of
what
Zach
said
would
get
us
there.
C
Sometimes
the
issues
are,
you
know,
they're
things
that
are
important
but
they're
hard
to
do
and
they're
big,
and
maybe
there
would
be
a
way
to
consolidate
a
bunch
of
those
in
one
place
and
maybe
handle
them
in
a
separate
kind
of
meeting,
because
it's
really
easy
to
show
up
and
make
a
couple
comments
on
something
and
merge
a
PR.
But
it's
hard
to
do
some
of
the
bigger
ones
I'm
thinking
one
in
particular,
I
think
you
worked
on
this
one.
A
little
bit
Tim
moving
Cube
cuddle
docs.
C
We
have
a
bunch
of
cube,
pedal
docks
that
are
sitting
in
Sig
CLI
I.
Think
you
started
on
that.
That's
one
I
wanted
to
take
on,
but
it's
not
something
you
just
do
in
five
minutes.
You
know
to
move
that
all
into
the
into
our
docs,
but
if
we
had
a
list
of
like
bigger
things
and
like
somehow
had
a
group
of
people
who
could
be
accountable
for
those
bigger
things,
I
would
love
to
work
on
the
bigger
things.
But
you
know
I
forget
and
there's
a
million
little
things
that
you
can
do.
A
Yeah
I
I
was
actually
going
to
bring
up
that
4K
website
other
than
blogs.
We
don't
really
use
a
project
board
and
besides
the
dockershim
project
board,
we
don't
really
you
leverage
a
project
board,
but
this
is
something
that
we
might
have
and
might
be
a
good
place
to
have
have
a
long-term
priority.
So
we
could
always
review
bike
weekly
at
the
towards
the
end
of
the
meeting
or
even
an
async
on
slack
as
well.
E
That
sounds
like
a
good
thing
to
put
on
the
on
the
agenda
discussion
thing
that
you
what
you
just
said
right
all
right.
A
Actually,
this
is
something
I
could
take
on
and
start
a
project
board
I'll
see
if
I
have
the
rights
as
well.
If
not
I
will
think
others
I
don't
have
the
rights
to
create
a
project
board,
but
I
believe
that
this
is
a
good
central
place
so
that
we
could
look.
We
could
add
in
long-term
issues,
so
priorities
as
one
of
the
columns
and
and
review
it's
bi-weekly
foreign.
A
All
right:
let's
go
to
the
discussion.
Mark,
let's
see
condos.
B
B
I
can
provide
a
little
bit
of
context
and
then
I
do
have
like
one
or
two
questions,
and
then
we
can
maybe
keep
discussions
offline
or
keep
them
going
here
too.
So
I
just
dropped
a
link
into
the
chat,
most
I
would
say
a
lot
of
the
windows.
Specific
documentation
is
on
this
one
page
which
I've
dropped
in
the
chat.
B
There's
a
couple
of
issues
with
this
and
I
think
Tim
agrees
with
with
me
here.
He's
commented
a
lot
too.
The
first
issue
is
that
a
lot
of
the
kind
of
differences
are
details,
highlighting
the
differences
in
behavior
for
how
windows
and
Linux
work
is
in
this
page.
That's
in
the
docs
setup
production
subtree
of
the
website,
which
doesn't
really
make
sense,
there's
actually
not
a
whole
lot
of
information
about
how
to
actually
set
things
up
here.
B
The
other
one
is,
this
page
is
quite
large.
It's
overwhelming
for
users
or
people
who
are
new
to
kubernetes
and
are
looking
to
see
what's
supported
on
Windows
or
not.
It's
also
very
difficult
to
to
maintain
there's
a
lot
of
different
information
here
and
usually
even
small
PR's
end
up
with
a
lot
of
different
owners
or
like
a
lot
of
different
people.
Getting
tagged,
saying,
hey
is
this
piece
of
information
on
this
unrelated
section
that
it
wasn't
changed?
B
Is
this
up
to
date
not
up
to
date,
so
I
think
at
the
a
little
bit
of
context,
I
think
at
the
time
that
this
made
sense.
B
This
page
kind
of
went
into
the
website
around
1
12
ish,
which
was
so
Windows
support
and
kubernetes
went
GA
in
114
and
I
think
at
the
time
there
was
a
lot
of
less
familiar
familiarity
with
how
windows
workloads
work
in
kubernetes,
but
Windows
workloads
have
been
G8
since
114,
most
of
the
major
Cloud
providers
like
Rancher
eks,
AKs
gke,
all
support
Windows
workloads.
B
So
it's
becoming
a
bit
more
common
and
natural
here,
so
I
think
the
desire
from
Sig
windows
and
from
a
lot
of
other
people
is
to
kind
of
break.
This
page
up
take
a
lot
of
the
the
sections
that
are
specific,
are
saying
like
here's,
this
one
topic:
here's
how
it
works
in
Linux,
here's
how
it
works
in
Windows,
here's
what's
different,
just
move
those
differences
into
the
you
know,
docs
specific
to
that
to
that
topic.
B
So
this
page
does
cover
a
lot
of
things
it
covers.
You
know
networking
what
container
runtimes
are
supported.
What
API
fields
are
supported,
what
node
features
are
supported
and
everything
what
I
have
done
is
I've
created
a
big
issue
here
and
that's
the
one
that
I
linked
to
the
agenda.
B
That's
that
three
one,
four,
two
eight,
where
I've
kind
of
outlined,
what
I
think
a
good
restructuring
of
this
page
would
be
where
I
call
it
specific
sections
in
this
page
and
where
I
think
they
should
live
in
the
like,
where
we
should
move
those
sections
to
in
the
websites-
and
it
also
includes
a
couple
of
PR's
that
are
open
for
for
doing
that
and
then,
as
so
that's
one
of
the
big
goals
that
we
want
to
do
is
we
want
to.
B
My
question,
I
guess,
for
this
group
really
is:
what's
the
best
strategy
for
for
doing
this
and
plus
best
place
to
make
these
changes.
I
had
kind
of
initially
opened
a
bunch
of
the
PRS
against
the
dev124
branch,
because
I
think
that
as
a
consumer,
it
would
be
better
for
things
to
just
change
all
at
once
kind
of
on
the
release,
boundary
and
also
we're
planning
on
putting
redirects
and
like
breadcrumbs
whenever
we
move.
B
We
move
docs
out
to
as
opposed
to
doing
this
in
other
branches,
I'm,
not
super
familiar
with
the
branch
structure
and
the
release
Cadence
of
the
website.
So
that
was
my
one
question:
are
there
any
thoughts
or
concerns
about
doing
these
PRS
early
in
the
dev
124
Branch?
For
so
that
they
kind
of
go,
live
with
the
rest
of
the
dev
124
changes
and
yeah,
and
if
there
are
concerns,
what
are
what's
a
better
approach
to
take
with
this
I
see
Tim
was
raising
his
hand.
I
think.
D
Sure
so,
regarding
putting
it
into
the
one
two
four
branch
I
would
prefer
that
we
didn't,
because
the
one
two
four
branches
really
reserved
for
documentation,
changes
that
are
outlined
in
the
in
the
Caps
that
are
set
out
for
the
one
two
four
relief,
so
I
I
would
prefer
us
to
be
because
of
the
the
amount
of
work
that
one
two
four
is
already
turning
out
to
be
plus
all
of
the
dockershim
removal
stuff
that
can
hit
either
main
or
one
two
four
I'd,
rather
not
muddy,
one
two
fours
Dev
Branch
with
things
that
aren't
really
a
part
of
the
capital
part
of
the
part
of
the
release.
D
That
being
said,
I
think
that
you're
right
having
having
this
hit
all
at
once,
rather
than
for
a
piecemeal
I,
think
makes
a
lot
of
sense
to
that.
I
would
suggest
that
we
open
up
potentially
another
Branch
for
this
work
and
I'm,
not
sure
that
we
need
it
to
to
hit
with
a
release.
D
I'm,
not
I'm,
not
because
the
work
has
already
been
done
on
the
code
side.
It's
it's
not
really.
It's
not
really
a
release
thing
at
this
point
where
we're
trying
to
to
catch
up.
It
seems
like
so
those
are.
Those
are
my
thoughts
on
on
whether
or
not
we
should
use
dev124
and
I
noticed
in
your
in
your
issue
that
you
had
looked
to
put
the
the
Milestone
as
well.
D
E
Okay,
goodbye
Zach
I
will
I'll
go
next,
so
I
agree
what
Nate
said:
I'm
gonna
tweak
the
thing.
One
of
the
options
is
to
make
a
new
branch,
and
the
other
option
is
to
make
a
bunch
of
PRS
that
we
use
the
crow
hold
functionality
against
and
have
those
PR's
Target.
The
default
Branch
remain
and
then
you've
got
two
options.
E
E
Okay,
so
you
can
either
unhold
them
all
at
once,
which
is
probably
easiest
given.
We
have
prowl
giving
us
all
of
that
stuff
for
free
once
the
once
you're
ready
to
unhold
them
and
let
proud
sort
out
the
merge
order
or
you
can
octopus
them
together
into
a
new
PR
and
get
that
approved.
E
Both
of
those
would
be
fine
with
me
and
they
do
take
the
pressure
off
a
release
which
has
got
too
much
stuff
to
document
in
it.
Well,
not
too
much,
but
it
is
challenging
the
capacity
that
Sig
docs
has
to
document
it.
B
Yeah
I
think
that
makes
sense.
I
like
I
wasn't
like
I
I.
Do
think
that
it
would
be
good
to
have
this
land
all
at
once
and
I,
like
I
mentioned
before
I
I'm,
not
sure
the
release
get
into
the
branching
structure
of
the
website
and
I'm
definitely
going
to
defer
to
to
you
all.
For
that.
Whatever
makes
your
life
easier,
you
can
do
that
too.
I
do
the
one
and
one
slight
advantage
that
I
would
mention
with
the
dev124
branch,
is
a
lot
of
the
topics
in
that
page.
B
Do
get
updated
either
for
either
like
as
part
of
a
release,
because
we
go
and
update.
You
know,
feature
statuses
and
right
now.
They're
most
of
the
features
are
all
highlighted
on
that
one
page,
so
I
would
just
want
to
make
sure
we
coordinate
that
with
any
updates
that
are
going
into
the
120,
like
124,
specific
updates,
so
that
we
don't
accidentally
lose
information,
but
I
think
that's
that's
manageable
and
everything
too
I'm.
D
B
You
all
to
be
like
I,
don't
like
this.
This
page
is,
is
quite
old.
I
mean
it's
been
like
this
way
for
10
reasons
for
10
releases
I,
don't
I,
wouldn't
I'd
like
it
to
go
in.
You
know
sooner
rather
than
later.
If
we
do
need
to
flip
because
of
the
decor
shame
and
other
things
like
I
can
I
can
live
with
that.
But
there's.
B
D
I
wonder
if,
if
forking
off
of
because,
if,
if
you
want
like
I'm,
just
trying
to
think
if
you're
looking
to
make
sure
that
you're,
hitting
the
and
and
including
all
of
the
one,
two
four
changes,
I
think
you're
you're
always
going
to
be
chasing
that
regardless.
If
it's
going
to
be
one
two
four
one,
two
five
one,
two
six
you're
always
going
to
be,
which
is
why
I
think
Maine
is,
is
probably
a
good
spot.
D
But
if
you
want
to
Fork
off
of
one
two
four
every
week,
I
do
Branch
maintenance,
where
I
bring
main
into
one
two:
four,
which
sort
of
updates.
That's
the
the
part
of
the
the
integration
bench.
There's
a
link
up
in
in
the
in
the
release,
one
to
four
update
that
integration
Branch
gets
updated
weekly.
D
So
if
you
wanted
to
Fork
off
a
one
two
four
and
keep
updating
off
of
that,
that
might
be
a
way
of
helping
yourself
to
to
make
sure
that
you're
you're
catching
all
the
stuff
that
you're
afraid
that
you're
going
to
be
missing.
But
the
way
it's
it's,
it's
it's
going.
What
I'm,
I'm
really
hoping
is
that
all
of
the
updates
and
part
of
the
reason
we
do
the
this
maintenance
is
so
that
one
two
four
reflects
Maine
and
all
the
124
changes
when
it
hits
main
on
on
April
19th.
D
E
Oh
God
I
have
this:
you
could
have
your
work
ready
and
the
day
after
1.24
release
providing
there's
someone
who's
who's,
not
busy
running
around
dealing
with
a
Twitter
storm
or
whatever.
Just
imagine,
then,
if
you
have
that
ready,
if
you
do
what
Nate
has
just
suggested
and
you
base
off
1.2024,
then
when
that
merges
you'll
have
a
rebase
to
do
probably
I
would
guess
if
you've
got
PR's
open
you'll
have
one
rebase
to
do
for
every
PR.
E
So
if
the
people
doing
these
docs
are
comfortable,
rebasing
and
comfortable
with
like
fairly
Advanced
GET,
you
know,
like
medium
gift,
is
quite
hard
like
medium
Advanced.
Git
is
quite
a
quite
a
difficult
skill
to
acquire,
but
providing
people
can
do
that
things
like
rebasing,
then,
once
it
lands,
you
rebate
all
of
those,
those
hell,
PR's
and
they're
all
ready
to
go,
and
then
you
do
something
like
an
octopus
or
a
branch
or
whatever
you.
E
You
give
it
or
unhold
it
once
the
strategies
we
mentioned
before,
get
you
to
a
place
where
you
can
have
those
things
and
land
they
could
land.
You
know
in
the
days
following
the
1.24
release,
which
I
think
would
be
a
good
second
I
hope
that
would
be
a
good
second
option
to
to
to
what
you
were
hoping
for.
B
Yeah
yeah
I
think
that
works
I
I
think
that
as
long
as
I
land,
all
at
once,
I
think
that's
a
probably
one
of
the
best
outcomes
for
just
from
a
user
experience
that
that
I
can
hope
for
here
too
so,
okay,
I,
think
that
makes
sense.
I
will
continue
to
base
these
new
PRS
off
I've
done
more
than
half
of
them
and
I'm
pretty
familiar
with
you
know,
get
food
so
I'll
be
able
to
help
with
that
I.
B
My
plan
is
I'll
continue
to
make
new
PRS
off
of
the
dev
124
Branch
just
periodically
rebased,
especially
if
I
see
a
merge
from
Main
go
into
there,
just
to
make
sure
that
they
stay
relatively
fresh
and
well.
I
will
talk
with
a
couple
other
people
who
are
also
making
dprs
and
figure
out
what
we
want
to
do
for
the
actual
merge
all
at
once
and
I
think
we'll
probably
Target
having
the
PR's
ready
as
soon
as
possible
and
aim
for
hopefully
merging
them
shortly
after
the
124
release.
If
that's
agreeable
with
everybody,
what's.
D
Your
what's
your
get,
handle
Mark,
I'm,
happy
to
I
I,
already
I,
already
see
a
bunch
of
folks
for
informational
purposes.
So
I'm
happy
to
add
you
to
the
the
list
of
folks
I
penguin
when
I
make
those
maintenance,
PRS.
B
B
G
Yeah,
but
plus
with
all
that
good
conversation
can
generally
related.
Market
sounds
like
it
doesn't
fit
your
current
use
case,
but
one
other
thing
too,
that
we're
trying
to
do
as
the
world's
starting
to
get
back
to
normal
is
scheduled,
doc,
Sprints,
and
so,
if
there's
ever
interest
for
like
a
Windows,
focused
doc,
Sprint
that'd
be
something
the
two
states
could
could
con.
Sorry
could
collaborate
on
because
I
think
it
would
take
both
sigs
to
be
in
the
same
room
for
some
of
those
questions
from
Hey.
G
How
do
I
do
this
in
Windows
from
a
documentarian
and
how
do
I
do
this?
In
the
docs
perspective
from
you
know
a
Windows
itarian,
and
so,
if
you
did
have
interest
in
doing
something
like
that,
I
know:
Abigail
McCarthy's,
leading
efforts
for
Valencia,
just
throwing
it
out
there
to
improve
documentation
around
windows.
I
know
that
sync
Dax
doesn't
volunteer
to
write
those
the
content
but
potentially
an
opportunity
to
collaborate
there
in
the
future.
B
A
All
right,
I
put
a
topic
from
slack.
Actually,
there
was
a
Quest
from
6cli
to
help
improve
the
customized
docs
put
the
slack
link
on
there
as
well
I.
Think
one
person
from
six
CLI
said
that
they
might
come,
don't
see
the
person
here,
but
don't
have
the
full
background
information
on
this
as
well
and
I
think
that
I
I'm
I
think
they
want
to
make
the
customized
stock
similar
to
to
how
sick,
docs
or
or
k
website
does.
Does
their
documentation
I
think
go
ahead.
E
E
And
then
the
question
is,
you
know:
does
does
that
adoption
happen
under
the
ages
of
Sig
docs,
adopting
it
supporting
6
CLI
or
does
6cli
do
that
more
Standalone
without
really
getting
that
support.
A
Don't
know
if
I
have
an
answer
to
that
or
if
six
CLI
has
a
preference
for
that
too.
I
think
this
is
another
topic
that
we
could
have
two
six
work
together
and
see
what
the
best
path
forward
is.
E
I
will
I'll
let
that
I
think
what
six
CLI
you
know
they're
more
worried
about
what
might
they
lose
so
that
they're
happy
to
to
work
with
Sig
docs
provided?
But
you
know
that
it's
important
not
to
to
lose
out
on
things
like
I'm,
not
quite
sure
there
are.
There
are
things
that
matter
to
to
them
and
to
to
the
readers
that
that
need
to
be
maintained
as
as
valuable
things
that
still
happen.
A
I
think
I'm
going
to
try
to
get
more
info
on
this
and
tend
to
stick
CLI
meeting
and
try
to
try
to
write
up
and
get
summary
for
Sig
docs
and
bring
it
back
to
your
slack.
Channel.
E
I'm
gonna
add
this
ties
in
tangentially
to
a
piece
of
work:
I've
been
working
chipping
away
at
which
is
to
bring
more
of
the
coupe
cuddle
docs
into
K
website
and
to
reorganize
them.
I've
really
only
made
a
little
bit
of
a
start,
but
I
know
I
had
a
look
at
the
size
of
it
and
there's
plenty
more
work
to
be
doing.
A
That's
gonna
be
a
huge
effort,
so
if
any
new
contributors
don't
want
to
help
out,
I
mean
what
that's
a
good
place
as
well.
A
All
right
last
call
for
commentary
questions.
The
last
thing
I
have
on
the
discussion
topic
is
just
the
ongoing
doctor
should
related
related
work
linked
the
project
board.
On
that
it's
going
pretty
well,
you
know,
there's
some
issues
that
haven't
been
assigned
yet,
but
yeah
we
are
working
through
those.
D
If
you're
interested
in
picking
up
one
of
those
issues,
we
would
greatly
appreciate
it
and,
if
you're
looking
at
them
and
are
confused
or
would
like
help,
we
are
very
happy
to
explain
things
and
and
and
walk
through
what
needs
to
be
done.
If
things
aren't
aren't
clear
as
it
is.