►
From YouTube: Kubernetes SIG Architecture 20190718
Description
Minutes are at https://bit.ly/sig-architecture
A
A
B
D
D
B
D
D
Io
namespace
like
what
would
what
would
that
look
like
both
process,
wise
and
technically
like
for
today,
you
can't
rename
CRT
groups
so
I
think
as
long
as
the
guidance
is
clear
about
what
it
currently
means
and
what
the
limitations
currently
are
like.
If
you
do
this,
there's
not
a
clear
path
for
moving
between
API
groups.
There
are
desires,
I
think
to
enable
that,
but
we're
not
sure
exactly
what
that
would
look
like
at
this
point:
I
I'm,
pretty
happy
with
the
current
state
of
that
proposal.
D
I
know:
Tim
Hakan
wasn't
thrilled
with
it's
still
sort
of
looking
like
Cates
I/o.
If
you
just
glance
at
it,
but
I,
don't
I,
don't
know
if
you
consider
that
a
hard
block
or
if
that
was
just
kind
of
well
I,
can
live
with
it.
I
think
he's
out
of
the
office,
but
yeah
I
think
where
it's
at
you
said
it
well
Tim.
It's
like
an
uneasy
like
we
need
a
place
for
people
to
do
stuff,
yeah.
E
D
I
mean
if
our
statement
is
that
domain
qualification
is
the
important
thing
then,
like
anyone
can
get
a
Kate's
looking
domain
and
do
stuff
under
it.
And
it's
you
know,
it's
gonna
be
considered.
Okay,
so
I
think
us
having
an
X
prefix
at
least
has
prior
art
for
experimental
extension
stuff
in
other
areas
of
computing.
I.
Don't
know
it
seems
okay,
so.
A
If
I
understand,
to
recap
it
here
we're
suggesting
that
the
kubernetes,
I/o
or
Kate's
dot,
IO
namespace,
is
only
four
core
API
sand.
If
you're
going
to
do
something
such
as
I'll
use
when
I
work
on
the
application,
CRT
and
controller,
which
is
under
kubernetes
SIG's,
that
should
use
X
Kate's
IO
instead
of
Kate's.
That
IO
is
its
identifier
and
then
anything
that's
outside
of
the
kubernetes
org
should
use
their
own
identifier,
not
kubernetes
or
KS
or
X,
or
any
of
that
right.
Right.
B
C
D
D
Those
would
have
been
fine
to
be
implemented
using
crts
if
they
went
through
API
review
and
we
had
a
coherent
story
around
how
those
should
be
installed
and
distributed.
So
it's
it's
more
about
how
you
put
in
port,
official
or
reviewed
or
supported
an
API
is
that
determines
whether
it's
under
Kate's
IO
or
under
the
more
kubernetes
adjacent,
X,
K,
tayo,
I
think
one.
The
goal
is
to
give
six
a
place
to
operate.
A
F
D
It's
about
repo
and
more
about
their
to
demand.
One
is
how
official
and
supported
and
reviewed
it
is,
and
the
other
is
whether
the
concept
that
is
being
modeled
and
surface
in
the
API
is
considered
kind
of
an
extension
or
more
fundamental.
And
so
some
of
the
things
like
CSI
are
going
to
be
more
fundamental
because
that
they
are
the
extension
points
for
storage,
whereas
something
that
it's
building
on
top
of
fundamental
kubernetes
concepts
could
be
more
of
an
extension
and
might
belong
other
xscape.
D
F
F
G
D
A
And
so
if
we
say
it's
part
of
the
API
review
process,
it
is
something
like
CSI.
That's
got
extensions.
This
kind
of
gives
examples,
so
folks
can
extrapolate
it
because
I'm
looking
at
this
going,
okay,
say:
gaps
created
the
application,
C
or
D
and
controller,
and
it
sounds
like
that
should
live
in
X
Katie
Oh,
given
everything
I
just
heard
here,
and
so
now
am
I.
Even
asking
questions
like
it's
beta
and
it's
applications
taps
dot.
Kate,
zero
is
the
current
namespace
today.
How
do
we
now
deal
with
this?
A
H
The
one
question
I
had
was
there
was
a
discussion
on
the
document
describing
how
we
would
intend
access
gates
that
I
would
have
used
and
Jordan.
You
proposed
the
prefix
of
the
sig
name,
given
that,
like
our
six
structures,
have
proven
fluid
over
the
course
of
the
project
and
they're
not
really
externally
understood
by
users.
Is
that
really
guidance
that
we
would
want
to
present
versus
policing
just
registers
for
a
non
subdomain
under
X
gates,
io
and
doesn't
carve
up
something
to
make
that
sig
I?
Think.
B
Instead
of
bike
shedding
on
this
particular
topic
year,
I
think
we
need
to
have
like,
as
met
point
out,
the
whole
document
that
gives
sort
of
guidance
and
guidelines,
because
that's
kind
of
what
my
forcing
this
was
kind
of
a
roundabout
way
of
requesting
that
document
of
guidelines,
because,
as
Matt
points
out
like
it's
clear
that
there
is
a
host
of
ecosystem
that
wants
to
do
right
by
the
community
and
to
find
the
happy
landing
zone.
But
there
is
no
there's
no
guide
for
them.
D
There
are
the
problem:
there
are
huge
use
cases
trying
to
be
accomplished
by
this
one
mechanism.
One
is
given
SIG's
a
place
to
experiment
and
iterate
quickly,
and
so,
if
every
stick
can
just
assume
that
their
Signum
is
a
place
under
which
they
can
iterate,
then
that
you
know
avoids
conflicts
on
api's,
we're
here
ending
on
some
cigs
map.
D
Pretty
nazi
games
map
pretty
naturally
two
concepts
that
would
make
sense
to
an
end
user
so
like
off
or
node
or
storage,
some
less
so,
and
so
the
idea
was
and
I
agree
with
Tim
like
these
is
getting
down
to
the
nitty-gritty
details.
We
can
work
that
out
offline,
but
if
it
seeks
a
place
under
which
they
can
experiment
and
own
the
whole
prefix
space
and
then
if
they.
D
A
So
how
about
this
I'll
propose
to
start
a
document
and
share
it
out
and
try
to
initially
capture
the
guidance
that
I
think
I
heard
here,
and
then
we
can
iterate
on
that
until
it
gets
into
decent
shape
and
we
can
post
it
somewhere
more
visible
in
public,
with
the
guidance
does
that
sound,
acceptable
I'll.
Take
the
option
to
start
this.
D
A
D
I
called
for
an
act
on
kind
of
the
concrete
proposal
and
would
like
people
to
comment
there.
So
please
Daniel,
you
want
to
comment
there.
Brian
was
okay
with
it.
If
you
wants
to
comment
and
then
we
can
work
through
kind
of
the
mechanics
and
like
Matt
was
saying
flushing
out
the
guidance
with
examples
and
yeah
just
wherever
it's
unclear,
we
can
make
it
more
clear.
E
So
we
we
have
discussed
Tim's
change
to
the
to
the
APA
review
policy
document,
but
we
haven't
discussed
the
other
thing
which
is
quite
related
and
triggered
this,
which
is
the
like
I,
think
it's
a
cap
that
that
David
even
started
proposing
that.
Basically
we
require
C
or
DS,
claiming
to
be
in
Cades
IO
to
provide
a
link
to
the
place
where
they
were
approved
and
the
purpose
of
that
as
I
understand.
It
is
to
make
sure
that
cluster
administrators
have
some
way
of
telling
like
what
the
status
of
this
C
or
D
is
like.
E
Anybody
can
write
case
that
IO
and
the
group
name.
So
that's
this
makes
it
visible
to
the
person
installing
the
CRT,
like
this
C
or
D
claims.
It's
in
case
that
I
oh,
this
is
the
link.
I
can
follow
to
see
why
they
claim
that
or
I
can
put
in
there
like,
like
I,
haven't
actually
gone
through
the
process.
So
as
an
escape
hatch,
I
don't
know
if
David
will
agree
with
that
summary,
but
I
think.
E
D
Mean
based
on
the
accidents
we've
seen
that
there
are
two
main
purposes
behind
it.
One
is
so
administrators
can,
you
know,
follow
a
thread
to
make
sure
what
they
have
in
their
hand
the
manifest
they
have
in
their
hand,
actually
matches
like
the
shape
the
safe
guys
supposed
to
have,
and
the
other
is
just
a
prevent
accidents.
D
We
there
was
cargo
bolting
of
bad
examples
and
things
that
accidentally
used
its
IO
namespaces
that
weren't,
even
in
the
kids
project,
good
burn
any
project,
and
so
this
this
makes
it
difficult
to
accidentally
make
an
API
in
the
domain
and
based
on
Tim's,
based
on
the
XK
tayo
like
where
we
settled
for
that
I.
Don't
think
this
really
impacts
that
either
way
the
question
about
existing
community
API
is
that
are
using
its
io
suffixes.
D
E
E
D
B
History
has
taught
us
that
whenever
we
try
to
make
substantial
changes
in
policy
that
there's
always
going
to
be
people
who
said
I
didn't
hear
that
perhaps
late
raising
it
to
sig
leads
in
more
detail
might
be
beneficial
because
I
think,
like
Matt,
pointed
out
with
regards
to
their
separate
controller.
There's
a
lot
of
stuff
that
exists
and
there'd
be
a
lot
of
stuff
that
people
would
want
to
change,
to
follow
the
best
practices
here,
so
I
think
maybe
having
some
some
broader
awareness.
I
I.
D
I
think
people
want
to
do
the
right
thing.
So
I
agree
that,
like
letting
taking
the
policy
that
has
existed
and
we're
trying
to
figure
out
how
to
make
people
more
aware
of
and
sending
it
to
the
cygnets
channels
lists
cubed
eV,
like
the
places
in
the
community
that
are
building
all
these
things.
Let
people
know
now
so
that
stuff,
that's
in
flight
and
if
it
hasn't
already
been
released,
can
tweak
its
name
and
the
stuff
that
has
been
can
consider
where
it's
at
and
its
attorney
lifecycle
and
consider
it
yeah.
A
I
mean
this
is
the
reason
that
I
actually
wanted
to
get
that
document
going
was
so
we
get
clear
guidance
for
people
and
we
get
it
in
some
kind
of
written
for
more
happy,
communicating
it,
and
then
we
put
it
out
everywhere.
A
blog
post,
Doc's
community,
meeting,
ke
dev,
get
it
out
to
all
the
leads
and
chairs
and
just
just
kind
of
blast
it
out,
because
it's
a
policy
change
and
folks
may
miss
one
place.
But
if
it
goes
a
lot
of
places
they
might
catch
it
and
it
can
start
to
catch
on.
A
G
C
G
G
Guess
my
next
question,
though,
is
that
do
we
want
to
actually
have
some
sort
of
lockdown
for
X
K
IO
to
make
sure
that
you
at
least
point
to
the
you
know
the
sub-project?
That's
doing
it
is
part
of
the
kubernetes
project
because
it
may
be
that
people,
okay,
nao,
doesn't
work.
Let
me
just
do
X
and
that's
that.
E
J
D
E
D
And
the
problem
and
was
cargo
halting
of
its
I/o
specifically
and
I-
think
solving
that
in
a
really
lightweight
way
now
has
value
the
the
idea
that
you
can
like
point
to
canonical
schemas
like
that
would
apply,
like
you
said,
Joe
for
all
API
groups.
You
know
by
domain
suffix
or
something
that
I
see
some
value
in
that,
but
I
think
that's
a
broader,
bigger
future
thing.
D
D
So,
just
to
run
through
some
recent
things
have
been
going
on
the
Windows
run
as
username.
Alpha
field
emerged
this
week.
That
is
the
second
windows
specific
field
in
pods
that
wraps
up
the
first
round
of
those
holes
from
Sig
Windows
that
allows
launching
containers
as
a
specific
Windows
user
name.
So
that
is
an
alpha.
In
116
the
admission
webhook
registration
api's
got
promoted
to
v1.
After
all,
the
work
that
happened
in
the
last
release.
D
A
lot
of
that
work
was
validated
by
consumers
before
and
after
the
115
release
and
was
promoted
to
V
1
with
no
schema
changes,
but
some
of
the
defaults
were
improved
to
make
webhooks
safer
by
default.
So
if
you
don't
know
that
failure
policy
is
a
thing
by
default,
if
the
call
to
your
web
hook
fails,
the
request
is
blocked
instead
of
the
previous
default,
which
was
to
fail
open
a
few.
A
few
de-puff
like
that
tightened
up,
timeouts
things
like
that,
but
but
no
schema
changes.
D
There
are
several
reviews
that
are
in
progress.
You
can
look
at
the
API
reviews
Forge
to
see
what
those
are
and,
if
you
have
questions
about
one
that
is
not
getting
attention,
make
sure
it's
in
the
116
milestone
and
in
the
reviewers
who
are
assigned
if
you
are
in
a
cig
and
have
changes
that
require
API
reviews.
Please
make
sure
that
the
reviewers
for
your
cig
are
paired
up
with
the
approver
doing
the
the
review
to
make
sure
they're
getting
exposure
and
experience
and
lots
of
different
kinds
of
API
changes.
D
D
D
D
The
the
shadowing
is
intended
to
get
people
exposed
to
different
types
of
API
reviews,
and
we
haven't
actually
had
shadow
errs
that
I'm
aware
of
go
through
all
the
different
types
like
entirely
new
API
types
and
it
guide
changes
so
we're
that
the
document
that
you
are
updating
is
where
those
details
would
go,
and
that
needs
to
be
added
to
that.
Okay,.
D
K
D
K
F
Implementations
out
there
I
think
the
thing
is
missing
from
that
cap.
I
think
I
left
this
key
Python.
There
is
like
what
should
we
do
and
it's
been
sort
of
the
blocker
to
date,
which
is
when
there
are
manifests,
which,
for
whatever
reason,
wants
to
run
the
master?
What
should
they
do
and
I
think
the
answer
to
date
has
been?
We
will
address
that
with
like
pod
identity
and
things
like
that,
but
those
things
aren't
ready
yet
and
so
I
think
we
need
to
understand
like
it's.
F
L
L
L
Cmc
have
had
had
hired
some
contractors
they're
wrapping
up
this
week,
so
we're
just
trying
to
get
all
of
their
PCP
I
was
resolved,
so
anybody
who's
commenting
on
any
of
those
opening
needs,
accrue.
Work
late
and
I
know.
You've
looked
at
something
Brian's
gonna
look
at
some
as
well.
There
are
a
few
that
still
need
to
be
moved
in
to
approve
all,
though,
because
I
need
some
additional
updates.
L
The
additionally
we
have
an
effort
going
on
so
CN
CF
is
also
funding.
Hippie
hackers
group
III
he's
they've
been
funding
the
in
case
new
quirk,
but
they're.
Also
now
funding
some
work
out
of
API
snoop.
We
got
a
bunch
of
information
about
different
API
that
are
not
yet
covered
in
informants
or
even
that
are
being
used
by
core
components
or
by
different
ant
s,
incidentally,
and
so
he's
gonna
keep
working
on
promoting
those
or
those
that's
making
progress
already,
actually,
which
is
good.
L
Your
comments
is
looking
at
initially
the
way
the
caps
written
we're
sort
of
defining
those
behaviours
just
in
a
mall
in
our
own
missile
format.
But
it's
been
suggested
it
using
something
like
darken
or
something
existing
behavior,
behavior
definition
DSL
or
something
might
be
helpful.
So
anybody
with
experience
but
those
those
DSL
specifically
gherkin
I'd
love
to
hear
from
that
I
have
sort
of
mixed
mixed.
L
L
I
is
gonna,
actually
take
we're
gonna
redirect
some
of
the
resources
that
over
can
you
cast
you
and
have
them
focus
on
doing
a
little
spike
to
investigate,
build
out
some
actual
examples
with
the
the
Durkin
language
to
make
sure
that
it
its
expressive
enough
and-
and
we
can
make
it
reusable
enough.
The
goal
here
would
be
the
the
that
this
group
can
go
to
the
SIG's
and
say
we
want
you
to
define
the
set
of
behaviors.
L
That
can
be
that
are
important
to
your
conformance,
within
your
sake,
so
stepping
back
one
second
part
of
the
cap
is
building
tooling,
that
automates
the
low-hanging
fruit
of
you
know
you
create
a
resource.
You
make
some
change
to
it.
The
state
of
the
cluster
converges
in
the
way
you
expect
so
we're
automating
a
bunch
of
scaffolding
for
that.
But
there
are
things
that
we
can't
automate
directly
off,
of
that
a
sort
of
simple
example
would
be
pod
pod
communication,
there's
no
API.
That
really
is
specifying
conf
on
communication.
L
We
just
expect
it
to
exist,
so
some
human
has
to
write
this
behavior
and
we'd.
Rather
that
can
have
the
the
that
behavior
accrued
separately
from
the
tests
that
actually
people
met
that
behavior
we'd
like
to
be
able
to
go
to
the
SIG's
and
have
a
ciggy
find
those
lists
of
behaviors
independently
of
the
dentist
or
the
conformance
tests
that
that
evaluate
them.
So.
A
K
So
one
of
the
one
of
the
conformance
tests
that
was
suggested
to
be
proposed
to
conformance
was
the
note
or
the
HP
a
horizontal
pod,
auto
scaling
conformance
test.
Hpa
is
a
v1
API
within
kubernetes,
however
metrics
and
the
supporting
infrastructure
for
it
is
optional,
and
so
we
merged
it.
It
broke
a
few
things
that
didn't
install
metrics,
metrics,
has
kind
of
a
maybe
I,
don't
say
a
default
or
optional
default
implementation
within
the
Q
project
and
a
number
of
other
alternatives.
K
I'd
say:
we've
never
made
the
statement
as
a
group
that
metrics
is
required
for
all
conformant
distributions,
and
so
this
raises
an
interesting
policy
point
of
whether
an
API
with
a
very
clearly
defined
implementation,
that
is
part
of
the
cluster
HPA
its
interface
and
how
its
implemented
relative
to
the
metrics
API
might
very
well
trigger
conformance.
It
is
not
required
on
all
clusters
and
so
there's
a
couple
of
paths
forward
and
we
reverted
it
temporarily
from
being
added
to
conformance,
but
we
need
to
have
a
follow-up
in
the
conformance
working
group
to
discuss
ways
forward.
K
A
couple
of
them
were,
you
know,
promoting
the
metrics
to
required,
which
I,
don't
think.
There's
a
ton
of
appetite
for
another
might
be
that
the
conformance
test
itself
should
skip.
If
you
don't
have
a
metrics
implementation
in
installed
and
there's.
Maybe
a
third
or
fourth
option,
which
is
this
doesn't
belong
in
the
defaults
profile.
L
Yeah
I
mean
I
think
we
haven't
fully
defined
profiles
yet
really
so
strictly
speaking,
this
is
I,
guess
optionally,
because
the
underlying
infrastructure
is
optional,
but
I,
don't
think
that's
a
satisfactory
answer
that
we've
got
right
now
for
a
lot
of
things
like
this.
That
has
you
know
I
guess
maybe
this
is
just
indicating
me
to
push
far
enough
well.
K
And
it's
a
great
example
of
it's
a
component
that
is
part
of
what
we,
what
most
people
would
consider
the
cube
API
when
it
is
installed
and
configured
and
that
behavior
being
defined
to
a
reasonable
degree
for
people
who
expect
HPA
to
work
with
multiple
different
metrics
backends
is
relatively
value.
It's
not
a
relatively
valuable.
K
It's
not
required
that
it
be
conformance
for
that
value
to
exist,
but
I
do
think
it's
a
good
example
of
we
depend
on
an
input,
and
once
we
have
an
input,
we
provided
defined
behavior
and
that's
actually
a
that's
actually
an
opportunity
for
us
to
extend
this
and
think
about
how
we
would
handle
other,
potentially
optional.
Api's
I
know.
B
L
We
definitely
have
a
need
to
say:
okay,
there's
a
set
of
features
that,
if
they're,
if
they
are
enabled
within
a
cluster,
we
want
them
to
all
be.
We
want
them
to
behave
the
same
way
in
all
clusters
and
that's
what
against
the
profiles
right
now
is
is
around
and
we
need
to
I
guess
we
need
to
revisit.
L
K
L
In
some
of
these,
and
is
it
I,
don't
know
if
this
is
true,
so
I
need
to
investigate
this
more,
but
from
some
of
the
work
in
trying
to
do
some
conformance
tests
around
priests
table,
there
were
some
indication
that,
depending
on
what
CRI
you're
using
you
may
get
different
behavior,
so
that
that
is
an
interesting
policy
point
of
like
okay.
How
do
we
it's
almost
like?
We've,
we're
already
broken
as
far
as
conformance
is
concerned,
and
how
do
we
handle
that
situation?
A
J
Based
on
that
work,
we
found
a
few
things
that
we
could
fix,
but
then
we
are
facing
some
pushback
from
people
saying:
okay,
we
don't
want
to
do
this,
so
that
was
one
thing.
So
what
a
period
of
time
really
get
to
the
point
where
we'll
have
a
lot
of
projects
with
specific
shots,
but
they'll
still
be
a
bunch
of
things
with
random
trust,
especially
the
x
net
stuff
for
sure,
so
that
that
was
one
thing.
J
So
I
don't
want
to
make
it
mandatory
right
now
or
even
later,
because
it's
you
know,
for
example,
with
C
advisor
right.
We
tend
to
cut
a
random
shot
in
C
advisor,
try
it
out
and
then
move
to
a
specific
version
of
C
Anderson,
so
I
think
we
need
to
keep
that
going,
so
it
will
be
like
we
now
will
have
to
every
release.
J
J
The
main
thing
why
we
want
to
do
this
is
so
that
when,
when
we
want
to
get
to
the
point
where,
for
example,
in
the
Python
right,
so
when
there
is
new
release
coming
out,
then
it's
easier
for
people
to
look
at
the
change
logs
and
you
know
see
if
there
was
anything
security
fixes
and
things
like
that
and
update.
So
we
haven't
been
able
to
get
to
that
point
for
us
every
single
time.
It's
inspection
right
it
and
it's
very
hard
to
keep
up
with
repositories
like
doctor-doctor,
where
yeah
no
idea
what's
going
on.
J
J
So
as
part
of
this
process,
we
also
added
modeling
to
some
additional
C
entry
volume
providers
as
well.
So
earlier
we
used
to
have
only
warnings
for
the
cloud
providers.
Now
we
have
warnings
for
deprecation
warnings
for
volume
plugins
as
well.
So
if
you
know
of
any
volume
plugins
that
people
are
not,
if
are
still
essentially,
then
we
can
go
add
a
entry
in
for
concentrating
a
duplication
warning
for
that.
So
that
was
another
one.
J
What
else
there
are
two
two
different
vendor
dependencies
that
we
are
trying
to
get
it
off.
One
is
the
inotify
one
and
the
other
one
is
the
gho
DSS
llamo,
so
that
has
worked
in
progress
as
well.
So
that's
the
main
highlights
of
the
things
that
we
were
working
on.
So
if
anybody
is
interested
in
this
work,
please
come
to
our
meetings
and
there's
plenty
of
things
to
do
so
even
on
even
today
on
Twitter
somebody
was
saying
that
go
dependency,
stuff
was
so
hard
with
curators
and
they
don't
like
the
staging
stuff.
J
A
B
Just
want
to
do
a
PSA
before
you
get
an
issue
strategy
put
at
the
end
was
that
there's
a
cap,
that's
going
I
think
came
from
storage
folks,
which
kind
of
touches
that
ecology
awareness
in
labels
issue
I
was
surprised
to
see
that
some
high
level
API
Rivers
had
thought.
This
was
okay,
because
I
thought
it
was
sacrosanct
to
not
encode
that
type
of
information
instead
of
labels.
So
I
just
wanted
to
raise
awareness.
Amoebic
we'll
talk
about
it
next
name.
A
A
I
Hey
yo
I,
don't
think
bother
is
here
so,
but
unless
someone
is,
someone
else
wants
to
speak
out
to
the
issues
I
can
take.
It
and
I
actually
put
a
patek
put
a
couple
in
there.
So
for
the
for
the
past
couple
of
weeks,
we've
already
in
some
other
some
other
people,
whose
name
I
don't
remember-
we've
been
triage
in
the
sig
architecture
issues.
There
are
so
a
good
handful.
They
need
some
attention.
I
I
just
picked
a
I
just
chose
they
say
the
top
five
issues
have
been
updated
more
recently,
just
for
the
sake
of
time
and
not
to
inundate
everyone
with
with
a
ton
of
work
to
do
and
really
just
want
it
just
wanted
to
throw
them
out
there
see.
If
anyone
here
has
any
update
has
any
updates.
Most
of
them
are
relatively
old
and
there's
not
a
lot
of
information
on
next
steps
or
things
that
need
to
be
done.
I.
J
N
So,
regarding
updating
top-level
approvers
I
think
we
can
actually
close
this
now
I
think
we
like
the
suggested
action
items
we
suggest,
like
I,
suggested
couple
action
items
that
we
can
reduce
the
necessary
necessity
to
like
have
many
more
people
here
and
I
think
we
actually
did
all
of
those
or
at
least
most
of
those
and
it
I
think
it
works
fine.
So
until
we
we
have
a
better
evidence
that
we
really
need
that
I
think
we
can
actually
close
this.
I
Really
quick
question
for
future
reference:
a
if
we
keep
doing
the
issue
triage
in
these
sessions,
given
a
given
that
time
and
what
type
of
information
module
a
will
make.
It
will
make
this
process
a
call
come
faster
for
a
for
all
of
it,
wait
what
they,
what
other
information
will
be
useful
to,
including
this
update
a.