►
From YouTube: Kubernetes Sig Docs 20171128
Description
Meeting notes: https://docs.google.com/document/d/1Ds87eRiNZeXwRBEbFr6Z7ukjbTow5RQcNZLaSvWWQsE/
The Kubernetes special interest group for documentation (SIG Docs) meets weekly to discuss improving Kubernetes documentation. This video is the meeting for 28 November 2017.
https://github.com/kubernetes/kubernetes.github.io
B
A
Pacific,
the
I
think
most
of
the
ingredients
were
there,
but
I
think
that
we
need
to
go
over
I
think
we
could
go
over
what
the
actual
flow
of
the
event
is
going
to
be
like
some
of
the
logistical
details
and
also
to
make
sure
that
that
the
project
for
sprint
participants
to
to
draw
issues
from
it
has
all
of
the
information
that
it
needs.
A
We
had
talked
last
week
about
sending
an
email
to
sprint
participants,
saying
hey:
what
are
you
interested
in
and
following
up
a
little
bit
more
but
I
also
neglected
to
factor
in
the
holiday
into
all
of
those
plans,
and
so
right
now
we're
about
a
week
and
a
half
out
from
the
sprint.
So
I
don't
know
that
we
have
enough
time
to
well
I
mean
do
we
is
it
worth
trying
to
follow
up
on
that?
A
C
D
I
mean
it's,
the
questionnaires
I
think
good
to
go,
so
we
could
just
send
it
out
to
that
list
that
we
have.
If
you
want
to
take
a
look
real,
quick,
see.
If
there's
any
other
questions,
you
want
to
ask
them
besides
what
we
already
have
and
we
try
to
keep
it
as
short
with
just
like
four
questions,
sure.
A
A
D
Well,
I
think,
based
on
the
responses
we
can
gauge
kind
of
with
the
distribution
of
experiences,
and
so,
if
there
aren't
that
many
that
have
experience
with
actually
kubernetes
or
Doc's
or
whatever,
then
we
might
focus
more
on
like
the
glossary
stuff.
But
but
if
the
distribution
looks
pretty
good,
then
we
can
maybe
kind
of
roughly
break
them
up
into
groups
and,
like
you
know,
and
then
I
don't
know,
see
see
if
they're
interested
in
working
on
like
the
these
are
journey's
pieces
that
we
need
to
have
fixed
up
and.
C
My
plan
absent
any
further
information,
is
to
try
to
break
some
of
those
down,
make
them
a
little
more
manageable
I'm,
especially
a
mini
cube
one,
which
is
the
one
I'd
like
to
see
the
most.
That's
a
whole
lot
of
content
and
I.
You
know
I
feel
as
though,
if
I
it
I
want
help
with
it.
I
should
be
more
specific
and
help.
C
People
and
sort
of
you
know
give
people
options
about
it,
but
if
it
looks
as
though
we
don't
have
that
level
of
interest,
I
mean
I
will
do
that
for
the
mini
cube
one
anyway,
because
they
could
use
compliment
from
anybody
at
any
time,
but
there's
other
large
issues
that
could
get
further
broken
down.
That
could
support
the
user
journeys
and
I'll
make
more
of
an
effort
to
do
that.
If
it
looks
as
though
we're
gonna
have
attendees
who
might
be
interested
and
similarly,
if
we
need,
we
think
we
need
more
small
bits.
C
A
C
A
Don't
know
that
I
don't
know
Jennifer
that
you
have
to
devote
a
lot
of
time
to
going
really
granularly
in
in
some
of
the
meteor
issues
like
like
with
mini
cube,
I.
Think
some
specificity
is
helpful
and
I.
Think
that,
like
in
the
context
of
a
sprint,
I
think
that,
like
working
working
together
in
a
group
of
interested
people
will
be
helpful.
But
I.
Don't
know
that
like
deep
granularity
is
going
to
be,
is
going
to
be
like
a
necessary
requirement.
C
It's
likely
that
a
cube
con
will
get
people
even
ready,
er
and
able
right
because
right,
the
docs
is
drawing
from
all
the
people,
as
opposed
to
kubernetes
specific
interested
people.
I
know
at
right.
The
docs
in
Portland
in
the
spring
most
of
the
folks
at
the
kubernetes
table
were
not,
they
knew
kubernetes
was
cool,
and
that
was
most
of
why
they
wanted
to
be
there
a
lot
of
the
more
first-time
open
source
contributors.
You
know
there
was
a
certain
we've
taken
care
of
some
of
it.
C
A
Yeah
Android
Jennifer.
That's
a
really
good
idea
about
sending
out
that
questionnaire
and,
like
just
pre
loading,
some
of
the
distribution
work
and
trying
to
get
a
sense
in
advance
of
what
of
what
of
where
participants
are
and
being
able
to
get
a
sense
of
what.
What
the
balance
on
like
room
distribution
is
going
to
be
like
I,
think.
A
C
A
A
E
D
A
E
A
Right,
exactly
okay,
cool,
just
as
a
side
note,
I
I
mean
I
have
Kristen
Disick.
My
my
manager
at
at
the
Linux
Foundation,
has
tasked
me
with
finding
better
and
richer
swag
for
Docs
participants.
So
I
don't
know
well.
I
do
know
that
I
won't
have
time
to
get
it
all
arranged
before
koukin.
But
look
look!
Look
for
riches
stocks,
riches
to
fall
from
the
sky
afterwards
in
gratitude
for
your
many
contributions
boom
asterisk.
A
There
are
things
that
are
perfectly
good
ideas,
but
that
we
are
just
not
going
to
be
able
to
touch
in
the
foreseeable
future,
like
I
can't
foresee
within
within
six
months
and
and
within
a
year
whether
or
not
we
can
actually
get
to
those
issues.
So
I
don't
really
feel
the
need
to
preserve
an
archaeological
record
of
where
we
are
based
on
open
issues.
A
You
should
totally
do
this.
You
know
if
you
are
willing
to
provide
the
support
to
make
that
happen.
If
you're
willing
to
undertake
the
efforts
to
put
an
open,
a
PR
against
this
and
see
it
through,
then
yes,
we
can
absolutely
do
it,
but
this
issue
hasn't
gotten
any
updates
in
six
months.
So
there's
no
there's
no
chance
that
we
can
I'm
not
keeping
this
open.
Just
because
it's
a
good
idea,
so
I
don't
know,
it's
I
realized
that
that
is
potentially
fraud.
Maybe
it's
a
good
idea.
Maybe
it's
a
terrible
idea.
B
D
F
Is
there
is
there
some
way
to
close
the
issues
with
an
indication
of
why
they
were
closed?
I
mean
there's
a
difference
between
this
will
never
ever
happen,
because
it
is
no
longer
actionable,
and
this
is
a
really
good
idea,
but
unless
somebody
steps
forward
to
take
it,
it's
just
not
going
to
happen.
A
Sure
I
think
that
kind
of
specificity,
normally,
when
I
do
bulk
actions
like
that
I
have
a
I,
have
a
scratch
pad
with
some
boilerplate
text
that
I
use
when
responding
to
a
scene.
It's
just
nodding
because
I
gave
him.
My
boilerplate
I
have
some
boilerplate
that
I
use
when
responding
to
issues,
and
it's
it's
totally
feasible
to
the
calves.
At
least
you
know
have
at
least
two
different
boiler
plates
for
responding.
One
saying
it's
not
feasible
that
we're
going
to
get
to
this
and
or
like
this
is
aged
out.
A
This
is
a
good
idea
and
if
you
want
to
provide
the
resources
to
do
it,
yes
or
I
mean
this
issue
just
doesn't
fit
inside
the
scope
of
what
we're
willing
to
do.
I
think
we
can
provide
some
specificity
I,
don't
know
that
we
need
to
provide
I,
don't
I
mean
sure
we
could,
that
I
wish
that
we
could
provide
handwritten
comments
for
every
single
issue,
close
I.
F
A
G
Slightly
different
take
on
it
I
think
it's
probably
a
reasonable
idea
to
do,
but
I
think
to
follow
along
with
it.
Something
that
we
may
want
to
consider
is
a
focused
on
when
bugs
coming
in
as
a
part
of
the
triage
process.
Encouraging
people
hey.
This
is
a
great
idea,
you're
right,
it's
a
problem,
we'd
love
to
have
that
update.
Can
you
do
it
and
just
ask
them
explicitly?
Do
it
and
focus
much
more
on
guidance
to
improve
the
number
of
contributors
coming
in
with
like
one
or
two
patches
with
the
existing
team?
A
Okay,
it
sounds
like
an
opportunity
to
update
the
pull
request,
template
saying:
hey
thanks
for
opening
at
his
full
request,
the
chances
of
it
being
I,
don't
like
finding
finding
some
way
to
say
the
best
way
to
get
this
pulled.
This
issue
addressed
is
to
work
on
it
yourself
to
point
out
that
this
is
it's
an
open
source
project
and
and
there's
there's
absolutely
it
like
no
barriers
and
no
gatekeeping
to
to
contribution.
A
E
D
D
Just
on
the
PRQ
side,
once
we
kind
of
got
it
down
to
you
know
like
50
or
below,
and
you
know
it
really
helped
us
to
kind
of
turn
a
corner,
and
then
people
had
more
faith
that
there
was
stuff
going
on
and
there
was
change
and
that
you
know
process
was
was
working
so
I
think
I'm.
Similarly
like
for
issues
that
will
help
a
lot,
because
then
people
will
feel
more
confident
if
they
enter
an
issue
and
I
will
actually
get
addressed.
Let's.
E
A
Fair
ya
know
it's
a
really
good
point:
Andrew
is
that,
like
from
a
community
health
standpoint
like
seeing
seeing
active
maintenance
in
the
repo
I,
think
I
think
it
does
encourage
people
to
it,
gives
people
faith
that
the
the
work
is
manageable,
that
the
the
scope
of
what's
going
on
is
healthy.
It's
actively
maintained.
There
is
some
discretion
about
saying
yeah.
These
are
the
things
we
will
work
on
and
we'll
get
them
done,
because
it's
it's
being
actively
maintained.
A
E
A
And
Joe
just
reminded
me
that
there
is
an
open,
there's,
there's
kind
of
a
hidden
cache
of
Doc's
issues
in
kubernetes
kubernetes
they're
in
kubernetes
kubernetes.
There
are
issues
that
have
been
flagged
with
a
cig,
Doc's
label.
So
at
some
point
we
also
need
it's
it's
a
kind
of
a
different
issue,
but
we
need
to
figure
out
how
to
how
to
incorporate
those
issues
into
a
into
our
awareness
and
like
factor
that
into
the
scope
of
what
it
is
that
we're
actually
looking
at
so
I
will
make
a
note
about
that.
G
G
A
H
H
One
of
the
ideas
that
we
have
is
group
mentoring
via
cohorts
code
works
like
a
graduating
class,
essentially
I've,
taken
inspiration
from
several
different
sources.
What
we're
trying
to
what
we're
trying
to
get
away
from
is
one-on-one
mentoring,
that's
not
to
say
that
we're
not
some,
not
supporting
that
it
just
doesn't
necessarily
scale
to
where
we
need
it
to
be.
So
this
idea
of
group
mentoring
is
also
adding
a
peer
mentoring
concept
in
a
very
self-paced,
yet
semi
structured
learning,
environment.
So
every
so
it's
a
three
month
program.
H
People
start
who
are
currently
on
the
same
track.
So,
for
instance,
current
members
would
all
be
in
this
class
to
go
to
reviewer
ship,
and
then
they
would
have
bi-weekly
stand-ups
where
they
all
talked
about.
You
know
their
goals
and
objectives
and
their
goals
and
objectives
are
coming
directly
from
the
community
membership
markdown
file.
H
That's
in
the
community
repo
and
within
this
program
they
would
be
doing
different
activities
and
issue
grooming
and
come
reviews
and
we'll
have
speakers
come
in
and
and
give
talks
on
things
like
how
to
give
code
reviews
that
aren't
necessarily
positive
in
the
best
way.
You
know
how
not
to
sound
like
a
jerk
on
github,
how
to
have
back-and-forth
conversations
and
take
them
offline
when
and
when
and
where
to
take
them
offline.
H
Things
like
that
and
I
was
speaking
to
Andrew,
and
he
said
that
in
a
previous
Docs
meet
a
Doc's
group
that
you
guys
were
talking
about
how
to
get
more
tech
reviewers,
and
this
could
possibly
float
into
this
sort
of
program.
If
you
will
so
I'm
very
curious
to
hear
what
exactly
types
of
what
types
of
individuals
you
would
be
looking
for,
and
also
like
how
we
can
execute
on
this
exactly
so
the
test
code
work
that
we
have
is
going
to
be
launching
a
week
after
cube
con.
H
It
will
last
anywhere
between
two
to
three
months.
It
is
a
predetermined
group
of
people
that
we
already
have
and
the
reason
why
we're
doing
it
like
this
as
the
test
is,
we
just
want
to
see
if
group
mentoring
works
and
the
philosophy
behind
it,
as
well
as
some
of
the
executable
ideas
that
we
have,
because
you
know,
let's
face,
it,
am
I
not.
This
is
very
experimental
deal.
Not
many.
H
Open-Source
projects
have
like
group
mentoring
in
this
type
of
you
know,
semi
structure
environment,
so
we
want
to
see
if
it
works,
but
we
can
definitely
add
in
this
kind
of
tech,
reviewer
component
to
each
person.
I
do
want,
to
give
a
little.
A
little
caveat
is
that
there's
only
two
to
three
different
sig
/
working
groups.
/
sub
projects
are
represented
in
each
cohort
to
reduce
the
noise
and
because
everybody
does
things
differently.
H
D
Cuz
like
I
I,
understand
as
a
writer
I
understand,
you
know,
like
the
high
level
stuff,
how
things
work,
but
then
there
may
be
like
the
syntax
or
whatever
or
like
a
Yama
file
or
configuration
thing
where
it's
like
I,
don't
know
if
this
is
technically
correct,
so
I
just
need
someone
to
verify
that,
and
sometimes
it's
not
like
a
long
thing.
They
just
need
to
you
know
just
take
a
look
currently
a
lot
of
times.
D
Engineers
are
just
too
busy
to
look,
even
if
it's
you
know
like
a
one-line
change
or
something
it
would
help
if
we
had
more
tech
reviews.
But
the
question
I
have
is
in
terms
of
selecting
tech
reviewers
for
PRS.
Is
it
like
that
willed?
We
will
just
get
a
list
and
then
we
will
assign
them
ourselves
or
should
we
just
like
you,
one
of
those
at
mentions
to
their
particular
area
and
then
they
will
self
select
like
who
will
do
the
review
I.
H
Mean
for
mentoring,
and
that
does
some
to
us,
I
mean
I,
think
whatever
we
think
do
me.
Do
you
have
do
you
have
current
needs
that,
like
people
from
like
a
psychic,
say,
gaps
group
or
like
a
QB
cube,
a
DM
group
could
fulfill
for
you,
I
mean
if
so
like.
What
I
can
do
is
give
you
a
list
of
the
people
that
are
in
the
program
and
we
even
have
one
of
their
bi-weekly
stand-ups.
H
If
you
will
I
mean
the
idea
ultimately
will
and
then,
if
all
goes
well,
that
we'd
have
multiple
cohorts
going
at
the
same
time,
with
different
old,
having
different
goals
and
multiple
multiple
sinks,
and
things
like
that
being
involved.
I
mean
the
test
code.
Word
is
obviously
limiting
us
a
little
bit
with
you
know
with
the
code
base
areas
and
things
like
that,
but
yeah
I,
don't
know
where
it's
gonna
go
with
the
last
favor.
C
What
so
parents,
with
regard
to
your
concern
about
the
cohort,
especially
the
test,
cohort,
focusing
only
on
a
few
areas,
the
current
list
of
tech
reviewers,
that
we
have
divvy
them
up
by
area?
So
we
don't
necessarily.
We
don't
expect
one
any
given
tech
reviewer
to
be
able
to
review
any
technical
content.
We
expect
you
know
we're
trying
to
map
that
way.
Now.
So
that's
it's!
The
current
model
rate,
okay,.
A
H
I
mean
I
think
it
would
be
actually
a
great
idea
for
you
to
come
in
to
one
of
the
by
weeklies
and
maybe
not
the
first
one,
but
maybe
something
around
like
the
second
or
third
bi-weekly,
and
talk
about
you
know
how
helpful
they
can
be
with
becoming
a
tech
reviewer.
What
you're
looking
to
see
out
of
tech
reviewers
it
just
maybe
for
like
a
10
to
15
minute
sort
of
chat.
H
If
you
will
and
then
and
then
what
we
could
do
is
we
could
just
kind
of
start.
Assigning
people
and,
like
Andrew,
said
tag
tag
these
certain
individuals
in
certain
issues
that
you
need
them
and
then
what
I'm
going
to
be
doing
its
tracking?
What
each
one
of
these
folks
is
doing
on
the
back
end,
so
that
when
the
program
is
over,
we
can
essentially
give
them
the
keys
to
the
car,
and
in
this
case
the
car
would
be
the
owners
file
of
whatever
code
base
that
it
is
they're
working
on.
A
What
a
good
tech
review
looks
like
this
is
what
the
process
in
this
repo
looks
like,
that
being
part
of
a
training
that
we
can
help
set
expectations
and
rather
than
expecting
a
tech
reviewer
to
come
in
and
like
figure
out
our
process
like
imparting
that,
and
it's
really
straightforward,
but
it
that's.
It's
not
straightforward.
If
you
don't,
if
you're,
if
you're
like
a
if
you're
new
to
the
repo,
so
I
think
we
can
absolutely
participate
in
in
the
training
that
you're
talking
about
just
kind
and
say
this
is
what
a
tech
review
looks
like.
A
This
is
the
scope
of
what
most
tech
reviews
look
like
they're,
they're,
really
easy
they're,
not
super
demanding,
and
it's
a
it's
a
great
way
to
fill
like
five
ten
fifteen
minutes
here
and
there
and
like
based
on
if
you're
looking
to
fill
like
some
empty
spots
between
between
projects.
Doing
type
of
use
for
Docs
is
a
great
way
to
do
that,
or
just
incorporating
it
into
like
the
regular
schedule,
but
yeah.
We
can
absolutely
do
that.
I
mean.
H
We
can
also
incorporate
it
into
the
ladder
itself,
meaning
it
like
one
of
the
things
that
I'm
actually
looking
coorporate
now
is
the
mentorship
piece,
so
we
can
order
to
become
a
reviewer
or
an
approver,
or
you
know,
insert
higher-level
here
into
the
organization
you
have
to
participate
in
least
one
in
at
least
one
mentor
program
or
be
a
reviewer
or
etc.
So
we
currently
don't
have
that
right
now.
It
is
very
much
based
off
code,
so
we're
talking
about
adding
these
things,
because
they
do
do
definitely
promote
the
health
of
this
organization.
H
In
this
project,
though,
I'm
actually
going
to
do
the
pull
request
to
the
community
member
ship
file
sometime
within
the
next
couple
of
days
to
to
signify
that
I,
also
in
the
chap
put
in
the
mentee
guidelines
to
the
next
baby.
Another
reason
why
I
did
that
is
at
the
very
bottom
you'll
see
and
I
thought
I'm.
Actually
it's
in
the
middle,
but
you'll
see
development
areas
and
activities,
and
this
is
the
stuff
that
we're
actually
calling
out
as
to
have
areas
for
people
in
the
cohort.
H
So
I
do
have
right
now
in
the
current
reviewer.
It's
a
suggest
that
activity
be
attacked
reviewer
for
docs,
but
I'll
actually
create
some
more
meat
potatoes
around
that.
It's
based
off
of
our
conversation
today
and
include
things
like
docks
will
come
into
a
biweekly
to
talk
about
this,
but
I'm
anticipating.
That
would
probably
be
probably
some
of
the
first
weeks
in
January.
I
So
my
experience
with
tech
reviewers
has
been
that
I
usually
need
somebody
with
very
specific
knowledge
of
a
particular
component,
and
it
often
is
someone
who's
not
on
any
list
of
current
tech,
reviewers,
so
I
feel
like
right.
Now
it's
been
pretty
freeform
and
what
I
often
do
is
just
go,
look
and
see
who
worked
on
that
piece
of
code
most
recently
and
asked
them
to
review
so
I.
I
H
Bring
in
the
person,
ok,
I'm,
sorry
I
was
definitely
gonna
say
bring
in
the
first
eight
100%.
This
is
just
another
way
of
you
of
you,
ultimately
getting
the
word
out
and
training,
better
tech,
reviewers
and
also
getting
these
folks
who
are,
in
this
men
program,
more
skills
and
more
exposure
to
different
areas
of
the
project.
So
this
is
not
take
away
anything
that
you're
currently
doing
by
any
chance.
This
is
just
in
addition
to
and
as
like
a
supplement,
the.
H
I
Yeah
thanks
yeah
and
I'd
like
to
see
more
names
added
to
our
list,
most
the
names
that
we
have
on
this.
That
list
right
now
are
people
here
at
Google,
but
I
in
reality,
we've
been
using
a
lot
more
people
than
that,
so
I'd
like
to
I
mean
would
does
that
seem
like
it
would
be
okay
to
do
to
just
if
I've
been
working
with
someone
over
and
over
again
for
the
last
six
months
to
just
go
ahead
and
add
them
to
that
list.
G
Let
me
rephrase
it
it's
a
slightly
different
question
for
Paris
they're
in
a
couple
of
the
context
documents
there's
this
concept
of
a
ladder
and
if
your
reviewer,
then
you
know
you're
in
a
file,
should
we
be
using
those
files
more
actively
in
terms
of
identifying
people
that
can
help
do.
Is
this
technically
accurate
kinds
of
reviews
for
various
components,
yeah.
H
Definitely
I
would
definitely
say
so:
I
mean
it's
not
in
there
I,
don't
think
we
have
necessarily
job
descriptions
if
you
will
but
I
mean
I
think
that
community
membership
guy
definitely
comes
close
and
it's
a
work
in
progress,
as
you
can
say,
so
it's
definitely
something
that
we've
been
talking
about
and
I
think
even
at
the
contributor
summit.
Some
of
the
topics
that
have
come
up
for
people
who
want
to
discuss
this
are
things
like.
What's
the
role
of
these
individuals
exactly,
and
so
this
is
definitely
a
very
active
conversation.
H
That's
going
on,
and-
and
you
know,
if
you
have
anything
that
you
know
you
want
to
add
to
the
community
membership,
you
know
start
a
conversation
on
start
a
conversation
on
it
or
submit
a
PR
or
something,
but
it's
definitely
yeah
I
would
say.
Definitely
please
reach
out
to
the
people,
those
owners
files
and,
if
not,
they
not
themselves.
They'll.
Definitely
give
you
someone
the
idea
or
suggestion
of
who
to
reach
out
to
and
who
to
contact.
D
So
I'm
thinking
long
term,
what
I'd
like
to
see
is
a
little
bit
of
automation
like
maybe,
if
we
owners
file
like
specified
these
different
buckets
or
specialties
and
then
have
like
the
people
associated
with
them,
then
we
can
have
like
the
tooling
automation
people
like
Auto
assign.
So
if
so,
if
we
do
like
slash,
assign
and
then
like
a
particular
specialty
or
something,
then
it
would
look
through
that
list
and
just
Auto
assign
them
that
way.
We
don't
have
to
like.
D
I
We
also
lists
owners
in
the
front
matter
of
individual
topics
and
we're
not
consistent
with
that,
but
that
had
been
a
pattern
in
the
past.
If
we're
going
to
talk
about
automating,
assigning
tech
reviewers,
we
will
need
to
make
a
decision
as
to
you
know,
do
we
keep
that
information
in
two
places
or
just
one
place,
because
right
now,
it's
it's
also
in
sometimes
in
the
front
matter
and
I've
had
the
experience
where,
if
I
forgot,
to
ask
one
of
those
people
for
review
they,
they
got
a
little
miffed.
I
D
D
A
There
enough
here
that
I
want
to
make
sure
that
we
that
we
have
the
full
discussion
about
about
automation
and
about
convention,
so
you
know:
do
we
like,
for
instance,
do
we
do
we
add
and
do
we
add
a
note
to
the
style
guide
about
listing
contributors
or
reviewers
in
the
front
matter?
How
do
we
want
to
handle
the
owners
file
it?
It
sounds
like
there's
enough
to
discuss
that.
We
should
probably
like
have
a
separate
discussion
about
this
yeah.
A
I
I've
been
going
through
and
trying
to
understand
all
the
different
tools
and
processes
that
are
used
to
generate
the
different
kinds
of
ref
Docs
and
turns
out
the
list
is,
is
bigger
than
I
thought
and
one
of
the
things
that's
on.
There
is
the
Federation
documents
there.
There
are
several
Federation
components
like
cube,
fed
and
Federation
API
server.
That
kind
of
thing
that
we
have
one
one
script,
that's
responsible
for
generating
those,
and
then
there
is
a
Federation
API
that
has
a
big.
I
You
know
one
of
those
big
long
single
pages
where
the
the
API
is
documented
in
the
scripts
for
generating
those
were
were
both
broken
because
the
Federation
repo
was
recently
split
off
from
the
kubernetes
kubernetes
repo
and
so
the
the
scripts
hadn't
been
adjusted
for
that.
But
just
yesterday,
Maru
Maru
worked
on
those
and
they're
they're
working
now.
I
A
D
I
There's
a
discussion
about
this,
it's
in
in
slack
in
cig,
multi
cluster,
because
I
was
you
know,
working
with
Maru
yesterday
to
to
get
this
fixed
and
it
generated
a
discussion,
and
so
there
it
seems
to
me
on
the
engineering
side,
there
is
a
strong
desire
to
get
a
unified
toolset
and
get
more
automation
in
the
way
of
copying
things
into
the
kubernetes
website,
repo
and
that
kind
of
thing.
What
what
I
said
to
that
in
that
discussion
is
that
yeah
we're
kind
of
looking
at
head
in
that
direction
in
q1?
I
Thank
you
for
we're
doing
this.
Just
trying
to
understand
the
big
picture
see
what
all
the
processes
are
and
what
all
the
tools
are
get
that
documented
and
then
you
know
by
all
means
in
q1.
We
want
to
look
at
this
bigger
picture
of
how
do
we
get
a
more
unified,
toolset
and
a
more
stable?
You
know
easy-to-use
process
for
all
these
generated.
Docs
I
think
we
will
have
support
from
this
from
the
engineering
side.