►
From YouTube: 20191010 SIG Arch Community Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
We
do
have
a
light
agenda
today
and
I
was
hoping
that
we
could
get
ourselves
organized
a
little
bit
around
with
the
recent
turn
in
you
know
the
folks
working
on
the
sig
architecture,
so
I
wanted
to
open
up
this
dock
I,
don't
know
if
anybody
had
a
chance
to
go
through
this
dock
and
add
their
names.
What
I
will
do
is
I.
Let
me
pace
this
to
the
channel
as
well,
so
you.
B
B
Probably
some
of
it
needs
to
I,
don't
know
we
there
needs
to
be
a
lead
on
any
one
of
these
things.
It's
mainly
my
point.
Otherwise
you
know
it's
nobody.
We
really
will
expect
everybody
else
to
do
it.
So
if
we're
gonna
organize
this
way,
I
just
think
we
need
to
make
sure
that
there's
a
point
person
for
each
of
these.
C
C
The
one
ask
I
have,
as
we
start
to
fan
this
out
is
like
that.
We
find
the
appropriate
meeting
cadence
for
these
various
pieces,
so
that
people
can
actually
meet
and
also
do
other
activities.
I
think
a
lot
of
us
have
a
ton
of
the
overlapping
items.
So
I
don't
know
for
some
of
these
items
that
we
were
assuming
different
meeting,
Cadence's
form
or
ad-hoc
interaction.
A
Okay,
yeah,
let
me
say
what
I
was
thinking
when
I
was
doing
this
right.
So,
first
of
all,
we
have
the
four
sub
projects
they
already
have
leads
and
they
have
their
current
cadence.
All
of
them
have
you
know,
Google
Docs,
and
they
have
project
boards
and
whatnot,
and
the
API
reviews
have
BOTS.
So
these
four
I'm
not
really
worried
about
right
now.
This
was
more
about
making
sure
that
if
there
are
new
people
coming
in,
they
know
that
these
are
the
four
projects
that
they
need
to
go
to
so
Jared.
A
Who
else
can
so?
Please
make
sure
that
you
talk
to
the
leads
of
those
are
the
sub
projects
that
you
are
interested
in
the
rest
rest
of
the
people
that
I
see
the
names?
You
know
how
to
Navy
hit
the
Cuban
interest
community,
so
I'm
not
worried
about
you,
know
Quinton
art
or
Jorge
Orta
for
that
matter.
So
these
four
things
right,
the
four
things
on
top
the
way
I
was
thinking
about
it
was
we
know.
We've
traditionally
had
problems
with
the
technical
debt
and
there's
like
nobody
paying
attention
to
it
then
kept
curation.
A
We
still
don't
have
a
cadence
this
some
of
this
work
was
in
sick
p.m.
before.
But
then
what
do
we
do
on
the
architecture?
Side
was
was
the
idea
here
then
the
topics
we
constantly
had
we've
canceled
meetings
several
times
in
the
last
few
months.
Just
because
you
know
we
don't
have
you
know
timely
meeting
topics
that
are
raised,
that
we
could
then
go
around
finding
people
to
that
who
that
might
affect
that
might
be
affected
by
specific
table
topics
and
need
input
on
specific
topics.
A
Then
triage
we've
tried
to
do
this
before
in
a
separate
call
and
try
to
bring
stuff
before
the
meeting
and
add
it
to
the
agenda.
So
these
four
I
don't
see
these
four
as
sub
projects
per
se
right
now,
because
we
have
to
bootstrap
them,
and
the
idea
here
would
be
to
get
the
people
looking
at
these
four
groups
to
propose
things
that
we
could
talk
about
in
the
regular
cigarette
lecture.
A
You
know,
for
example,
these
three
could
meet
outside
of
this
main,
seek
architecture,
call
and
propose
items
to
the
same
goes
with
these
four
people.
If
they
need
our
help
in
terms
of
you
know
self
organize,
if
self
organization
doesn't
work,
then
you
know
we
can
put
some
structure
into
it
saying
okay,
these
are
the
needs
kind
of
thing,
I'm.
C
Sorry
so
I'm,
just
kind
of
mapped
with
things
have
been
working,
I
know
what
you're
posing
here.
So
the
issue
in
PR
triage
view
that,
as
just
a
general
helping
framework
that
we
tried
to
apply
the
other
six,
so
that
seems
to
make
perfect
sense
the
meaning
topics
curation.
We
had
previously
had
a
meeting
to
discuss
what
to
do
in
the
meeting,
and
then
we
started
transitioning
to
just
in
on
over
slack
I.
C
A
Would
leave
it
up
to
the
set
of
people,
so
you
bring
whatever
they
think
would
be
of
value
across
so
the
way
I
was
thinking
about
it
was.
If
it
is
specific
to
one
sink,
then
it
might
not.
We
might
not
have
to
look
at
it
if
it's
crossing
SIG's,
then
we
might
have
to
you,
know,
help
move
the
cap
around
sorry
about
saying
something.
I
find.
D
I
would
personally
find
that
valuable
and
I
think
having
a
group
would
be
a
forcing
function
to
do
some
of
that.
Not
that
I
want
another
meeting,
but
I
need
a
good
excuse
to
put
time
aside
and
read.
Caps
could
publicly
shame
the
rest
of
us.
Well,
I
was
hoping
that
I
could
get
the
four
or
five
of
you
to
do
the
same,
and
we
could
shard
the
work
out
and
summarize
the
caps
and
like
actually
make
it
not
particularly
painful
and
and
interesting
I
think.
E
So
I
agree
with
Tim's
supposition.
I
think
you
can
make
this
a
standing
item
as
part
of
the
this
meeting,
where
they
just
a
subsection
or
small
working.
Your
just
reports
out
updates
I,
don't
think
we
need
to
formalism
here
other
than
for
most
of
those
sub
elements
of
above
but
I
think
someone
who
helps
to
curate
the
meeting
it
helps
to
drive
the
agenda
and
a
format.
B
I
mean
I
think
that's
a
good
point.
I,
don't
I,
don't
know
that
we
want
to
add
topics
just
for
the
sake
of
having
a
meeting,
but
I
do
definitely
think
the
strategy
thus
far
has
been.
If
you
want
to
talk
about
something
in
the
meeting
raising
the
mailing
list
so
that
it's
more
widely
distributed
in
those
people
who
are
are
interested
in
it
can
show
up
to
the
meeting
for
live
discussion.
B
I
think,
probably
we
haven't
done
a
readout
from
the
different
sub
projects
for
a
while
I
think
it's
reasonable
that
there
is
some
small
standing
agenda
of
readouts
from
the
sub-project.
So
maybe
like
a
highlighted
cap
like
this,
but
I,
don't
think
we
want
to.
You
know
necessarily
go
in
search
of
topics
just
to
fill
time.
D
F
Do
you
want
to
try
a
smaller
scale?
First
Tim,
like
maybe
you
see,
if
you
can?
Actually
you
personally
can
get
traction
with
two
other
people
to
convince
to
do
this,
like
I,
think
you
have
a
good
idea
and
I
know
myself
and
the
idea
of
social
peer
pressure
to
get
me
to
actually
sit
down
and
read
it.
It
may
actually
work
okay,.
G
D
C
C
He
also
has
like
yeah
I,
think
I'll
take
it
from
your
office
David,
but
the
the
question
I
have
is
like
there's.
The
idea
here
is
not
to
act
as
a
gatekeeper
to
get
to
caps
but
more
to
advertise
that
which
is
happening
around
the
community.
I
worry
about
by
structuring
this
some
might
view
this
as
a
gatekeeping
role,
ya.
D
Know
I
do
it's
a
great
point.
I
do
not
want
to
make
this
a
gatekeeping
role
unless
we
detect
that
there
are
actually
systemic
problems
that
were
not
handling,
otherwise
I
would
say
initially.
This
is
a
you
know
the
senior
people
on
the
project
looking
at
what's
going
on
in
the
project
and
making
each
other
aware
of
the
interesting
parts
right,
maybe
caps
at
home.
H
D
C
D
F
E
Then
go
Dericks,
concern
or
question.
Is
that
maybe
having
a
well-defined
charter
might
help
to
sort
of
alleviate,
because,
like
one
of
the
things
I
would
ask
for
this
group?
Is
this
the
problem
that
we
have
the
performance
of
project
is
enforcement?
Okay,
we
have
a
lot
of
caps,
but
we
don't
necessarily
have
enforcement
for
policies
that
we
have
around
some
of
these
proposals.
So,
okay.
H
A
A
So
what
we
should
do
here
is
the
current
three
chairs,
plus
these
three
people
will
basically
will
ping
each
other
and
see
what
needs
to
be
talked
about.
So
that
is
the
way
I
was
thinking
about
it.
This
would
be
like
a
short
conversation
on
slack
fall
and
or
followed
by.
You
know
any
mail
to
the
Google
Group.
So
we
have
you
know
things
on
the
agenda
for
the
coming
Thursday.
Does
that
work
well,
I
think.
A
A
A
Everything
or
do
we
need
to
make
it
like
a
sub-project
of
Sagarika,
textured
I,
don't
know
yet
this
is
just
to
get
it
started
at
this
point,
because
I
know
that
we
have
Brian
grant
has
a
list
of
issues.
You
know,
I
have
a
list
of
issues
I'm
sure
all
of
us
have
lists
of
issues
that
go
stale
and
we
keep.
You
know
reviving
them.
So
this
is
an
effort
to
collect
all
of
them
and
see.
If
there
is
anything
we
could
do.
You
know
e-even.
D
B
A
Not
necessarily
John,
for
example,
Brian
had
tried
out
a
a
couple
of
months
ago
about
something
that
was
overarching
everybody,
so
let's
take
a
stab
at
it
and
if
it
is
specific
to
specific
SIG's,
then
we'll
make
sure
that
they
see
it
and
they
can
dispense
with
that
right
and
if
there
are
things
that
across
six,
then
we
will
try
to
help
with
that.
But
this,
the
the
point
here
is,
we
should
have
an
inventory.
We
don't
have
an
inventory
and
I
like
the
project
board
idea.
So
let
let's
start
with
that
in.
D
My
mind
that
the
best
kind
for
this
would
be
the
types
of
things
that
there
isn't
a
clear
owner
for
like
if
it's
something
in
a
particular
component
yeah.
That's
that's
that
SIG's
responsibility
to
prioritize
and
and
work
through.
But
if
there's
something
like
everyone
agrees,
it's
a
problem
and
no
one
knows
who
owns
it
like
that.
D
A
A
A
A
A
A
You
know
on
the
project
board
once
we
advertise
it
and
if
you
are
not
sure
just
ping
me
and
we
will
talk
about,
it
sounds
good.
Yes,
okay,
so
going
on
to
the
force
of
projects
I,
don't
we
already
talked
about
this
unless
anybody
any
of
the
new
people
who
are
on
who
put
their
name
here,
had
a
question
about
it.
A
Or
can
on
code
organization
going
once
going
twice?
Okay,
then,
going
to
the
section
about
cigar
collector
shares,
so
there
were
three.
Oh
there
were
three
people
who
wear
the
cigar.
Collector
chairs,
for
there
were
two
running
the
cigarette
picture
for
a
while,
and
then
we
added
Mac
and
then
we
added
Derek
and
I,
and
then
we
went
back
to
three
given
what
we
have
right
now,
given
you
know
what
we
are
envisioning
here
with
these
four
new
task
forces.
Do
we
need
more
cigar
critic,
church
chairs,
that
that's
a
question
here?
F
G
Iii
agree:
I.
Think
three
is
actually
a
fine
number
gives
us
enough
coverage
if
people
are
out
and
as
long
as
they're
all
actually
able
to
devote
about
time
and
do
it
I
think
I
think
it's
great
I
just
put
my
name
down
there,
because
people
say
we
wanted
more
help
volunteered,
but
I.
Don't
actually
think
we
need
more
than
three
effective
chairs.
Okay
sounds.
A
D
E
Think
that's
great
I
want
to
stress
to
you
from
a
community
perspective
that
a
chair
is
a
responsibility.
It's
not
like
a
status
and
privilege.
It
is
a
lot
of
work.
I
said
like.
If
people
show
up
to
help
do
the
work
they'll
naturally
be
promoted
to
those
chairs
just
by
their
efforts.
So
by
all
means,
if
you
are
interested
in
becoming
a
chair,
please
show
up
and
help
we
we
always
could
use
the
people
who
do
the
chocolate
and
carry
the
water.
B
Well,
the
discussion
on
I
was
going
to
say
you
know
later
today,
discussion,
people
weren't
sure
whether
we
should
use
a
project
or
not.
So
it's
not
officially
a
sub
project.
Yet
the
the
issue
is
whether
there's
ongoing
work
or
whether
this
is
implemented,
tap
and
move
on,
and
in
which
case
we
don't
really
need
a
sub-project,
because
the
intent
is
that
the
reviews
aren't
like
an
active
pool
of
reviewers
specialized
in
that
it's
that
we
build
the
tooling
and
and
kind
of
enable
reviews
in
different
in
different
sections
by
different
different
people.
B
So
it's
it's
still
not
clear.
I
think
that
if
we
want
it,
I
think
there
are
other
related
things
that
we
could
put
under
this,
not
just
production
readiness
reviews,
but
like
the
the
the
cap
that
David
put
out
on
the
beta
policy,
the
the
definition
of
alpha
beta
ga
criteria
may
I
think
there
are
other
kind
of
issues
we
could
tackle,
potentially
under
the
same
group,
but
at
least
the
group
that
met
Tuesday
wasn't
thrilled
about
I.
Wasn't
you
know
enthusiastic
about
a
new
sub
project,
particularly
I?
Don't
think
anyone
is
against
it
either.
B
B
A
Okay,
so
there's
a
couple
of
questions
from
Jared
one
was
the
CLI
and
caps.
You
know
we'll
talk
to
him
when
he's
here
he's
not
here
anymore
right
now
and
the
other
one
was
a
whole
generation,
sub-project
and
Nikita
already
answered
so
I.
We
are
at
the
bottom
of
the
hour
to
31.
So,
let's
let
me
just
give
one
chance
to
anybody
who
hasn't
spoken
up
already.
A
H
H
H
I
F
A
F
Sure
so,
I'm
sure
many
people
are
aware
that
we
have
lots
of
beta
api's,
and
sometimes
it
takes
a
long
time
to
go
from
beta
to
GA,
and
this
cap
is
about
making
sure
that
during
that
time
frame,
we
didn't
just
I,
don't
want
to
say,
forget
about
a
feature
but
decide
that
something
else
is
more
important
and
I
have
some
personal
experience.
Writing
several
features.
F
I
did
things
like
the
crdi
API,
which
just
plain
took
a
long
time
to
get
GA,
but
I
also
was
responsible
for
some
of
the
pieces
in
the
CSR
API,
which
has
languished
similarly,
the
mission
webhook
api.
It
took
a
long
time
thanks
to
Jordan
Leggett,
for
pushing
that
one
over
the
line,
because
we
had
left
it
in
beta
for
almost
two
years
and
as
we
do
that
it
has
impacts
for
us
trying
to
promote
something
to
GA
and
looking
at
like
well.
F
What
behavior
changes
can
we
actually
make
now
that
we
know
what
we
want
to
do?
Can
we
actually
make
the
changes
and
it
has
impacts
for
the
consumers
and
I'm,
also
a
consumer
downstream,
where
I'm,
using
it
and
I
get
used
to
using
it
and
I?
Forget
that
the
thing
is
beta,
and
so
it
makes
my
transition
to
GA
more
painful,
because
I
have
built
core
pieces
of
products
around
beta
features
and
I
am
both
the
guy
responsible
for
that
and
then
the
guy
who's
gonna.
F
Take
the
GA
make
the
changes
have
to
then
like
feel
the
pain
on
the
other
side
and
I
thought
about
what
I
could
do
to
to
help
encourage
us
to
focus
our
effort
on
getting
something
TGA
and
to
also
make
it
clear
to
consumers,
including
myself,
that
you
know
this.
Thing's
beta
and
beta
has
a
meaning,
and
it
means
that
you
should
be
real
careful
about
building
product
around
us
and
how
I
can
balance
those
two
things.
F
So
this
proposal
is
that
we
bound
the
number
of
releases
that
an
API
can
live
in
a
particular
beta
version
and-
and
you
know
the
conversation
on
this
thread
and
the
Google
Group
has
led
to
a
realization
that
we
should
scope
this
down
to
just
our
REST
API,
because
that's
very
easy
to
to
assess
and
look
at
without
argument.
You
came
out
as
a
beta
version
and
we
can
measure
you
and
to.
F
To
then
use
that
to
force
the
deprecation,
so
the
idea
would
be.
The
initial
proposal
is
for
two
releases
but
I
think
based
on
comments.
We're
gonna
go
with
three
and
I
will
be
updating.
It
kept
to
reflect
three
releases
where
you
are
in
beta
you're
on
by
default,
and
you
get
feedback
and
you
can
take
that
feedback
and
improve
your
current
beta
version
for
a
while.
But
if
you
aren't
gonna
make
GA,
you
introduce
a
new
beta,
so
you
have
introduced
a
new
beta.
D
D
F
D
Think
if
we're
gonna
do
something
like
this,
we
need
to
do
better.
We've
talked
for
quite
a
long
time.
I
mean
I.
Remember
this
pre
1.0
talking
about
adding
a
notes
field
to
the
return
type
on
most
API
calls
where
you
could
get
a
note
back.
That
says:
heyo
just
FYI.
This
is
a
deprecated
API
and
cube
Cuddalore,
and
other
tools
would
be
able
to
push
that
out.
So,
if
I
said
keep
it'll
create
something,
it
would
steer
me
a
message
that
says
this
is
a
deprecated
API
I.
Remember.
F
That
Brendan
Burns
poll
from
like
one
four
we've
talked
about
it
off
and
on
for
a
long
time
it
just.
It
was
never
important
enough
to
do.
Oh
I,
guess
I,
guess,
I,
look
at
it
and
say
using
the
api's.
It
makes
sense
to
at
least
I
check
for
new
ones.
I
have
four
deprecated
ones,
basically
the
diff,
but
if
other
people
don't,
maybe
we
can
think
of
a
different
way
to
communicate
it.
F
D
So
I
I
would
like,
if
that's
really
the
goal
and
actually
I
agree
with
the
goal
of
making
it
more
obvious
that
users
are
using
beta
I.
Think
that's
at
the
heart
of
a
lot
of
our
problems
like
ingress
I'll.
Take
the
blame
for
this.
One
has
been
beta
for
three
years
and
people
don't
really
realize
it,
except
some
do
so.
You
get
some
high
value,
customers
who
say
well,
I,
don't
want
to
use
betas
I
think
we
can
look
for
other
ways
to
put
the
beta
'no
sin
people's
face.
I
think.
B
D
F
B
My
belief
too
and
I
think
I
said
this
on
the
on
the
cab
discussion
that
did
and
I
believe
our
developers
in
general
are
acting
in
good
faith
and
that
the
reason
they're
not
talking
to
GA
is
because
there's
zero
cost,
leaving
them
beta
and
there's
other
priorities,
but
if
there's
actually
a
cost
to
leaving
it
in
beta,
then
why
not
just
make
a
GA
instead,
if
it's
good
enough
I
mean
if
there's
changes
needed
and
either
way,
it's
just
changing
the
incentives.
Slightly
I
wonder.
G
B
G
Yet
we
don't
actually
I'm
not
sure
who
specifically
signs
up
to
make
sure
that
that
happens
in
a
concrete
period
of
time,
so
people
volunteer
to
build
a
better
thing
and
they
promise,
but
they
hand
on
some
other
book
and
say
we're
gonna
make
this
GA,
but
we
have
no
way
of
really
enforcing
that.
So
we
can't
go
backwards.
We
can't
deprecated
something
that
we
said
we're
going
to
take
to
GA
and
we
don't
have
necessarily
the
staffing
to
make
it
go
to
GA
and
you
kind
of
get
stuck.
We.
D
D
G
Just
languishing
right,
maybe
my
understanding
is
out
of
date.
Beta
originally
meant.
This
thing
is
not
like
in
full
use
in
why
I
did
not
fuse
yet
that
we
know
that
it's
you
know
ready
for
production
use,
but
that
we
are.
We
have
every
intention
of
taking
it
to
GA
and
you
should
start
using
it
and
developing
it,
not
in
production
yet,
but
you
can
assume
that
you
will
be
able
to
build
production
systems
on
it
in
the
future.
Is
that
wrong,
or
is
that
accurate,
I.
D
A
Story
I
wanted
to
say
here
is
like:
if
there's
a
clock,
then
we
there
is
stuff
that
we
can
tell
our
management
chain
saying:
okay,
if
we
don't
do,
there's
a
clock
going
on
and
if
we
you
know
that
is
our
justification
for
putting
some
resources
and
getting
some
help
on
a
pretty
particular
feature
and
make
progressing
it
or
letting
it.
You
know,
go
down
the
chute
right
and
if
there
is
no
clock,
then
what
I
I
get
a
feedback
is
like.
Oh,
it's
it's
the
same
problem
we
had
with
the
flow
providers.
A
Oh
it's
entry
nobody's
going
to
take
it
out.
If
there's
a
date
or
a
deadline,
when
people
will
take
it
out,
then
you
tell
me:
I
will
go
figure
out
what
to
do
right.
So
it's
a
say
the
same
story.
So
if
there
is
a
clock,
then
there
is
justification
that
we
can
take
off
the
management
chain
to
say:
okay,
there's
things
that
we
need
to
do
here.
Otherwise
you
know
bad
things
are
going
to
happen
so
Tim.
D
You
go
next,
though,
I
think
it's
a
good
idea
to
force
people
to
understand
their
GA
plans
before
we
approve
a
bail,
I.
Think
only
anybody's
going
to
disagree
with
that
right.
I
also
think
we
can't
pretend
to
force
our
army
of
contributors
to
do
anything
right.
We
can.
We
can
tell
them
that
we're
gonna
rip
out
their
API,
but
we
better
mean
it
and
the
deprecation
rules
do
allow
it
even
though
I
think
Quinton,
your
characterization
is
the
sort
of
idealized
form.
That
is
the
intended
form.
D
You
come
before
this
group
or
some
other
group
and
plead
your
case
there
by
you
know
putting
some
barrier
to
just
leaving
it
in
perma
beta,
but
I
keep
coming
back
to
this
idea
that
users
are
not
sufficiently
incented
to
not
rely
on
betas
I
know
I
mean
the
ingress
is
a
great
example,
but
everybody
uses
it
and
it's
in
beta,
so
we
just
have
to
acknowledge
that
it
isn't
actually
in
beta.
It's
actually
in
GA
I
would
love
to
explore
other
ideas
to
make
things
more.
D
Obviously,
beta
I've
been
putting
a
lot
of
thought
into
that
over
the
last
year
or
two
I've
talked
with
Daniel
Smith
a
little
bit
about
this
I've
talked
with
Brian
a
little
bit
about
this,
but
I've
never
really
written
down
the
ideas.
If,
if
there's
people
who
like
David
I,
would
love
to
throw
some
ideas
at
you
and
see,
as
with
your
API
machinery
had
on
like
what
sticks,
I.
F
I
would
like
to
be
able
to
tell
users
that
you
know
something
something
is
at
risk.
I
have
an
interest
in
that
I
am
trying
to
find
ways
to
incentivize
developers,
I
think,
Tim's
and
and
John
both
face
similar
challenges
to
to
what
I
do
in
terms
of
overall
interest
in
and
not
the
developer,
parties
and
and
I
do
think
that
actually
we're
guy
is,
is
actually
fairly
easy
on
an
API
machinery
level
lean
is
killed
in
a
server,
it's
not
friendly,
but
it
is
possible.
I.
F
G
Just
actually
wanted
to
respond
to
Tim,
it's
pretty
stepped-up,
but
what
I
totally
agree
that
that
what
I
sketched
out
is
kind
of
idealistic
and
we
don't
actually
have
a
way
to
make
people
do
things.
So
one
one
alternative
would
be
to
modify
the
beta
kind
of
meaning
to
say
the
project
intends
to
take
this
thing
to
GA.
But
if
you
want
to
use
it
as
a
user
and
you
wanted
to
go
to
GA,
you
may
actually
need
to
fund
getting
it
to
GA.
G
You
would
have
the
support
of
the
project,
but
the
work
needs
to
be
done
and
the
project
does
not
actually
have
employees
per
se,
and
so
therefore,
that's
kind
of
the
message
to
users.
It'll
either
get
deprecated
in
a
year
and
go
away
or
you
can
help
get
that
to
GA
and
that
make
einde
of
address
thing
more
practically.
C
Just
I
don't
think
it's
crisply
stated
in
the
cap,
but
I
think
David
and
I
were
talking
about
this
briefly
before
the
call.
C
When
we're
describing
this
in
my
mind,
this
is
covering
api's
that
are
under
the
purview
of
KK
itself
and
I.
Don't
know
if
others
in
this
discussion
are
thinking
more
broadly
than
just
that
core
project
and
if
people
feel
differently,
if
they
think
that's
right,
here-ish,
this
fall
also
projects-
or
just
are
we
discussing
here
with
this
perspective
that
this
covers
keeps
you,
repo
content,
primarily
I,.
B
F
C
G
I
would
imagine
it
will
form
a
kind
of
a
precedent
that
other
projects
might
follow
as
well
and
I.
Think
there's
value
in
that
I'm,
not
sure
that
users
necessarily
see
us
as
clear
a
distinction
between
those
two
groups
as
we
do.
They
just
want
to
use
this
stuff
and
understand.
You
know
when
it's
gonna
go
away
or
whether
it's
gonna
go
away.
I.
B
Mean
I
think
it
would
certainly
need
to
apply
to
any
API.
That's
ever
gonna
be
subject
to
conformance,
so
anything,
that's
gonna
be
GA
and
built-in
and
not
optional,
and
so,
if
that
means
it's
gotta,
be
in
case
that
I/o
anyway,
then,
then,
that
makes
sense.
I
think
we
can't,
like
with
a
David
said,
can't
dictate
to
other
people
and
be
performed
outside
of
our
API
group.
D
D
We
don't
even
know
at
this
point
how
long
they're
gonna
be
able
to
use
this
thing
for,
and
so
we
give
people
all
these
examples
and
encourage
them
use
it
use
it
use
it
give
us
feedback
and
then
like
at
some
point
later
in
a
release.
Note
like
a
year
later,
maybe
there's
a
note
that
says:
oh,
we
we
promoted
to
GA
or
whatever,
and
so
now
this
thing
that
we
encouraged
you
to
use
for
a
year
with
an
unbounded
time
frame
is
now
deprecated
and
we've
built
this
habit
in
people
using
cube
api's.
D
D
D
We
should
come
up
with
as
many
as
we
can
I
like
the
idea
of
kind
of
active
like
in-your-face,
if
you're
using
a
baby,
API
you're
gonna
get
or
a
deprecated
API
you're
gonna
get
warnings
and
things
like
something
I
like
that
as
well,
but
if,
at
the
same
time
we're
asking
for
PETA,
we
can
make
it
clear
like
please
give
us
feedback.
Please
use
us
use
this
we'd
like
to
prefer
us
to
be
a
here's.
The
lifetime
of
this
video
API
I
think
that
would
help
yeah.
E
Don't
like
it
but
I
think
what's
kind
of
missing
here
is
its.
It
seems
like
we're
solutioning,
something
where
we
don't
have
the
full
state
space
of
it,
because
we
kind
of
made
it
up
as
we
went
along,
but
having
a
workflow
or
a
document
that
outlines
this
is
the
lifecycle
of
an
API
from
soup
to
nuts
like
this
is
what
it
means
to
go
to
alpha.
E
This
one
needs
to
go
to
beta,
and
here
are
the
policies
around
that
that
would
help
to
eliminate
the
community
about
like
what
it
means
to
actually
be
a
baby
yeah.
What
are
the
guarantees
and
what
are
the
lifecycle
events
that
occur
with
it,
because,
right
now
we
don't
really
have
that
and
we
have
a
bunch
of
api's
that
either
beta
Reena
GA
that
graduated
surreptitiously
along
the
way,
because
one
person
or
another
push
that
feature
through.
B
Yeah
I
think
that
a
couple
things
were
almost
out
of
time
here,
so
we
should
try
to
wrap
up,
but
five
minutes.
Six
minutes
left
I
think
that
the
the
discussion
of
alpha
beta
and
GA
and
the
lifecycle
of
feature
and
and
the
criteria
for
advancement
from
one
of
the
other
and
the
policies
around
deprecation.
We
have
a
lot
of
that
stuff,
but
it's
probably
time
to
revisit
them.
I've
raised
an
issue
a
while
back
on
in
the
community
repo
I
believe
around
that
so
I
I
think
I
wanted
to
continue
that
discussion
under
it.
B
With
that
same
group,
the
production
readiness
group
in
a
sense
because
I
see
that,
as
as
at
least
adjacent
I
think
the
other
point
here
that
keeps
coming
up
is
that
the
differentiation
between
how
we
notify
or
community
with
users
that
this
is
bethe
API
and
what
the
expectation
should
be
around
that
and
we
encourage
the
developers
to
move
it
forward.
In
my
opinion,
like
I
said
this,
cap
is
about
the
latter
with
a
little
bit
of
the
former
and
that
we
need
a
separate
cap
around
the
ideas
of
making
it
more
in-your-face.
B
For
the
user,
some
of
the
things
I
know
that
have
been
discussed
are
the
warnings,
but
also
requiring
say,
a
special
flag.
You
know
a
special
header
to
be
used
in
order
to
even
be
able
to
see
the
beta
api's
things
like
that
are
possibilities.
So
I
guess
from
my
point
of
view.
We
probably
should
keep
these
two
things
separate
and
we're
gonna
separate
cap
for
the
user
side
of
it
and
allow
this
one
and
to
go
forward
as
it
is.
B
K
I
want
to
kind
of
react
her
the
point.
The
Tim
talking
brought
up
around,
making
sure
that
we
have
waste
surfaces
to
users
like
one
thing
that
we
could
do
is
if
people
aren't
ready
to
move
a
feature
rather
than
accessing
it
at
least
bump
the
version
so
that
people
have
to
recompile
their
stuff
or
critically
make
sure
that
we
can
surface
something
like
the
coop
CTL
user,
because
so
many
of
like
our
common
denominators,
are
people
who
use
coop
CTL
locally.
F
Think
that's
what
John
was
suggesting.
We
could
do
separately.
I.
Think
Jordan
did
raise
some
good
ways
to
make
it
obvious,
as
people
try
to
learn
how
to
use
an
API,
because
we
have
a
fixed
policy,
and
you
know
when
you
ship
it.
Your
dock
for
your
new
API
can
actually
say
this
will
be
deprecated
no
later
than
give
the
release
number.
It
will
be
removed
no
later
than
give
the
release
number
so
that,
as
you
learn
to
use
it,
you
see
it
right
there,
because
most
of
our
API
is.
D
There
are
other
reasons:
I
want
the
the
side
channel
warning
mechanism
as
well.
Look
at
some
of
the
things
we
have
around,
like
validation
problems
where
early
API
is
allowed
data
in
that
mold
actually
work,
but
we
have
trouble
validating
it
differently
in
a
compatible
way,
but
we
could
like
warn
you,
hey,
you're,
creating
a
pod
that
it's
not
gonna
work
like
you
requested
a
mill
abite
of
memory.
It's
not
gonna
work.
We
could
tell
you
things
like
that
in
a
warning.