►
From YouTube: Kubernetes SIG Docs 20190305
Description
Meeting notes: https://docs.google.com/document/d/1zg6By77SGg90EVUrhDIhopjZlSDg2jCebU-Ks9cYx0w/edit#
The Kubernetes special interest group for documentation (SIG Docs) meets weekly to discuss improving Kubernetes documentation. This video is the meeting for 05 March 2019.
https://github.com/kubernetes/website
A
B
A
A
I'm
Zack
is
out
today
and
tomorrow,
so
I'm,
not
sure,
since
he
had
a
question
originally
in
the
agenda
about
PR
wrangling,
I
will
something
about
PR
wrangling
for
the
next
couple
of
days.
They
think
no
promises
about
quantity,
make
sure
I'm
at
least
staying
on
top
of
the
queue
and
then
check-in
him
when
he
gets
back
unless
anybody
else
has
information
that
suggests
that,
what's
on
the
PR
regular
page
about
today,
sometimes
it
gets
a
little
it's
gotten
a
little
out
of
whack.
A
A
side
of
things
that
week.
So
I
would
let
y'all
know
and
because
we
had
little
and
announcing
the
time
in
the
slack
Channel
I
realized
that
it
was
probably
useful
to
remind
folks
who
are
not
in
the
US
on
this
call
that
we
will
be
differently
will
have
different
time
differences
starting
next
week,
because
the
u.s.,
those
and
daylight
savings
time
is
coming
me
weekend
and
until
I
have
to
I.
A
A
So
let's
see
and
is
that
Arnold
can't
attend,
but
he
would
like
to
remind
everyone
in
this
meeting
that
he's
got
a
forum
for
anybody
interested
in
participating
in
the
saqqaq
security
working
group,
and
it's
not
a
commitment,
form
I've
taken
a
look
at
it
already.
If
any
of
you
hasn't
had
a
chance,
the
link
is
there
in
the
agenda.
It
was
in
slack
yesterday.
It
went
out
to
the
I
believe
it
without
to
the
Google
Group.
A
A
C
D
D
A
D
D
Sure
you
know
we
have
started
exploring
communities
for
our
for
our
teams
and
as
well
as
they'd
like
to
know.
We
are
I,
see
it
over
to
us
here
in
Dubai,
so
we
are
also
like
you
know,
providing
we
also
want
to
provide
to
another
service.
So
we
are
exploring
couple
of
options
like
Tiki
behind
VMware
tks,
so
yeah
so
I.
We
also
have
some
teams
like,
were
you
know,
developing
machine
learning
as
a
service?
So
essentially
they
are
leveraging
seldom
machine
learning
model
deployments
and
to
flow
I
have
helped
my
team.
D
D
A
D
C
A
E
C
C
So
I
guess
it
is
fairly
easy
to
actually
anticipate
what
is
going
to
happen.
But
let's
run
through
this
real
quick,
so
this
robot
is
going
to
grab
the
gray
one
drop,
the
orange
one,
the
robot
on
the
top
grabs
the
orange
one
and
drops
the
blue
one,
the
robot
on
the
right
grabs,
a
blue
one
and
drops
earn
purple,
I,
guess
purple
one
and
the
robot
on
the
bottom
grabs
the
purple
one
and
drops
the
green
one
so
far,
so
good!
That
was
not
very
hard.
However.
C
F
C
C
Let's
go
back
to
this.
Our
instead
of
a
great
boil.
I
have
a
deployment
in
the
kubernetes
object,
store
the
deployment
controller,
reads
off
the
deployment
and
creates
a
replica
set.
The
replica
set
controller
reads
a
replica
set
and
creates
a
part
and
the
cubelet
picks
up
on
the
pod
and
creates
a
container.
C
So
when
we
describe
kubernetes
as
a
declarative
system,
we
usually
say
that
we
specify
the
desired
state.
We
say
that
the
deployment
the
desired
state
of
the
deployment
is
to
have
a
set
number
of
pots,
but,
as
you
just
said,
that
would
actually
mean
the
gray.
Ball
is
a
specification
of
the
desired
state
for
a
green
boil,
and
that
is
just
odd
I,
don't
want
to
say
if
it's
wrong,
maybe
you
can
view
the
word
through
this
lens,
but
it
is
completely
odd.
It
does
not
spark
a
very
good
mental
picture
if
I
tell
anybody.
C
Now,
let's
take
this
just
one
step
further
to
actually
internalize
how
this
system
works
right.
So
far,
we've
seen
these
are
individual
actors
right.
They
can
do
like
their
own
thing
and
there
are
causally
coupled
just
because
the
one
guy
drops
an
orange
boil,
the
other
guy
who
can
pick
it
up
and
drop
blue
ball.
I
can
reason
about
this
right.
I
can
with
what
has
to
happen
in
what
order.
So
individual
agents
causally
cut
it
right.
C
Let's
take
a
different
set
up,
we
have
an
orange
boil
guy
on
the
top
picks
up
the
blue
boil:
okay
and
the
right
picks
up.
The
blue
boy
drops
a
purple
boil
the
guy
on
the
bottom
picks
up.
The
purple
boy
drops
in
orange
pour
in
the
red
ball
and
the
guy
on
the
Left
greedy
guy,
just
grabs.
The
red
ball
doesn't
grab
nothing
that
doesn't
drop
nothing
all.
F
C
C
E
C
It
is
also
now
a
question
between
the
one
on
the
top
and
then
eventually
the
one
on
the
right.
So
nobody
says
that
the
red
one
needs
to
go
in
there
at
any
point
in
time.
If
we
do
this
round
five
times,
I
could
end
up
with
five
red
balls
and
one
orange
ball
over
here
before
the
red
one
ever
picks
one
up,
and
then
it
could
pick
up
five
red
ones
in
a
row,
and
so-
and
you
already
said
the
point
they
are
not
coordinated.
C
C
That
is
the
overall
working
philosophy
of
kubernetes
that
accurately
describes
kubernetes.
This
is
how
the
in
the
robot
is
a
stand-in
for
the
individual
controllers
and
the
objects.
The
colored
objects
is
a
stand-in
for
the
individual,
kubernetes
objects
and
kinds
of
kubernetes
objects,
yet
I
believe
none
of
us
would
that
this
is
a
declarative
system.
We
wouldn't
jump
to
that
description,
and
none
of
us
would
say
that
a
a
object.
The
colored
object,
is
a
specification
that
I
want
another
colored
object.
In
fact,
I
want
to
take
it
one
step
further.
C
C
Yet
I
do
not
have
a
crisp,
concise
term
that
describes
this
system
in
control
system.
Literature
as
far
as
I
can
see,
I
can
tell
the
general
interplay
between
the
components
is
called
a
coupling,
but
that
is
as
far
as
I
saw
it
on
like
standard
nomenclature,
but
if
we
describe
this
interaction
in
the
documentation
way,
this
the
mechanics
of
this-
if
we
describe
this
well,
we
have
an
overall
description
of
kubja
of
how
kubernetes
works
and
it
is
accurate.
It
is
free
of
philosophy
or
wishful
thinking.
G
So
that's
that's.
Why
that's
where
it
comes
from
from
from
my
point
now,
I
mean
things
happening
underneath
right,
I
mean
so.
If
you
you
got
six
replicas
and
to
go
down
in
your
desired
state
is
to
have
six.
It's
gonna
start
to
more
up.
You
declared
what
you
wanted
and
it's
gonna
go
make
it
happen.
That's
why
that's
why
I
always
do
it?
Does
that
help
in
true
yeah.
E
Cuz
see
when
we
were
looking
at
this,
like
we
tried
to
make
the
declarative
thing
work
for
a
while,
but
we
ran
into
like
problems
as
we
got
into
certain
areas
like
one
other
example,
dominic
correct
me
if
I'm
wrong,
but
is
like
like
just
looking
at
pods
right
and
like
like
say
you
want
to
run,
run
an
application.
This
is
continuously
running
versus
a
job
which
you
want
to
run
to
completion
right
so
like
when
you're
trying
to
think
of
like
being
declarative.
E
Specifically,
you
never
really
state
that
in
the
llamo
file,
whether
you
want
the
you
know
the
pod
to
run
to
completion
or
to
just
keep
running
right,
but
depending
on
which
thing
you're
doing
in
which
conflicts
it
may
be
different.
So
it's
like
how
do
you
then,
when
you're
really
trying
to
strictly
defined
declarative
like
what
is
what
does
that
mean
in
that
context?
It
because
it
totally
depends
no.
G
I
agree
with
you:
you've
got
to
be
careful,
I
mean
the
declarative
model,
works
really
well
for
deployments
and
replica
sets.
But
when
you,
when
you
talk
about
jobs,
that's
that's
more.
The
there
is
either
an
implied
declare
call
notion-
or
just
you
just
know
how
the
job
works
right.
It
runs
until
it's
done
so
so
I
see
what
you're
saying
I
never
really
thought
about
it
and
that
context
Andrew,
but
you're
right.
G
It's
not
it
certain
aspects
of
it
map
very
well
to
being
declarative,
and
then
the
other
thing
is
there's
just
lots
of
other.
There
are
other
mechanisms
and
constructs
that
there's
not
as
much
declarative
Ness
showing
through.
If
that
makes
sense,
you
know
yeah
I,
think
you
know
it's
kind
of
like
if
you,
if
you
dig
into
too
many
details,
you
yeah
the
analogy
kind
of
breaks
down,
I
would
have
to
agree
with
you.
There
yeah.
E
G
And
then
the
whole
model
of
you
know
people
not
necessarily
using
the
declarative
fortune,
they're
they're
running
from
the
command
line
and
they're
actually
doing
the
more
procedural
piece.
The
more
imperative
piece
right
go
create
this
create
that
right.
So
that
case,
declarative
was
only
one.
It
was
the
the
desired
path,
but
but
not
the
only
path.
Right.
E
G
I
think
what's
gonna
make
you
want
to
have
it
stick
around?
Is
that
whole
you
look
at
those
Djamel,
specs
and,
and,
and
you
know,
if
you're
giving
a
specification
of
a
model,
it's
real
hard
to
not
call
that
declarative
if
that
makes
sense,
so
at
least
for
the
the
animal
pieces
that
have
the
spec
and
the
status
and
and
trying
to
achieve
a
desired
state.
I
think
you're
gonna
have
a
hard
time,
not
calling
that
piece
of
it
declarative,
I,.
A
A
That's
the
case
where
the
interaction
with
kubernetes
really
seems
to
be
appropriately
called
declarative
and
I
agree
with
Brad
I.
Don't
think
you
want
to
get
rid
of
it
when
we
start
looking
at
how
things
work
under
the
hood
and
we
start
looking
at
all
of
the
sort
of
varieties
of
kubernetes
objects,
then
yes,
things
get
complicated
and
declarative
doesn't
work
anymore,
but
that's
not
people
who
need
to
understand
kubernetes
at
that
level
are
not
all
of
our
audience
to
the
docs.
D
F
A
Know
we've
talked
about
personas
and
I'm,
not
suggesting
we
go
back
to
I
mean
in
the
past,
with
some
past
projects
on
the
docks
and
I'm
not
suggesting
we
go
back
and
start
trying
to
build
up
more
personas
that
were
kind
of
artificial
constructs
when
we
worked
on
them
anyway.
But
if
we
do
think
about
the
different
needs
of
kubernetes
Doc's
I
think
we
can
find
an
appropriate
place
for
the
term
declarative
without
smearing
it
all
over.
Everything.
F
C
Of
course,
so,
first
the
the
observation
that
we
made
in
the
beginning
right
where
they
say
well,
the
green
ball
is
not
the
declaration
of
the
desired
state.
I'm.
Sorry,
the
gray
ball
is
not
the
declaration
of
the
desired
state.
Green
ball
right.
That
is,
that
is
an
very
accurate
description
of
what
happens
in
kubernetes.
So,
let's
pause.
C
F
C
C
None
of
us
jumped
on
to
this,
so
it
seems
now
we
are
trying
to
force
a
mental
model
that
doesn't
come
natural
to
us
when
we,
when
we
talk
about
the
robots
and
the
colorful
objects,
that
is
number
one,
so
the
mental
model
doesn't
seem
very
suitable
right.
Doesn't
it
doesn't
come
natural,
so
that
is,
that
is
the
first
part.
The
second
part
is
another
interesting
one.
Actually.
C
B
C
To
bring
this
an
interesting
observation
is
when
right,
because
by
taking
out
the
robot
I
broke
the
chain
now
all
I
can
say
is
well
if
I
have
a
great
Boyle
to
begin
with.
Eventually,
I
have
a
blue
Boyle
I'm,
not
gonna,
get
the
green
ball.
However,
the
gray
boy
didn't
change
the
great
balls
through
the
great
ball.
C
Well,
come
back
here
we
go
now.
The
great
ball
stands
for
the
green
ball.
Again,
it's
also
an
interesting
observation.
The
next
point
that
I
would
would
want
to
make
is
that
personally,
I
have
the
tendency
to
try
to
describe
a
system
in
terms
of
its
construction
right
in
terms
of
the
sheer
facts.
A
system
is
constructed
a
certain
way.
A
system
behaves
a
certain
way.
There
is
no
argument
about
it.
C
It's
just
universally
true
and
I
understand
that
certain
analogies
right
from
a
high
enough
level-
and
we
only
look
like
we
don't
look
close
enough
on
the
replica
on
the
deployment
and
we
only
look
at
the
deployment.
We
completely
ignore
the
jobs
and
then
yeah.
You
can
have
a
mental
model
of
declarative,
but
it
breaks
down
as
soon
as
you
look
at
other
aspects
of
the
system
and
it
breaks
down.
C
If
you
look
into
detail
right,
that
doesn't
seem
to
be
a
suitable
mental
model
either
it
doesn't
hold
when
you
look
at
the
entirety
or
literal
components
of
kubernetes
and
it
doesn't
hold.
When
you
look
into
detail,
however,
we
find
a
good
description
of
the
robot
process
right
that
one
holds
it
doesn't
matter
what
components
aka
controllers
you
look
at.
C
It
doesn't
matter
in
how
much
detail
you
look
at
it
that
mental
model
will
hold
it,
so
you
do
not
have
to
have
multiple
mental
models
that
are
inspired
more
by
philosophy
of
or
what
we
want
right.
You
have
one
mental
model,
and
that
is
how
the
system
is
actually
constructed,
and
the
system
follows
this
model
everywhere.
So
it's
actually
fairly
easy
to
describe
right.
C
Unfortunately,
I
don't
have
I,
don't
have
something
that
rolls
off
the
tongue,
but
let
me
try
here
yeah:
these
are
individual
actors,
they
are
causally
covered,
they
are
not
temporarily
covered
and
an
actor
acts
according
to
if
an
action
is
continuously
enabled
that
action
will
eventually
be
taken.
As
I
said,
this
doesn't
roll
off
the
tongue.
Yeah
sometimes
would
actually
find
something
more
snappy
for
that.
Well,
but
it
is
an
accurate
description
of
the
system
as
a
whole
and
the
individual
parts
of
them.
G
Yeah
I
think
the
challenge
you're
gonna
have
is
you
know
all
models
can
only
model
so
much.
They
all
eventually
break
down
against
a
a
real
system.
There's
always
going
to
be
things
where
I
just
think
the
model
just
can't
capture
everything,
and
you
know
they're
the
decision
for
the
declarative
and-
and
you
know
using
the
declarative
analogy
or
the
declarative
description
is
because
it
was
a
key
differentiator
for
for
kubernetes
compared
to
previous
cloud
infrastructures.
G
So
if
you
looked
at
what
we
did
in
previous
cloud
infrastructures,
whether
it
was
cloud
stack
or
OpenStack,
these
were
very
procedural
based
approaches.
You
use
scripts
to
deploy.
So,
oh
you
use
chef
or
puppet
or
ansible,
and
the
beauty
of
kubernetes
with
its
yamo
description,
the
the
gamma
files
and
the
ability
to
generate
docker
files
was.
It
was
at
least
more
declarative
than
the
previous
generation,
which
meant
we
could
store
and
source
control.
All
your
Yama
files.
G
We
could
store
in
source
control
all
the
docker
files
used
to
generate
the
images
and
we
had
a
much
better,
a
much
better
view
of
the
world
with
regards
to
being
able
to
keep
it
in
source
control
and
do
continuous
delivery,
and
so
for
those
types
of
reasons.
That's
why
this
is
the
many
of
us
view
kubernetes
as
more
declarative
than
the
previous
procedural
scripting
base
cloud
infrastructures
and
you're
gonna
have
a
hard
time
getting
people
not
to
want
to
use
that
term,
especially
with
a
specification
state
model
built
into
so
many
things.
G
Does
the
model
eventually
break
down?
If
you
dig
too
deep
absolutely,
but
does
the
model
get
most
users
where
they
need
to
be
and
understanding
the
value
of
kubernetes
and
how
it
differentiates
from
previous
cloud
infrastructures?
It
does
a
pretty
good
job,
so
I
mean
you
know,
that's
the
trade-off.
Is
the
80%
model
saying
the
of
using
a
declarative
model?
Let's
call
out
the
80%
solution
where
it's
getting
you
80%.
Is
that
good
enough
and
is?
Is
that
right?
Because
what
can
happen?
You
know,
as
I
was
taught
many
years
ago?
G
C
Have
one
follow-up
statement
on
that
from
the
beginning
when
you
said
all
MIT
all
models
break
down,
that
depends,
so
there
are
two
types
of
or
multiple
but
two
in
this
case
there
are
models
of
analogies,
and
that
is
correct.
Not
everything
that
is
true
about
the
model
is
true
about
the
system.
These
models
break
down
sure,
but
there
are
models
about
models
of
construction
where
each
everything
that
is
true
about
the
model
is
true
about
the
system
they
do
not
break
down.
They
just
are.
C
E
Yes,
so
this
the
you
can
look
up
on
Wikipedia,
but
there's
this
way
of
explaining
things.
It's
called
lying
to
children,
where
you
tell
them
like
a
simplified
thing
just
so
that
they
have
some
some
way
to
think
about
it
and
then
later
on,
you're
like
well.
Actually,
no!
No!
It's
not
like
that.
It's
it's
actually
this,
and
sometimes
the
universities
like
they
do
that
too
yeah.
But
that's
not
the
approach
that
we
want
to
take
there.
C
Is
there's
one
reason
to,
or
at
least
for
me,
there's
one
reason
to
avoid
this
approach,
and
that
is
so
psychologists
design
mental
model
right
is
an
internal
representation
of
the
concepts
and
the
relations
among
the
concepts
that
concern
us
and
one
of
the
problems
with
mental
models
is
that
is
a
deeply
held
belief
right.
So
once
you
acquire
a
mental
model,
it
is
very
hard
in
general
to
shed
that
mental
model.
C
So
when
you
have
that
lying
to
children
approach
right
and
you
need
to
go
further,
eventually,
you
come
to
the
point
where
you
struggle
and
you
will
you
will.
You
will
run
into
frustration
right
because
you
have
to
share
what
you
believe
you
knew
about
the
system,
but
it's
a
question
of
philosophy,
so
that
would
basically
be
it
Fred.
Does
the
documentation
lie
to
children
on
well.
G
G
A
Inclined
to
agree
with
you
but
I
think
a
higher
level.
I
have
two
points
to
make
one
is
we
need
to
win
dis
discussion
down,
because
I
would
like
us
to
hear
from
Jimmy
all
about
the
state
of
the
114
ducks
and
on
the
end
of
the
meeting,
and
this
is
getting
very
big
and
very
conceptual
and
theoretical,
but
the
other
thing
that
I'm
hearing
a
slow
CEQA
that
I
try
to
call
attention
to
earlier,
but
I'll
be
more
explicit
here-
is
we're
talking
a
theoretically
pure
contract
for
an
ideally
typed
audience.
E
A
People
who
need
that
kind
of
information
are
I'm,
guessing,
probably
a
relatively
small
subset
of
the
folks
to
the
kubernetes
Doc's.
Looking
for
solutions
to
problems
of
how
to
get
their
app
up
and
running
stable
and
expensable,
and
at
the
end
of
the
day,
that's
who
we're
waiting
for
I
believe
we're,
maybe
waiting
for
other
people
as
well.
But
this
conversation
is
leaving
the
kind
of
practical
application
buddy
aside,
I,
think
and
while
I'd
like.
A
G
No
and
if
I
could
add
to
that,
I
agree
with
everything
you
said
Jennifer
and
the
other
way
to
look
at
it
is
even
if
you
could
get
everything
right
with
a
model
and
you're
like
I've
nailed
it
a
hundred
percent.
With
this
model,
you
have
to
understand
and
accept
that
a
lot
of
the
people
that
read
the
documentation
are
not
necessarily
model
oriented
I
like
models,
because
I
took
a
heck
of
a
lot
of
abstract
math.
On
my
on
my
journey
in
my
education,
so
I
personally
enjoy
it
and
the
con.
G
You
know
the
the
the
syntax,
the
semantics,
the
the
they
really
I
really
find
joy
and
in
reading
things
that
way,
but
I
have
to
admit
there's
a
lot
of
people
that
are
trying
to
use
kubernetes
that
the
model
approach
is
not
going
to
be
something
that
that
they
digest
very
well.
So
I
think
that
complements
what
you
said.
Jennifer.
A
D
A
Not
saying
that
that
should
be
that
I'm
not
trying
to
give
direction
here,
I
see
real
value
here,
but
I'm
trying
at
all
levels
but
I'm
trying
to
bring
it
back
to
those
sort
of
practical
aspects
of
the
docs
and
I
guess.
I'm,
also
wondering
if
I
could
shut
myself
up
at
this
point
there,
maybe
I,
don't
know
whether
it's
possible
to
slash
whether
those
of
us
who
are
interested
should
form
a
smaller
working
group,
because
we've
taken
up
I,
think
a
lot
of
I
mean
I.
A
Think
we've
done
I
think
this
is
been
a
really
really
useful
and
important
conversation.
We
clearly
can't
medicate
this
kind
of
time,
two
out
of
the
week
Lisa
box
meeting
to
this
thing,
especially
going
forward
but
I
think
it's
really
important.
So
maybe
we
could
brainstorm
and
slack
a
little
bit
about
how
to
continue
the
conversation.
You
know
sort
of
inside
group,
a
working
group,
asynchronously
I'm,
not
sure
yeah,.
F
A
H
H
All
right,
so
this
is
the
enhancement
tracking,
spreadsheet,
I'm,
not
sure
who
all
has
or
not
I
had
a
link
in
the
in
the
agenda
here
and
what
I
wanted
to
go
over
is
I
made
a
few
changes
and
how
we're
tracking
some
of
the
enhancements
to
give
us
better,
real-time,
metrics
and
just
a
quick,
you
know
too
long,
didn't
read.
Overview
of
the
release
process
for
documentation
is
mainly
these
two
columns
here.
So
this
is
a
list
of
all
the
enhancements
for
114.
H
They
made
it
a
requirement
that
every
single
enhancement
had
to
have
a
community
enhancement
proposal.
So
that's
a
very
cool,
forcing
function
that
then
requires
all
of
these
enhancements
to
have
a
testing
plan,
a
rollback
plan,
a
update
plan,
a
essentially
a
group
of
people,
all
agreeing
that
this
enhancement
that's
needed
and
should
be
going
into
kubernetes
or
whatever
the
latest
releases
and
this
documentation
tracks
it.
H
But
we
also
do
four
sig
docs
is
track
it
under
these
two
columns
is:
does
this
enhancement
need
Dax,
so
there's
options
of
whether
it
has
Doc's
and
these
Doc's
they're
unknown
or
there's
none
required?
And
then
beyond
that?
Doesn't
need
it
just
in
general,
there's
the
actual
doc
status,
so
this
is
more
of
the
real-time
tracking
of
wood
ducks
are
going
through
their
overall
life
cycle
or
how
they're
changing
so
here
for
the
status
we
have.
You
know
draft,
so
major
2p
are
open.
It's
in
draft
state.
It's
not
ready
to
be
merged.
H
It's
not
implementable!
It's
just
in
kind
of
a
raw
form.
Almost
like
a
placeholder
PR,
that's
just
out
there!
No
PR
could
be
good
or
bad
depending
on
the
status
that
there's
right
before
it.
So
if
you
see
below
here,
you'll
see,
none
required
has
no
PR,
so
that
makes
sense.
Late
would
be
if
you
needed
ducks
and
you
didn't
have
any
PRS
open
for
those
dogs
and
you
missed
a
deadline,
and
you
can
see
it
kind
of
goes
through
here.
You
know,
has
a
PR
open.
Its
ready
for
review
is
complete
emerge.
H
So
the
reason
for
doing
this
and
why
I'm
going
through
explaining
this
is
I,
was
able
to
modify
the
overview
for
the
future
stats,
an
additional
tab
here
to
give
a
point-in-time
view
of
where
we're
at
for
the
documentation.
So
what
I
felt
was
lacking
in
this
release
cycle?
Is
it?
Do
you
say
yeah
we're
60%
good
or
were
you
know,
80%
good
I
didn't
feel
like
I
had
that
the
ability,
so
here
what
I
did
is
I
start
pinning
it
down
to
see
okay.
So,
in
this
release,
there's
the
total
of
33
enhancements.
H
I
could
check
that
against
some
of
these
other
metrics
here
so
I
can
see
here's
the
total
of
alpha
beta
and
stable
releases
33
there
I
can
also
see
that
there's
features
per
se,
there's
33
there,
so
those
numbers
all
make
sense
and
then
I
can
see.
Okay
well,
I
need
22
documents
in
the
current
release.
One
of
them
is
unknown.
Tendo
acquired
ducts.
So
what
is
the
overall
picture?
H
A
H
A
H
So
I
think
between
us
in
the
shadow
they
should
have
enough.
You
know
people
looking
at
the
different
issues,
but
I
guess
as
we're
reviewing
different
PRS
and
saying
things
come
and
if
you
see
anything
that
looks
like
it
might
before
the
release
is
improperly
marked
and
properly
tagged.
Any
open
questions
feel
free
to
ping
me
in
slack
or
any
of
the
shadows,
you're
involved
with
the
sig
release
for
docs,
so
I
guess
I'm
saying
we
don't
need
help,
but
we
need
all
the
help.
A
A
A
F
Just
if
you're,
if
you
are
signed
up
to
do
one
of
the
projects,
you
know
we
have
in
them
in
the
git
repo,
we
have
the
projects
you
can
go
to
doc,
writing
and
editing.
I
can
see
that
people
have
signed
up
for
most
of
those
I
think
in
there,
and
there
is
some
progress
being
made.
Maybe
next
week
we
can
at
our
meeting
reach
in
them
go
through
and
just
ask
you
know
one
project
at
a
time.
What's
the
status
of
this
or
one
that
one
issue
at
a
time?
Sorry!