►
From YouTube: CNCF Serverless WG 2020-06-25
Description
CNCF Serverless WG 2020-06-25
C
C
A
E
F
A
C
A
G
H
A
A
A
I
D
A
A
A
Right
all
right:
it's
three
after
let's
go
and
get
started,
c17,
alright,
so
anything
from
the
community.
If
you
want
to
bring
up
I
think
we
all
timers
on
the
calls
and
nobody
knew
all
right
SDK
we
do
have
an
SDK
call
scheduled
after
this
one
I
believe
they're
just
a
couple
things
on
the
agenda.
If
we
have
enough
people
to
make
a
quorum,
so
please
stick
around
for
that.
If
you're
interested
I
don't
see
anybody
from
the
SDK
working
group,
I'm
just
don't
know,
I,
don't
see
anybody
so
no
update
there.
A
K
A
Okay,
any
objection
to
approving
perfect.
Thank
you
close
all
right,
so
the
next
three
are
technically
too
soon
for
us
to
approve
so
I
just
wanted
to
draw
your
guys
attention
to
it.
They
leave
the
first
two
or
maybe
they're,
all
three
of
them
yeah.
The
first
two
are
about
SDKs
and
particular
governance,
stock
and
common
procedures
and
stuff.
A
We
don't
initially
need
to
go
through
it
here
unless
somebody
has
and
they'd
specifically
like
to
bring
up
about
these
I
guess,
I
just
want
to
draw
people's
attention
to
it,
so
you
can
review
it
comment
on
it.
We
are
trying,
at
least
in
some
cases,
to
have
consistence
process
and
governance
across
the
SDKs.
Just
for
some
consistency,
so
we
will
be
looking
at
putting
documents
in
the
main
repo
under
community.
A
A
Okay,
in
that
case,
moving
on
this
one
very
minor
since
it
just
came
in
this
morning,
otherwise
I
would
have
just
really
approved
it.
Someone
wanted
to
add
into
the
demos
dock
a
little
demo.
They
had
I'm
assuming
no
one
has
any
objection
to
this.
Normally
I
would
have
just
to
prove
this,
but
since
it
just
came
in
I
thought,
I'd
put
it
up
there.
A
A
D
C
A
Okay,
at
some
point,
we
probably
need
to
decide
at
what
point.
Do
you
want
to
discuss
those
or
close
them
out
one
of
the
two?
Okay?
We
don't
have
to
decide
right
now,
just
going
forward?
Okay,
so
that
was
technically
yet
for
the
the
meet
of
the
agenda
last
night
as
I
was
thinking
about.
Obviously,
the
agenda
I
was
thinking
that
I
mentioned
the
last
week's
call
that
we
were
talk
there
I
mentioned.
A
We
should
probably
start
looking
at
doing
some
sort
of
testing
of
the
discovery
spec
itself,
whether
that's
a
full-blown
Interop
or
just
encourage
people
that
implemented
to
see
what
kind
of
feedback
they
get
or
something,
because
I
think
I
think
the
spec
is
in
a
fairly
good
State
for
people
to
start
playing
with
it
and
so
I
thought.
Okay,
maybe
we
could
do
some
little
interrupts
type
thing.
I
was
thinking
something
basic
right.
A
People
choose
to
put
up
a
service
provider,
maybe
use
github
as
a
sample,
trying
to
follow
the
the
adapter
that
we
set
up
for
github
with
all
the
cloud
event,
attributes
mappings
and
stuff,
and
then
people
can
write
clients
that
talk
to
the
various
services
that
are
out
there
or
servers
that
are
out
there.
I'm
sorry
discovery
endpoints
that
are
out
there
testing
the
various
things
that
we
define
the
spec
verifying
responses.
A
So,
for
example,
you
know
if
you,
if
you
do
you
get
the
same
list
of
services
from
this
query
versus
this
query,
that
kind
of
stuff
you
know,
there's
all
the
data
and
I
did
a
match.
There's
the
searching
scene
intuitive
that
kind
of
stuff
I
don't
know.
I
was
just
sort
of
initial
thought.
I
had
and
I
just
wanted
to
sort
of
open
the
floor
up
for
discussion,
see
what
people
thought
in
terms
of
other
ideas
for
moving
forward
and
doing
some
sort
of
base
level.
Testing
of
this
thing.
F
A
F
F
C
C
So
I
think
I
think
there's
there's
there's
activity
over
in
that
hand,
lands
correct,
Eric
had
been
I've,
been
making
comments,
I
think
I
think
there
are
some
aspirations
to
go.
Do
some
implementation
and
we
have
some
aspiration
to
do
some
implementations,
obviously
as
well
but
yeah
for
the
schema
registry.
There
should
be
a
you
know:
simple
app,
maybe
a
node
or
an
asp.net,
depending
which,
which
simply
implements
that
interface
good,
ideally
just
generated
from
the
open,
API
and
then
plums
that,
on
the
simplest
possible
document
store
in
the
back.
F
A
A
C
The
I
think
of
the
this
discovery,
the
discovery
the
subscription
API
and
the
schema
registry
are
somewhat
related
and
having
so
so,
actually
having
a
project
that
that
tries
to
build
on
top
of
whatever
a
simple
database
is
tries
to
prototype
them
out.
All
at
once
would
not
be
terrible
and
it
doesn't
need
to
I,
don't
think
it
needs
to
be
needs
to
be.
You
know,
running
in
kubernetes
and,
being
you
know,
four
hundred
lines
of
yeah
mol
deployment.
Stuff.
Sorry,
if
I'm
insulting
anybody,
they
should
be
using
a
native
Khan
yeah.
D
C
C
C
J
C
And
if
you
want
to
turn
that
into
the
thing
that
you're
gonna
sell
to
the
world,
fine,
it's
just
I
think
I
think
that
what
we
need
is
the
proof
point
that
the
stuff
that
we're
doing
here
in
all
theory
is
actually
hold
together
in
practice.
Yeah
I
do
agree.
So
more
so
more
than
one
implementation
would
be
great,
but
if
we
can
start
with
one
and
get
an
implementer
implementers
of
Phinney,
that
will
certainly
help
yeah.
A
Well,
that
was
my
intent
here
was
try
to
get
some
more
multiple
pages
of
this
thing
going
and
I
I
agree.
The
Clements
that'd
be
great.
If
we
actually
did
all
three
specs
I
was
just
trying
to
do
one
step
at
a
time
and
I
thought
there.
This
guy
respect
has
had
more
reviews
than
the
other
ones.
That's
why
I
was
thinking
that
might
be
good
place
started.
A
B
B
A
Think
you're
all
weekend
right
well
come
on
Scott
I,
don't
know.
Do
you
want
to
I
mean
we
could
push
for
I,
don't
know
a
couple
weeks.
Maybe
I
I
can't
imagine
that
the
the
discovery
spec
is
actually
that
difficult,
let's
be
honest,
I
think
the
hardest
P
DS
is.
That
piece
is
actually
just
figuring
out.
What
all
the
metadata
looks
like
to
be
honest,
yeah
I'm
interested
in
my
favorite
language,
mm-hmm.
A
A
F
A
A
A
That's
good
question:
I
think
that
goes
back
to
what
Clemens
was
saying
earlier,
because
I
think
what
Cummins
was
suggesting
use.
My
own
words
was:
maybe
we
should
have
a
reference
implementation
of
this
available
yeah
edit.
That
is
something
we
have
not
talked
about.
I
know
the
SDKs
kind
of
come
close
to
that,
but
we
haven't
talked
about
that
for
these
specs,
yet
I
think
it's
definitely
about
adoption.
If
the
group
wants
to
do
that,
I,
don't
think,
there's
anything
that
stops
us
from
doing
it.
Okay,.
A
A
A
A
A
A
B
A
A
A
Was
funny
is
I
happen
to
be
looking
at
just
yesterday,
because
the
the
workflow
spec
is,
you
know,
trying
to
go
forward
with
and
as
a
nest
as
a
sandbox
project,
and
they
got
held
up
because
they
didn't
have
a
code
of
contact,
even
though
technically
it
doesn't
require
them
to
have
a
code
of
conduct,
so
they
quickly
Act
one
and
they
weren't
sure
which
one
to
add
so
I
pointed
into
that
one.
So
it
seemed
result
of
me.
The
only
thing
was
a.
J
A
Not,
but
what's
funny
about
this
is
the
CN
CF
code
of
conduct
in
the
little
section
that
says
you
know
if
you're
concerned
about
something
happened,
you
know
notify
us
well
when
in
the
notify
us
section
it
points
to
kubernetes
not
to
the
CN
CF,
but
I
thought
was
kind
of
amusing,
so
I
did
ask
about
that
and
they
said
yeah.
That's
a
work
in
progress
to
fix
that.
So
that's
the
only
things
a
little
bit
awkward
about
their
sin.
Their
code
of
conduct
I
have.
A
A
E
J
A
A
J
A
A
Okay,
so
these
two
actually
are
two
piers
I
put
here,
not
because
I
thought
there
was
anything
we
had
to
discuss,
but
just
I
wanted
to
bring
them
up
to
see.
If
there's
anything
you
folks
wanted
to
talk
about,
are
there
any
kayak?
To
be
honest,
I
have
not
followed
any
discussions
going
on
on
those
two,
so
I
don't
know
if
there's
anything
controversial
or
worthy
of
discussion.
If
not,
we
can
skip
it,
but
I
just
want
to
give
you
folks
the
opportunity
to
bring
something
up.
L
One
thing
about
wine
is
that,
after
finished
to
Reddit,
I
I
recognize
that
I
implicitly
assume
that
who
owns
the
rights
the
bright
right
for
our
repo
as
also
the
right
to
publish
the
releases,
and
that's
not
true,
because
we
don't
ever
to
mention
in
I,
think
it
most
of
us
the
case
we
don't
an
automation
to
perform
releases.
So
I
think
that's
something
that
was
already
brought
up
in
past
and
I.
Don't
know
if
you
could.
C
We're
John
is
gonna
set
up
the,
so
there
are
some
automation
on
these
c-sharp
SDK
already,
but
we
are
what
we're
missing
to
be
complete
in
the.net
world
is
strong
names,
strong
liam
signatures,
so
John's
still
taking
the
action
item
to
go
and
do
that
and
I
think.
Once
we
have
strong
names,
then
we
can
basically
just
go
and
and
and
automate
builts
to
push
them
straight
to
knew
that
so,
firstly,
chakra
will
do
that.
Okay,.
L
A
A
A
L
A
L
A
M
Did
raise
a
question
in
there
which
Francesco
suggested
maybe
just
become
an
issue,
and
that's
that
to
do
should
we
consider
changing
the
default
branch
name-
that's
probably
not
worth
talking
about
in
this
PR,
but
something
to
think
about.
Maybe
for
the
future.
You
know
not
the
master,
but
something
else.
Yeah.
A
Yeah
we
can
talk
about
that.
Some
play.
Okay,
there's
no
I
was
asking
whether
they're
ready
to
go
is
because,
if
we
want
to
do
you
know
that
one
week
time
period,
then
we
could
say
okay,
today's
the
day
where
no
significant
changes
are
planned,
maybe
type
of
type
stuff,
but
between
now
and
next
Thursday
is
that
one
week
period
and
we
can
just
nag
the
appropriate
SDK
maintainer
is
to
to
vote
on
on
the
2p
ours.
J
A
L
A
J
N
Do
you
really
need
to
vote
on
it
or
use
it
sort
of
a
different
inverse
approach
where
okay
people
comment
it
at
some
of
time?
There
is
no
conflicts,
there
is
no
contradictions
and
that
effectively
makes
it
because
I
don't
assume
that
each
document
is
once
it's
merged.
It's
not
changeable
I
mean
things,
will
change,
things
will
evolve
and
we'll
enjoy
it.
Those
changes
will
be
addressed
separately.
So,
for
example,
looking
at
this
document
sure
let's
say
merge
it
right
now
doesn't
mean
that
it's
not
going
to
change.
N
A
N
A
Yeah,
okay,
so
sinky
I'll
get
to
you
in
a
sec.
The
reason
I
think
this
is
different
than
say.
A
PR
in
one
of
the
SDKs
itself
is
because,
first
of
all,
this
is
going
to
the
cloud
events,
repo
itself
and
technically.
The
process
we
try
to
follow
is,
unless
it's
so
blindly
obvious
that
as
a
co-chair,
I
can
do
it
myself,
like
syntax
type,
changes
right.
Anything
of
any
significance
gets
approved
by
the
group
alright,
and
that
usually
means
Thursday
phone
call.
A
People
get
to
review
at
least
two
days
in
advance
and
we
basically
take
a
vote
like
we
do
on
everything
else.
So
technically,
this
should
follow
that
exact
same
process.
You
know
a
reason
we're
doing
slightly
different
here
is
because
this
is
really
only
about
the
SDKs
right
and
so
I
feel
like.
We
still
should
have
some
sort
of
vote
around
this
thing.
It's
just
the
scope
of
who
gets
to
vote
I'm.
N
A
I
see
what
to
say:
okay,
yeah,
okay,
okay,
I
apologized
understood
the
reason
this
is
the
reason
this
is
different
is
because
people
understand
that
when
they
on
the
Thursday
phone
calls
were
going
to
do
votes
right
and
if
they
choose
not
to
vote
that,
you
ought
to
join
the
call
they
know
they
can
speak
up
on
the
on
the
pr2.
Raise
an
objection.
These
I
don't
think
we
gave
fair
enough
warning.
A
J
J
A
Yeah,
it's
interesting
what
a
pill
thing
because
I
know
Francisco
on
last
week's
call
you
you
mentioned
the
possibility
of
having
to
introduce
some
kind
of
TOC
kind
of
thing,
I
think
mark.
What's
your
suggestion?
There
is
something
a
little
bit
similar
right
at
the
authority
above
the
SDK.
It's
each
individual's
decaying,
so
slinky
your
answer,
yeah.
L
So
two
things
first
note
that,
at
the
end
of
the
document
is
clearly
states
that
to
change
these
rules,
we
need
a
vote
following
the
voting
process
that
Ickes
that
I
stayed
here,
so
I
mean
if
we,
if
we
pass
these
rules,
then
let's
make
sure
we
like
it
and
then
I
see
what
Mark
you're
talking
about
and
I
wished
to
address
those
issues
too.
But
I
did
this
draft
just
to
talk
about
security,
patches
and
quality
of
service,
which
are
which
were
long-standing
issues
in
this
community.
L
I
really
wish
to
talk
about
these
order
things,
but
I
think
that
we
may
need
other
peers,
for
that.
Yeah
is
that,
okay,
for
you,
I
mean
in
general
through
community.
If
you
want
to
take
action
items
separately
to
to
fill
this
document
with
the
order
bits,
we
need
like
the
one
that
you
said
about.
Actually,
when
we
have
a
problem
should
we
escalate
or
the
other
one
that
we
said
about
there.
What
happens
if
one
is
the
came
on
Tina's
overall,
the
order
so.
J
L
J
J
The
other
thing
with
with
this
document
that
I
was
going
to
comment
on,
but
since
we're
on
the
call
I'll
comment
here,
it
talks
a
lot
about
security
patches
in
Doug.
Do
we
have
a
secure
way
of
being
being
able
to
handle
security
patches
I'm?
No
one,
but
we
have
a
do.
We
have
a
mailing
list
that
someone
could
use
if
they
find
a
security
issue
and
not
have
to
go
through
the
your
issue.
L
A
H
A
A
M
N
Go
said
that
this
be
our
primarily
was
obviously
is
going
to
expand,
but
primarily
it's
for
security
patches.
Maybe
it
would
help
because,
for
example,
I'm
looking
I'm
reading
it
for
the
first
time
and
I
could
provide
a
few
comments
or
worse
or
various
questions,
and
that
could
prolong
the
process.
Maybe
we
should
slim
down
these
PRS
to
say:
listen.
This
is
a
security
cash
part
of
it
and
then
eventually
we
agree
on
that.
N
We
agree
on
something
else
and
so
on
and
then
at
some
point
of
time
we
agree
on
these
chunks
and
then
we
can
assemble.
The
entire
is
decay
governance
document,
because
we
have
things
that
are
related
to
security
patches
here,
I'm
assuming
and
then
things
that
are
not
related,
and
that's
that
I
don't
know.
A
So
so
the
way
I
kind
of
view
that
is
I,
don't
I,
don't
person
have
a
problem
with
splitting
this
out
into
several
PRS,
but
I'd
rather
wait
until
someone
does
review
and
says
you
know
what
this
particular
issue
is
such
a
scary
beast
that
let's
pull
this
out
to
have
a
separate
discussion,
because
I
can't
even
live
with
this
as
a
starting
point.
Right
and
I
can't
wait
for
a
follow-on
PR
to
fix
it.
A
A
Okay,
there
we
go
all
right,
so
I
mentioned
in
one
of
the
I
think
it
was
in
the
Java
SDK
and
one
of
the
PRS
there
that
we
talked
about
this
sunset
on
this
call.
Francesco
I
don't
have
to
issue
in
front
of
me,
but
you
opened
up
an
issue
where
I'm
sorry,
you
opened
up
a
PR
where
you
created
a
milestone
for
the
Java
SDK,
and
then
you
merge
that
relatively
quickly
and
I
think
what
happened
there,
because
some
people
raised
some
concerns
about
that.
A
My
interpretation
was
that
a
milestone
is
a
relatively
light
thing.
It's
it's
it's
a
little
more
real
than
just
so
just
telling
people
to
go
grab.
You
know
the
head
of
the
branch,
but
it's
not
like
a
release
candidate
or
a
says
hey.
This
is
what
we
think
is
the
final
thing.
It's
just
sort
of
a
well
I
kept
using
the
term
snapshot
in
my
head,
but
I
wanted
to
bring
up
that
discussion
because
I
know
there
was
some
concerns
there.
So
let
me
stand
me
get
off
and
let
other
you'll
talk.
N
This
is
Oleg
I'm
good
I
was
coming
from
the
world
where
you
correct.
The
word
snapshot
has
a
very
distinct
meaning.
The
word
milestone
has
a
very
distinct
meaning,
and
the
world
of
this
kind
has
a
very
distinct
meaning.
So
it's
not
just
oh
grab
it
from
the
head.
No,
we
have
snapshots
for
that.
For
example,
a
lot
of
projects
publish
snapshots
daily
nightly
after
each
commit
and
so
on
and
so
forth.
There's
different
rules
to
do
that,
at
least
in
a
job
all
right,
so
milestone
means
you
have
something
again.
N
It
means
if
you
have
something
that
can
feature
that
you
want
a
community
to
start
demonstrating
or
your
announces.
You
explain
what
it
is.
You
say
this
is.
Why
are
we
doing
this
milestone?
It
could
change,
but
there
it
is
out
there.
People
can
start
using
it.
It's
actually
a
step
above
the
snapshot,
because
we
have
something
important
to
say.
So
it's
not.
We
can't
just
release
milestone
just
because
enough
time
went
by
and
then
obviously,
as
you
said,
release
candidates
so
on
day.
N
So
and
with
that,
there
are
certain
patterns
which
people
are
familiar
with,
especially
within
a
particular
community
that
they're
going
to
be
looking
for
and
eventually
when
we
and
so
Sergey
his
comment
was
kind
of
related.
To
that
say,
listen
there's,
maybe
not
not
an
issue
releasing
milestone
because
we
Don
some
significant
work,
but
maybe
you
should
change
it
to
m1
something.
N
N
A
So
it
seems
to
me
that
that
there
was
just
a
for
lack
of
a
better
phrase,
just
sort
of
miscommunication
in
terms
of
the
process
or
the
terminology
and
stuff,
and
so
the
first
thing
I
ran,
through
my
mind,
was
okay.
The
best
way
to
solve
this
going
forward
is
to
just
document
what
the
document
the
process
is
right.
A
I
commend
what
we
think
it's
okay
document,
what
a
milestone
is
document
where
these
candidates
are,
and
as
long
as
every
understands
and
agrees
on
what
they
are,
how
they
get
created
when
they
could
have
created
what
the
process
by
which
they
get
created.
At
least
we
don't
have
that
miss
that
miscommunication,
so
I
think
this
is
more
of
a
document.
Documentation
of
our
process
issue
more
than
anything
else,
is
that
fair,
yeah,
okay,
so
I
have
a
I
sort
of
a
high
order.
Question
here.
A
N
M
A
A
Do
you
see
that
being
more
as
a
release,
kind
of
a
thing,
the
reason
I'm
asking
is
because
I'm
wondering
whether
it
makes
sense
to
have
commonality
just
in
terms
of
terminology
and
and
not
necessarily
when
things
happen.
So,
for
example,
let's
say
we
defined
what
a
milestone
is
and
the
rules
for
who
can
create
a
milestone
when
we
define
what
a
release
candidate
is
and
how
that
process
happens,
and
then
we
decide
what
it
releases
and
who
gets
to
vote
on
whether
release
passes
or
not.
A
But
we
don't
necessarily
say
that
every
single
SDK
has
to
have
all
three
levels
right.
Some
may
choose
to
have
all
three.
Some
may
only
have
releases,
but
at
least
then
there's
commonality
in
terms
of
how
you
approve
each
one
of
those
or
what
they
actually
mean.
Does
that
make
any
sense
yeah?
It
does
make
sense
and
I
agree
with
that.
I
guess
just.
N
To
clarify
the
lens,
my
point:
it's
not
about
go
head,
snap
shadow
has
not
shells
but
go
doesn't
or
we
should
not
have
it
or
whatever
it's
more
about.
For
example,
yes,
snapshot
has
a
meaning;
we
can
define
what
there
is,
and
it
doesn't
certainly
have
to
follow
a
particular
thing,
but
once
we
agree
what
the
snapshot
is,
how
do
we
identify
the
snapshot
artifact
itself
within
Java
world
versus
within
other
languages?
So,
and
that's
that's
where
I
come
in,
because,
for
example,
with
the
Java
world,
it's
not
just
what
we
want
it's.
N
There
are
tools.
There
are
products
out
there
who
will
do
parsing?
Who
would
you
just
give
me
the
latest
one
and
they
will
know
how
to
pick
the
latest
one.
So
we
need
to
be
very
careful
whether
we
do
it
lowercase,
uppercase,
M,
1
or
milestone,
and
so
on.
So
there
is
much
more
to
discuss
there.
We
have
been
doing
you
know.
I
was
in
spring
community
for
past
20-some
years.
N
We
actually
had
a
meeting
right
now
a
couple
weeks
ago
and
had
to
introduce
certain
minor
changes
to
our
naming
schema
because
of
certain
things.
I,
don't
want
to
hijack
the
meeting
for
that
as
well,
neither
but
I'm
just
saying
that
we
can't
just
throw
some
names
out
there
and
and
and
say
that's
that's
how
we
do
there's
much
more
to
these
names.
N
A
So
so,
you're,
okay,
it
sounds
like
with
defining
the
common
terms
and
even
possibly
the
common
sort
of
process
by
which
those
reliefs
are
and
those
artifacts
get
approved
and
and
stuff
like
that,
it's
just
you
want
to
test
decay
to
have
the
freedom
to
do
its
own.
Naming
for
lack
of
a
better
phrase.
Kind
of
stuff
I
mean.
N
Yeah
because
there's
just
moving
parts
that
outside
of
our
control
that
we
may
pay
the
price.
If,
if
we
don't
follow
certain
because
if,
if
everybody
expect
milestone,
ought
to
be
an
m1
and
you
don't,
then
your
thank
you
effectively.
Remove
yourself
from
the
features
and
capabilities
of
that
particular
system
or
that
particular
process
and
if
you're
trying
to
build
community
I
mean.
Why
would
you
want
to
do
that
in
the
first
place
right.
A
I
So
as
after
the
command,
the
request
I
just
wanted
to
point
out
that
my
main
concern
is
not.
That
was
the
selection.
I
was
working,
for
example,
the
milestone
or
risk
in
it
or
whatever,
but
rather,
and
we're
seeing
it
not
the
first
time.
But
lack
of
any
process
in
the
Java
is
the
key
of
reviewing
and
accepting
big
changes
like
it
was
just
dropped
as
a
pull
request
merged
instantly
without
any
approval
of
any
other
maintainer.
I
And
if
I
remember
correctly,
we
do
have
more
than
one
maintainer
in
the
cloud
events
Java
SDK,
which
kind
of
suggests
that
his
some
formal
process
of
reviewing
should
be
done,
and
my
comment
was
just
an
attempt
to
kick-start
discussion,
but
and
it's
okay
if
it
would
be
ignored,
but
I
was
surprised
that,
as
I
maintain
years
did
not
approve
the
poo
request
before
it
got
merged
and
it
went
to
the
modern
central
by
the
way.
After
second
attempt
not
on
the
first
one,
so
I
believe
code
review
could
catch
that
issues
fall
and
yeah.
A
So
does
this
do
these
two
bullets
summarize?
We
want
to
come
and
process
common
artifacts
right
milestones
versus
release,
candidates
versus
releases,
but
each
jess
DK
is
gonna.
Have
the
freedom
to
figure
out?
You
know
how
they
package
those
up.
What
the
names
are,
whether
it
actually
use
all
three
or
have
a
name.
You
have.
Those
kind
of
things
is
that
sound,
fair
and
accurate?
It's
what
we
talked
about.
I
A
N
Just
for
example,
there's
also
we
don't
use
it,
but
there's
some
people
use
it
with
work-in-progress
right
right
for
something
that
is
better
than
a
snapshot.
That's
just
you
know
one
of
those
things
but
I
think
the
surveys
point.
Is
he
raised
a
greater
point?
The
the
schema
question
whether
its
milestone
or
m1
is
just
a
particular
incident,
but
surcease
point
I,
think
and
correct
me.
If
I'm
wrong,
then
there
was
really
no
discussion,
no
debate,
nothing.
It
was
just
bamm-bamm
done
right.
A
A
L
A
A
When
it
happens,
who
has
the
authority
to
kick
it
off?
That
kind
of
stuff,
I
I
think
the
bigger
concern
here?
Isn't
it
it's
just
people
to
understand
how
the
mechanics
of
the
group
is
going
to
be
right?
How,
when
things
happen
by
by
who,
when
and
stuff
like
that,
so
that
somebody
who
does
understand
wasn't
part
of
the
group
they
can
read
this
document
say:
oh
okay,
I
understand
why
this
milestone
was
automatically
created
right.
It's
because
the
process
says
it
gets
created
every
day.
If
you
know
every
Friday
at
3:00
p.m.
right
whatever.
A
N
A
A
N
And
you
know
it's
gonna
be
pretty
much
what
you
already
have
there.
It's
just
going
to
be
in
a
more
formal
document
like
I,
said:
I'm
the
languages,
so
other
people
can
contribute
in
terms
of
what
other
typical
artifacts
are
being
released
or
expected
by
the
community
within
that
language,
environment.
M
Yeah
I
mean
you
kind
of
addressed
it.
I
was
just
wondering
where
this
proposal
was
gonna
show
up
I'm
assuming
it
would
show
up
on
this
back
repository,
but
then
that
sort
of
makes
me
start
to
wonder
if
there
shouldn't
be
a
governance
repository,
because
there's
a
lot
of
governance
stuff
going
into
this
Beck
repo
do.
G
M
M
You
know
actually
some
of
this
stuff
that
we're
talking
about
right
now
in
terms
of
you
know,
artifacts
and
processes
that
that's
why
I'm
keenly
interested,
because
I
don't
want
to
just
publish
it.
You
know
right
now:
it's
major
change
and,
and
so
I'm
a
little
concerned
about
doing
that.
But
I
also
know
that
you
know
getting
it
out
sooner
rather
than
later
would
be
would
be
great
because
it
is
completely
different
than
the
existing
API.