►
From YouTube: CNCF Serverless WG Meeting - 2018-09-20
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
A
A
B
Please
get
to
them
when
you
get
a
check,
yes
Anette,
but
this
face-to-face.
C
C
A
B
E
E
Interested
in
they
call
it
what
we
did
during
that
college.
We
re
clarified
priorities
for
the
clan
events,
SDK
version
0.1,
here's
what
we're
looking
you're
not
doing
for
that
I
want
support.
At
least
three
languages.
I
want
the
SDK
to
allow
users
to
easily
instantiate
cloud
events
in
code
per
the
cloud
event
specification,
and
we
also
want
to
define
you
know
basic
api's,
getters
and
setters
for
these
cloud
events.
E
Instances
and
the
goal
is
just
to
give
developers
a
great
experience
for
just
getting
and
setting
information
on
their
on
their
cloud
events,
event,
instance,
and
also
just
maybe
perhaps
getting
into
some
mocking
of
cloud
events
for
testing.
That's.
We
haven't
discussed
that
too
much.
Yet
next
up
was
determine
how
to
handle
versioning
across
the
SDKs.
The
cloud
event
specification
the
transport
specifications
as
well,
as
extension,
it's.
E
This
is
something
that
I'm
gonna
dig
into
in
just
a
second
year,
because
there
are
a
lot
of
moving
parts
and
the
SDK
is
kind
of
one
of
those
places
where
all
those
moving
parts
come
together
and
all
these
moving
parts
have
different
versions,
and
we
need
some
advice
from
the
group.
As
to
how
about
handling
all
this
stuff,
but
before
I
jump
into
that,
the
last
big
priority
for
version
0.1
is
support
for
extensions.
So
we
feel
that
extensions
should
not
only
be
custom
properties
in
the
event
and
look
as
they've.
E
You
know
been
discussed
within
the
context
of
this.
This
call,
but
extensions
are
also
middleware
and
hook
functionality
that
can
be
optionally
loaded
into
the
SDK
and
know
and
that
middleware
hook
functionality
can
is
the
function
I
that
will
add,
met
custom
extension
metadata
to
the
event
envelope.
E
So,
for
example,
if
there's
a
distributed
tracing
extension,
there
could
be
this
optional
library
which
you
could
load
into
the
SDK
in
that
library
will
help
you
set
the
correct,
distribute
tracing
information
on
the
cloud
in
the
cloud
of
its
metadata
as
well
as
give
you
perhaps
some
additional
handlers
or
methods
to
you
know,
pull
out
interesting
information
from
the
cloud
events
from
the
cloud
events
as
they're
instantiated
in
code.
So
this
is
how
we're
thinking
about
extensions.
We
think
this
is
important,
because
this
is
well
I.
E
Think
cloud
events
is
going
to
live
or
die
based
on
whether
or
not
it
gets
community
support
and
adoption,
and
we
think
that
extensions
are
going
to
be
the
place
where
the
community
really
plugs
in.
So
that's
the
open
source
community
has
the
ability
to
make
their
own
basically
libraries
and
metadata
to
extend
cloud
events.
We
think
vendors
need
this
as
well,
and
we
also
think
that
organizations
and
teams
who
adopt
cloud
events
are
going
to
need
the
opportunity
to
make
their
own
extensions.
E
E
F
This
sorry
can
I
ask
a
question
yep
about
the
extensions
you
right
there.
Can
you
scroll
down
just
a
bit
adding
support
for
different
vendor
solutions?
Do
you
intend
you
write
middleware,
but
you
also
write
who
do
you
intent
the
cloud
events
SDK
to
be
the
front
end
or
to
be
integrated
into
vendor
solutions.
E
That's
a
good
question
and
don't
have
an
answer
for
that.
Yet
I
think
that
we'll
have
to
see
what
the
market
wants
to
do
but,
for
you
know,
there's
kind
of
two
ways
this
could
happen.
You
know
the
vendors
could
offer
cloud
events,
extensions
that
fits
right
into
the
cloud
events
SDK
and
perhaps
that
might
be
the
best
approach.
If
the
cloud
events,
effort
in
general
gets
a
lot
of
traction-
and
you
know,
end-users
seem
like
they
want
to
prefer
using
the
open
kind
of
standard
option
rather
than
a
vendor
specific
option.
E
So
that
could
be
a
good
solution
for
that.
However,
at
the
same
time,
we
want
to
make
sure
that
the
cloud
events
SDK
is
something
that
you
can
require
into.
Maybe
your
vendor
specifics
SDK
as
well,
so
that
you
can
you
just
leverage
the
cloud
event
SDK
behind
the
scenes,
a
lot
of
different
use
cases
we're
covering
a
lot
of
different
surface
area
and
I'm,
not
sure
how
this
is
going
to
shake
out
yet,
but
those
are
yeah.
F
E
Will
well
we'll
we'll
learn
this.
You
know,
I
I
think
the
SDK
is
going
to
be
perhaps
the
first
instance
where
cloud
events
really
becomes
accessible
to
end-users
and
we'll
learn
a
lot
as
to
how
people
want
to
want
to
use
the
cloud
Abed
specification
overall,
as
well
as
what
they,
what
they
think
the
role
of
the
SDK
is
so
but
anyway,
good
good
things
to
consider.
Thanks
for
raising
those
yeah.
H
D
E
Well,
these
languages
are
going
to
be
determined
based
on
the
people
who
want
to
volunteer
their
time
and
energy
to
help
create
these
great
SDKs.
So,
while
we'd
like
to
say
hey
these
languages
would
be
great,
I
think
it's
really
gonna
come
to
like
who's
actually
gonna
contribute
the
time
and
what
languages
they
want
to
focus
on.
I
will
say
that
we
have
volunteers
already
focused
in
specific
languages,
and
that
is
Red.
Hat
has
been
focused
on
a
Java
implementation.
Vmware
has
been
focused
on
a
go
implementation.
E
E
So
these
are
our
priorities.
We
have
a
version,
0.2
kind
of
expect
out
here
and
the
way
we've
been
discussing
it
in
the
context
of
these
calls
is
you
know,
we're
laying
out.
You
know
we
laid
out
our
kind
of
the
various
scopes
of
work
we'd
like
the
SDK
to
accomplish
over
time,
and
we
prioritize
to
all
these.
E
Within
this
document
we
took
those
priorities,
so
we
broke
them
down
into
actual
cloud
events,
SDK
versions,
and
but
it's
really
going
to
be
up
to
the
people
working
on
this
as
to
whether
they
want
to
just
use
some
of
this
or
whether
they
want
to
go
ahead
and
go
a
bit
further.
We're
trying
to
use
these
SDK
calls
as
well
as
this
document,
to
help
harmonize
our
efforts
and
I
sure
that
we're
going
about
implementation
in
a
uniform
way
as
possible,
even
across
the
various
languages
at
run
times.
E
Doing
that
and
also
in
addition,
there
are
some
basic
design
goals
that
we
discussed
on
the
last
call
around,
perhaps
how
to
handle
some
of
the
versioning
concerns,
so
we're
going
to
keep
updating
this
as
we
move
along,
but
I
think
the
next
most
important
thing
for
us
is
really
just
to
discuss
some
of
the
versioning
issues
that
were
coming
up
against
within
the
SDK
and
get
some
of
the
some
feedback
from
the
larger
working
group.
So,
first
off
the
SDK
again
is
a
place
where
a
lot
of
moving
parts
come
together.
E
First
off
you
know
we're
gonna
be
dealing
with
multiple
versions
of
the
cloud
event
specification.
It
seems
highly
likely
that
people
who
are
building
applications
based
on
cloud
events
are
going
to
have
to
handle
cloud
cloud
events
that
have
conformed
in
different
versions
of
the
specification.
So
if
someone
has
an
application,
you
know
that
they
build
on
cloud
events
and
it's
been
running
for
a
long
period
of
time.
It
seems
like
they
may
have
old
versions
of
cloud
events
in
that
system,
as
well
as
possibly
new
versions
of
cloud
events
in
that
system.
E
So
we
want
to
make
sure
that
the
SDK
can
has
a
good
answer
to
handling
various
versions
of
the
cloud
event
specification.
So
that's
one
concern
we
have
and
something
we
have
to
think
through
then
there's
the
additional
consideration
for
the
transport
specifications-
and
that
is
you
know
we
have
these
separate
specs
for
each
transport
in
the
cut
in
the
SDK
calls.
E
We've
largely
just
been
focused
on
HTTP
for
now,
but
there's
a
whole
other
set
of
challenges
here
as
to
making
sure
that
the
cloud
events
SDK
can,
let's
see
the
scenarios
to
consider,
can
generate
and
deliver
events
directly
to
an
HTTP
endpoint
where
we
don't
know
what
version
of
the
protocol
the
endpoint
supports.
Okay,
where
we
do
know
what
version
of
the
protocol
the
endpoint
supports,
as
well
as
where
we
don't
know
what
first
the
protocol
the
endpoint
supports.
E
We
want,
to
you
know,
be
able
to
publish
in
format
events
that
can
be
sent
out
to
endpoints,
perhaps
running
different
versions
of
the
protocol.
We
also
want
to
be
able
to
upgrade
an
event
perhaps
to
match
a
version
of
the
protocol,
maybe
downgraded
an
event
to
match
a
version
of
the
transport
specification.
E
Just
a
few
different
scenarios
we
think
could
come
up
when
actually
architecting
a
system
around
cloud
events
and
the
specs
that
we've
defined
so
far,
so
how
we
actually
handle
various
versions
of
a
cloud
event
specification
and
various
version
of
the
transport
specifications
within
the
context
of
the
SDK
is
you
know
something
we'd
like
to
get
feedback
from
all
of
you
on
and
then
before?
We
actually
hear
from
from
everyone.
I
just
want
to
cover
the
last
few
moving
parts
because
they
might
be
related,
and
that
is
extensions
versions
as
well.
E
So
extensions
are
going
to
need
to
understand.
You
know
what
version
the
specification
is
involved.
Perhaps
what
version
of
the
transport
specification
we're
looking
at
and
they're
probably
going
to
need
to
be
version
themself,
so
the
distributed
tracing
extension,
for
example,
may
have
its
its
own
versioning
mechanism
and
then
of
course.
Lastly,
the
cloud
events
sdk
itself
needs
needs
version.
So
anyway,
a
few
questions
as
to
how
to
deal
with
these.
These
few
priority
things,
and
that
is
the
first
question-
is:
will
the
transport
specifications
continue
to
be
version
separately
from
the
core
cloud
event?
E
C
What
I
would
suggest
is
to
version
them
all
together
and
that's
what
because
that's
what
everybody
looks
at
looks
at
I
mean
if
we
want
to
keep
track
of
the
individual
document
traces
we
can
build,
make
documents
versions
basically
counters,
to
kind
of
keep
track
of.
You
know
if
you
are
currently
within
0.8
and
you're
kind
of
advancing
that
draft
that
you
still
have
a
way
to
keep
track
so
you're
in
v8
and
you're
now
in
working
draft
13,
then
you
know
where
you
are,
but
overall
this
should
all
be
a
version
together.
C
E
E
Are
we
going
to
have
to
also
include
perhaps
a
header
that
indicates
the
cloud
events,
HTT
transport
specification
version,
because
we
want
that
SDK
to
be
able
to
just
look
at
those
headers
and
kind
of
assemble
a
cloud
event
automatically
for
the
user,
so
the
user
doesn't
really
have
to
craft
the
cloud
event
from
from
that
HTTP
request.
So
if
this,
if
these
things
are
version
together,
then
I
guess
we
could
just
look
at
the
cloud
events
version
metadata
and
understand
how
to
assemble
the
cloud
event.
I
Make
sense
for
inbound
Austin,
but
it
doesn't
make
sense
necessarily
for
delivering
in
events
to
the
endpoint
right,
yes
dear,
if
you're
the,
if
you're
on
the
front
end
of
that
you're
you're
creating
the
event.
To
begin
with,
you
need
to
be
able
to
know
what
version
they
give
an
endpoint
actually
supports.
E
Yeah,
that's
that's
a
great
point.
Okay,
so
that's
so
this
would
help
via
for
inbound
requests
so
in
in
the
context
of
an
outbound
requests.
If
the
SDK
is
gonna,
have
some
published
method,
but
actually
you
know
sends
it
out
via
you
know
some
transport
and
again
we're
just
kind
of
focused
on
HTTP
for
now
and
they're
gonna,
send
it
out
to
I,
guess:
HTTP
endpoints,
where
we
were
they
likely
I
guess
you
just
should
not
assume
to
know
what
those
a
what
versions
of
cloud
events
those
HTTP
endpoints
support
right.
I
That's
right,
I,
don't
think
we
can
make
that
assumption,
because
we're
not
necessarily
in
control
of
the
influences
either
right
so
assume
like.
Let's
say
we
go
from
one
to
one
point:
one
and
I
upgrade
my
SDK,
but
the
endpoint
has
not
upgraded
yet.
You
can't
assume
that
one
point
one
format
will
work
within
the
one
auto
context.
I
So
really
it
almost
seems
to
me
like
there
needs
to
be
kind
of
like
a
pre-flight
check
to
be
able
to
determine
what
version
the
endpoint
actually
supports
and
then
gives
the
the
SDK
a
chance
to
downgrade
the
event
for
month
in
February.
It
realizes
yeah
this.
This
endpoint
does
not
speak.
This
version
of
the
spec.
E
K
E
The
way
I've
been
coordinating
this
effort
right
now,
it's
largely
to
do
it
through
this
document
and
to
list
all
kind
of
our
outstanding
questions
there.
However,
I
think
this
should
be
done.
I
think
this
should
be
done
through
the
github
repo
somewhere,
so
that
it's
tracked
people
can
always
find
the
discussion.
So
perhaps
I
could
open
up
the
issue
just
in
the
cloud
events
repo
and
we
could-
we
could
discuss
it.
There
yep.
E
It's
kind
of
leads
into
the
next
question
that
is,
project
structure.
I,
think
we
had
two
suggestions
for
how
to
do
this.
It
seems
like
all
the
volunteers
who
are
working
on
this.
Our
total
fine
with
posting
the
SDKs
that
they're
contributing
to
within
the
cloud
events
org
on
github
and
I.
Think.
The
question
now
is
whether
we
just
want
to
do
a
mono
repo
structure,
and
that
has
put
all
the
cloud
events
SDKs
into
a
single
repo
or
we
should
create
separate
repos
for
for
each
language.
Does
anyone
have
any
strong
opinions
on
these.
E
The
maybe
perhaps
one
challenge
with
that
is
simply
to
discuss
in
general
design
of
SDK
and
to
answer
questions
like
this.
You
know
if
we're
spread
out
across
a
lot
of
different
repos.
Perhaps
we
should
just
keep
the
discussion
within
the
core
cloud
event:
specification
repo
and
keep
kind
of
language
specific
implementation
details
with
within
these
specific
repos,
that's
unreasonable.
A
B
D
E
For
volunteering,
okay,
great,
this
helps
me
kind
of
make
sure
I
reach
out
to
all
the
people
who
are
volunteering
that
keep
them
informed
as
to
what
we're
doing
I
think
we'll
probably
have
another
SDK
call
soon
here,
because
we
need
to
clarify
how
we're
handling
some
of
these
versioning
issues
to
unblock
the
implementations.
So,
okay,
look
out
for
the
issue
regarding
how
to
handle
some
of
these
versioning
issues
as
well
as
github,
repos
and
I
will
coordinate
another
SDK
call
probably
shortly
here
and
that's
it
for
general
SDK
updates.
E
I
E
H
G
E
E
M
Yeah,
so
it's
177
posted
in
the
chat
quickly,
but
basically
the
issue
comes
down
to
the
fact
that
in
the
HTTP
spec
headers
are
defined
as
case
insensitive
and
in
particular
for
the
the
go
implementation
go.
Does
what
the
headers
is
a
canonical
Liza's
them
as
they
call
it,
and
basically
that
means
anything
after
the
first
letter
of
the
header
and
the
for
anything
after
a
dash
is
capitalized.
M
Everything
else
is
lower
cased,
which
means
if
we
have
in
particular
extension
properties
that
we
put
into
the
header
for
the
the
binary
transport
spec
in
go
in
particular
and
I
assume
in
other
cases
where
a
proxy
might
mangle
the
headers
or
something
the
the
case.
Sensitivity
of
the
the
header
is
lost,
and
we
can't
guarantee
that
we
use
the
right
case
as
the
property
name
in
the
JSON,
for
example
right.
M
So
if
I'm
in
this
SDK
I
am
accepting
a
HTTP
version
of
the
thing
and
forwarding
on
to
a
JSON
endpoint
in
particular
for
extensions
I
can't
guarantee
that
they'll
have
the
same
casing
when
I
pass
them
on
right
with
the
well-known
ones.
I
can
go
ahead
and
make
my
own
determination
and
put
the
correct
case
in
there.
M
M
If
an
older
version
of
the
SDK
needs
to
deal
with
an
extension
that's
been
promoted,
it
can't
automatically
do
the
the
proper
casing
of
those
headers
so
kind
of
basically
there
that
we
have
to
either
make
a
decision
that
the
properties
should
be
case
insensitive
or
perhaps
that
I
don't
know
you
give
some
other
way
in
the
property
name
for
the
header,
specifically
that
indicates
which
of
the
the
letter
or
which
of
the
you
know
the
casing
of
each
of
the
individual
characters.
So
perhaps
you
know
the
the
simple
way
and
go
would
be.
C
C
A
A
J
So
this
one
just
fix
a
link
issue
in
the
readme
file
and
also
other
contributors
who
has
contributed
to
this
work
flows.
Back
I
saw
a
comment
requesting
that
asking
what
authors
so
and
also
to
be
compliant
with
the
crowd
events,
so
just
add
a
similar
format
to
the
cloud
events
yeah
if
I
miss
any
one.
Please.
Let
me
know:
okay.
J
A
J
A
The
minor
thing
ID
in
terms
of
process
going
forward
I'm,
assuming
that
we're
following
the
same
process
here,
that
we
do
with
all
the
others,
which
is
at
least
four
changes
like
this-
that
are
strictly
editorial
in
nature.
For
the
most
part,
we
just
need
one
or
two
LG
TM,
and
then
we
can
merge
it
in
so
I
think
what
Kathy
is
looking
for
here
is
some
people
to
put
some
eyes
on
here
into
LG
TM
it
once
this
comment
is
addressed.
Is
that
right,
Kathy,
yeah.
J
Not
really
yeah,
if,
like
you
know,
I,
think
that's
that's
about
it,
so
I
think
going
forward.
If
there
are
any
issues
we
can
have
more
discussion.
I
have
more,
you
know,
meeting
discussion,
okay,.
H
A
H
A
B
A
J
C
We
had
discussions
about
object
versus
any
because
object,
clashes
with
the
concept
of
JavaScript
and
I
meant
it
in
the
in
the
way
how
Java
and
c-sharp
do
it.
It
can
be
the
any
type
we
then
landed
on
using
the
name
any
after
discussions,
and
what
this
does
is
it
this
chain
catches,
hopefully
all
places
where
we
are
referring
to
this
particular
thing
as
in
the
object,
type
and
renamed
it
to
be
any
time,
and
that's
all
it
was.
C
L
A
So
they
call
on
one
particular
person,
Thomas
I
know
you
were
deeply
involved
in
the
conversations
last
time
we
heard
about
this
I
assumed
you're.
Ok
with
this
I
think
you're,
ok,
with
changing
I
think
this
looks
good
to
me.
Ok,
anybody
else
have
any
comments
or
questions
on
this
one
right
is
there
any
objection
to
adopting
it.
A
B
A
H
A
H
So
this
is
a
really
quick
change.
I
think
we've
talked
about
before
this
change
so
before
the
standard
for
being
a
de
facto
standard.
Sorry,
the
bar
for
being
me
to
practice
that's
less
confusing
is
that
you
should
come
out
of
a
multi
company
because
sort
consortia,
and
we
had
some
examples.
This
changes
it
to
be
that
you
could
come
out
of
a
multi
company
consortium
where
you
could
be
released
by
a
single
company
at
the
point
is
that
you
have
a
strong
ecosystem
around
you.
A
A
Okay,
so
we
have
the
Poulter
transfer,
binding
I
did
ask
the
author
of
this
PR.
If
they
could
help
us
or
let
us
know
whether
they
thought
they
actually
met,
that
the
new
minimum
bar
that
we've
defined
and
basically
they
said
no,
it
does
not
so
they're.
Okay
closing
it.
However,
before
I
closed
it
I
wanted
to
make
sure
there
was
anybody
in
the
working
group.
Arms
are
at
the
project
who
thought
there
was
some
reason
to
keep
it
open
for
some
reason.
A
Thank
you
all
right
now,
this
one
as
I
mentioned
in
my
email,
this
did
go
in
I
think
just
yesterday.
So
it's
a
little
bit
new,
however
I'm
hope
people
people
got
a
chance
to
look
at
it.
It
is
relatively
straightforward
for
the
most
part,
most
part,
it's
really
syntactical
I
did
remove
the
notion
of
us
being
a
working
group
because
we're
not
a
working
group
or
just
a
project,
actually
a
sandbox
project.
A
That
said,
you
know
we're
going
to
encourage
offline
discussions
in
particular
we're
asking
for
you'll
do
reviews
and
then
I
did
talk
about
the
different
types
of
membership
here
and
mainly
I
want
to
make
it
clear
that
pretty
much
anybody
who
contributes
in
any
fashion
whether
it's
just
joining
phone
calls
writing
pr's
or
issues
they
are
members
and
no
formal
registration
is
needed.
Voting
members
are
really
no
different
than
normal
members
in
terms
of
rights
other
than
they
get.
The
vote
and
I
did
point
a
reference
down
to
the
voting
section.
A
A
Okay,
I'll
fix
that.
Thank
you
and
now
talk
about
admins.
Basically,
they
have
no
special
rights
whatsoever
other
than
they
can
do
stuff
in
their
github.
Repos
they've
moderate
the
meeting
and
stuff
like
that,
but
they
only
do
it
on
behalf
of
the
working
groups.
The
working
group
is
guys
that
greet
all
those
changes
anyway,
but
then
they
get
to
actually
do
the
actual
action
itself.
A
The
only
other
change
is
tabs
spaces,
because
tabs
are
evil
in
case
you
didn't
know
that
I
did
add
an
owner's
file
just
to
define
who
the
current
set
of
admins
are,
and
it's
basically
the
same
sort
of
co-chairs
from
the
service
working
group,
so
me
mark
and
Ken
other
than
that
it's
just
working
group
getting
rid
of
getting
rid
of
the
work
working
group
in
those
part.
If
people
are
would
like
more
time
on
this,
you
know
feel
free
to
speak
up.
A
H
A
J
A
H
A
I
think,
that's
that's
why
you
sort
of
got
in
there
by
default.
We
can
have
that
discussion
about
whether
it
makes
sense
to
keep
him
like,
but,
like
I
said,
it
doesn't
really
give
him
any
more
rights
other
than
he
can
perform
administrative
activities
on
behalf
of
the
group
if
he
needs
to
so
it's
not
like
he
has
special
voting
rights
or
anything
like
that.
That's
why
I
felt
comfortable
with,
but
keeping
him
in
there.
J
Sadaqa
I'm,
going
reading
through
this
I
see,
is
having
any
of
their
assent
representatives.
So
could
this
be
changed
or,
like
you
know,
for
example?
Sometimes
you
know
like
I
said
someone
cannot
be,
cannot
attend
the
meeting
because
of
business
trip
or
other
reasons.
Could
he
or
she
don't
have
another
one
represent
yeah.
A
So
that
that's
an
interesting
topic,
so
basically,
what
you're
talking
about
is
someone
basically,
what's
the
word
I'm
looking
for
kind
of
taking
up
your
someone
take
on
your
alternates
that
doesn't
alternate
like
cases
that
these
standards
meetings
yeah
proxy,
that's
the
what
I'm
looking
for
you.
G
A
A
An
interesting
topic,
I
think
Kathy.
If
we
want
head
down
that
path,
I'm,
okay,
with
exploring
it
obviously
but
I-
think
that's
a
separate
issue,
because
what
you're
basically
talking
about
is
modifying
this
section,
which
I
purposely
did
not
try
to
modify.
So
if
you
want
or
if
you
want
to
head
down
that
path,
can
you
open
up
an
issue
too
yeah?
Not
that
discussion,
yeah.
N
At
the
time
when
we
discussed
that
the
idea
was
three
meetings
aggregate
by
both
the
primary
and
the
alternative,
not
each
one
of
them
has
to
have
three
three
consensus.
Meetings
correctly
alternate
yes,
yes
using,
maybe
English
is
not
my
native
language,
but
for
me
to
read
it,
it
sounds
like
it
needs
to
be
either
of
them.
Each
one
of
them
has
three
yeah.
A
A
A
A
A
A
Well,
I
tried
to
take
a
first
pass
at
defining
the
minimum
bar
for
adding
a
new
extension.
The
basic
rule
here
that
I
try
to
put
forward
is,
it
has
to
be,
has
been
education
from
at
least
two
people
or
two
companies
that
they
want
that
actually
want
this
and
will
use
it.
So
it's
at
least
two
different
today.
Two
independent
projects
will
implement
the
basically
or
have
interest
in
using
it
now
Eric
you
raised
some
concern,
I
think
you're
on
the
call
now.
Would
you
like
to
talk
about
your
concerns?
O
They're
welcome
to
read
most
of
it
in
the
issue.
I
think
the
one
that
in
this
may
relate
I
I'm.
Sorry,
the
commute
was
terrible,
but
the
this
may
relate
to
the
earlier
PR
that
was
discussed
is.
Is
that
whether
the
conditions
that
we're
laying
out
in
the
news
documents
can
be
can
force
our
hand
as
a
group?
So
can
two
people
or
two?
O
You
know
two
people
create
two
projects
and
those
two
projects
independently
endorse
a
an
extension
and
that
extension,
because
of
this
document,
has
to
be
put
into
the
extensions
document
now
I
it's
coming
from
a
paranoid
space.
It
seems
like
an
unlikely
sort
of
a
thing
and
also
I
was
curious
just
about
the
way
that
we've
been
wording.
It
hasn't
has
been
kind
of
removing
us
from
that
that
workflow
and
it
seemed
like
the
the
really
the
real
value
that
we're
trying
to
provide.
A
L
One
idea
is
just
playing
with
it
in
my
head:
I
I'm,
trying
to
figure
how
to
make
it
not
too
much
of
an
ink
route,
but
basically
saying
if
you
have
to
endorsing
voting
groups,
it
doesn't
matter
how
many
people
are
disinterested
in
the
the
extension
it's
just
like.
If
you
basically
have
people
who
have
been
interesting
cloud.
Events
that
you
know,
I
can't,
for
example,
create
a
new
project
and
have
represented
that
and
have
Rachel
support
me
because
we're
both
in
the
Google
voting
bloc.
A
A
L
O
A
L
A
P
A
A
Actually
shared
that
view,
has
there
been
situations
where
I
was
the
only
IBM
er
in
a
group
and
I
happen
to
be
the
one
submitting
all
the
core
requests
and
I
couldn't
tell
GTM
it.
So
what
it
meant
is
I
had
to
get
someone
else
to
submit
all
my
PRS
for
me
and
just
feels
like
game
playing
I'd
rather
not
get
into
that
situation.
A
L
A
A
C
Also,
rules
that
require
rules
that
require
too
many
people
to
be
to
be
present
in
the
overall
process
start
to
become
real
blockers.
Once
the
working
group
or
sorry
project
gets
a
little
quieter
because
we're
kind
of
done
with
vo1
and
then
people
are
moving
to
implementation
rather
than
writing
more
spec,
because
in
the
end
there's
only
five
or
six
people
left
and
then,
if
there's
process
that
requires
seven
people
to
be
present,
it's
a
little
difficult.
Yes,.