►
From YouTube: WG-Gateway API GAMMA Bi-Weekly Meeting for 20220809
Description
WG-Gateway API GAMMA Bi-Weekly Meeting for 20220809
A
Hello,
everybody
welcome
to
the
august
ninth
instance
of
the
gamma
gateway
api
meeting.
As
a
reminder,
this
meeting
is
opened
by
the
kubernetes
code
of
conduct,
so
make
sure
to
you
know,
modify
your
or
behave
appropriately,
so
I
am
going
to
go
ahead
and
share
my
screen.
We've
got
a
little
bit
of
agenda
today,
but
if
you've
got
any
more
agenda
items,
then
please
feel
free
to
add
our
document.
A
C
C
A
Yes,
thank
you.
We
do
want
to
make
sure
we're
recording
but
yeah,
so
the
gateway
api
folks
mentioned
as
you're
starting
this
up,
that
it
would
be
great
to
kind
of
do
periodic
updates
from
what
we
work
on
here
in
the
game.
I'm
meeting
and
bringing
that
to
the
kind
of
the
upstream
gateway
api
meeting,
and
I
I
think,
a
good
kind
of
checkpoint
to
share
some
of
our
progress
would
be
august
22nd.
A
Approximately
that
gives
us
two
meetings
in
this
time
slot
two
meetings
in
the
in
the
eight
eight
in
the
early
time
slot,
and
that
way
we
can,
you
know,
update
kind
of
attendance
on
both
and
get
feedback
from
everybody
and
also
kind
of
share
the
technical
progress
that
we've
been
making.
So
keep
that
in
mind,
if
you
want
to
be
at
the
monday
gateway
api
meeting
at
3
pm
pacific
time
to
share
that
any
questions,
comments
or
concerns
on
on
that
before
I
move
on.
A
Wayward
son,
all
right.
Let's
move
on
to
the
action
item
review.
I
put
this
here
after
the
last
meeting
and
I
kind
of
like
this
style
of
going
ahead
and
getting
on
the
agenda
immediately,
so
we
can
kind
of
make
sure
we're
viewing
our
action
items
and
checking
in
so
you
can
eat
more
support
and
stuff
like
that.
A
B
So
there's
a
doc
up
at
hackman
hackmd
and
it's
in
hackmd,
because
it
simply
was
not
worth
the
time
to
try
to
go
through
and
wrestle
google
docs
list
structures
and
things
like
that
in
any
way
that
that
I
would
have
spent
far
more
time
doing
that
than
I
spent
writing
on
this
and
again
you
can
make
that
window
a
lot
narrower,
so
people
can
read
it.
There
are
a
couple
of
things
here.
B
I
deliberately
started
the
use
case
of
a
developer,
who
has
already
dealt
with
the
ingress
problem,
since
that's
the
first
one
that
they're
going
to
have
to
deal
with
and
is
now
going.
Oh
hey,
mesh
functionality
would
also
be
a
good
thing
that
brought
some
brought
up
a
couple
of
really
interesting
questions
that
I've
called
out
in
there.
B
B
B
At
the
you
know,
down
lower
level
that
sort
of
thing-
and
I
think
that
those
will
be
really
really
good
things
to
talk
about.
I
also
want
to
go
through
and
add
more
use
cases
here.
The
ones
that
I
was
specifically
thinking
about
in
the
first
place
had
to
do
with
like
authorization
policy
and
taking
a
look
at
the
distinction
between
suppose.
You
don't
want
to
mess
your
mesh.
Your
ingress,
but
let's
see
I
was
going
to
ask
for
other
use
cases
that
people
particularly
wanted
to
roll
out
of
a
new
version.
B
B
So,
like
I
said,
I
don't
really
know
how
much
sense
it
makes
to
burn
a
lot
of
time
on
this
if
people
have
not
had
time
to
really
go
and
read
over
that
document,
I
suspect
people
have
not
had
a
ton
of
time,
so
that
might
be
one
that
we
should
defer.
You
know
defer
until
next
time,
given
that
we've
talked
a
little
bit
about
some
of
the
questions
that
came
up
from
that.
B
D
D
No,
I
think
I
think
that
makes
sense
and
oh
yeah.
I
really
appreciate
you
doing
this
initial
exploration
and
yeah.
I
think
just
like
for
future
notes,
anytime,
that
there's
a
doc
something
like
that.
That
folks
can
look
at
have
a
chance
to
look
at
before
meeting
like
just
dropping
likes
and
slack
would
be
wonderful.
A
C
Yeah,
I
just
one
of
the
comments
that
I
think
you
had
made.
Flynn
was
specifically
about
whether
I
think
my
interpretation
of
it
was
if
it
makes
sense
to
use
the
same
http
route
for
ingress
traffic
and
mesh
traffic,
and-
and
I
guess
a
broader
question
is
is-
is
that
re?
Is
that
a
goal
of
gamma
to
use?
So
it's
one
thing
to
use
the
same
apis.
B
B
C
F
Hey
I
had
a
question:
can
you
guys
hear
me?
Okay,
it
looks
like
it,
so
I
I
definitely
think
like
what
you
have
in
this
doc
is
great.
Every
proposal
should
be
written
in
a
way.
That's
like
the
user
flow.
I
think
that's
that's
great.
My
question,
though,
is
what
exactly
is
the
goal
of
this,
like
one
interpretation,
but
I
want
to
run
it
by
you.
Is
that
you're
saying
here's
what
it
looks
like
to
use
http
route
for
mesh
and
it
looks
bad
here
which
I
agree.
F
B
In
the
last
meeting,
I
think
this
was
the
one
last
week,
not
the
last
one
in
this
time
slot,
then
there
was
a
certain
amount
of
discussion
around
hey.
Should
we
use
http
route
and
one
of
the
outcomes
of
that
was
well.
Maybe
we
should
write
out
an
example
workflow
and
see
how
it
looks
so
this
was
a
response
to
a
bunch
of
questions.
B
F
F
F
B
I'm
conflicted.
On
the
one
hand,
I
want
to
hear
about
what
you
know,
what
what
you
think
you
would
change
and
not
you
know
what
in
what
manner
would
you
use
it?
On
the
other
hand,
I
am
concerned
about
whether
people,
you
know
whether
everybody's
had
much
of
a
chance
to
really
read
and
think
about
it.
Yeah
can.
B
B
E
A
I
really
appreciate
the
time
to
that's
been
put
into
write
this
stock,
and
this
is
the
kind
of
thing
that
we
need,
but
I
feel-
and
folks
may
disagree
with
me
here,
but
I
feel
that
this
dog,
and
at
least
the
some
of
the
disagreements
around
the
conclusions
around
this
doc,
are
because
this
doc
still
feels
like
it's
talking
about
a
lot
of
the
how,
as
opposed
to
the
as
opposed
to
the,
what
and
the
why.
So
there
are.
A
I
I
had
a
chance
to
read
through
it
and
so
there's
some
specific
uses
like
his
http
route.
That
is
specifically
bound
to
a
service
and
even
then
like
a
mesh
resource
like
it.
The
doc
assumes
we're
going
down
one
or
more
different
options
that
we
chatted
about
in
the
exploration
dock,
and
so
I
think
in
general
I
I
feel
like
it
might
be.
A
Where
I
think
we
are,
as
I
think,
it's
difficult,
because
there's
so
little
that
we've
decided
on
and
so
trying
to
do,
something
like
this,
where
you're
looking
at
resources
and
what
are
the
cli
steps
to
take
is
difficult
without
having
a
how
and
I
don't
know
that
we
have
a
how
yet
for
mesh
representation
and
service
binding
and
maybe
more
docs
like
this-
are
our
useful
way
to
go
about
feeling
out
what
the
best?
How
is
and.
B
That
was
pretty
much
the
perspective
that
I
was
taking
in
writing.
It
was,
we
can
talk
about
a
lot
of
different
house
and
some
of
them
it
might
make
more
sense
to
just
really
sit
down
and
look
at
the
example
of
okay.
If
we
do
it
this
way,
how
does
it
affect
the
user?
How
does
it
affect
a
particular
kind
of
end
user.
B
I
am,
I
am
biased,
right,
I'm
very,
very
biased,
because
in
the
time
that
I
spent
in
ingress
land,
we
did
a
lot
of
this
and
we
found
that
it
really
helped
out
a
lot.
So
it's
fairly
natural
for
me
to
try
to
reach
over
for
this
and
just
try
to
think
about
it
from
the
perspective
of
okay.
We
know
that
they're
going
to
be
people
who
are
trying
to
use
this
where
this
is
not
where
this
isn't
where
their
heart
is.
B
What
they
want
to
do
is
work
on
the
thing
that
they're
working
on-
and
this
is
just
something
that
they're
gonna
try
to
get
out
there
with
minimal
friction
and
get
it
used.
So
how
does
this
idea
fit
with
that
answer?
This
idea-
maybe
not
so
well,
but
that
was
very
much.
The
goal
was
to
explore
one
of
the
house
and
see
how
it
worked
out.
A
Gotcha,
and
so
it
feels
like
the
the
get
process
that
we
kind
of
started
last
last
week,
and
I
mean
last
week
as
in
literally
last
week,
I
feel
like
that
process
is
really
focused
around
the.
What
and
the
why
and
getting
that
clarified,
and
I
think
I
think
the
and
I
don't
know
if
shane
was
able
to
come
back,
but
I
I
feel
like
the
idea
in
going
that
direction
was
that
we
would
get
the
what
and
the
wife
first
before
doing
the
how.
B
Another
thing
that
would
be
really
really
easy
to
do
would
be
to
haul
out
the
steps
of
what
jane
is
doing
from
this
user
flow
and
then
to
write
out.
Some
of
the
other
flows
for
here
are
things
that
I
think
people
these
roles
are
going
to
want
to
do.
It
would
be
very
easy
for
me
to
pull
that
out
as
a
way
of
exploring
more
of
the
what
and
then
leave
the
how
aside.
D
Yeah
sorry,
I
haven't
had
a
chance
to
look
at
your
proposal
in
detail,
but
I
think
just
I
guess
just
to
level
that
with
everyone,
it's
so
challenging
with
your
user
case
trying
to
solve
trying
to
solve
the
scenario.
Well,
the
ingress
may
have
a
different
route
than
the
mesh
route
for
a
given
service.
B
D
B
The
particular
thing
that
I
would
case
that
I
was
talking
about
was
one
where
the
ingress
has
a
route
saying:
hey,
go
and
take
this
particular
chunk
of
the
url
space
over
to
this
workload,
use
the
service
name
to
identify
the
workload
later,
the
person
wants
to
use
the
mesh
to
split
traffic.
To
that
workload
between
two
different
versions
of
the
workload
are
those
the
same
route.
Are
they
a
different
route?
Should
they
be
different
resources.
D
D
D
F
I
I
kind
of
did,
but
I
wasn't
sure,
but
I
guess,
since
you
asked
I'll
say
it,
it
seems
like
this
is
kind
of
assuming
in
this
stock,
something
that
was
surprising
to
me
and
I
I
get
why
I
was
just.
I
didn't
expect
this,
because
my
I
was
expecting
more
narrow
view
that
the
ingress
is
like
some
pod
running
in
the
cluster.
F
Well,
maybe
not,
but
it's
part
of
the
mesh
and
you
have
like
two
distinct
configs
one
is
like
you're
configuring,
the
ingress
part
of
that
and
then
like
it's
sidecar,
which
to
me,
I
think,
is
a
lot
of
why
this
feels
kind
of
awkward,
because
you
kind
of
have
one
logical
unit.
But
it's
split
into
two
proxies
which
are
configured
with
two
different
http
routes.
F
It,
it
seems
like
most
users
of
of
mesh
like
they're,
not
deploying
a
sidecar
next
to
their
ingress,
like
you
have
your
ingress,
it's
coming
from
english
or
it's
coming
from
inside
the
cluster
right,
and
so
in
a
lot
of
those
cases.
You
know
you
want
the
same
rules
to
apply
to
the
sidecars
and
to
the
ingress,
because
why
do
you?
You
know
regardless,
where
it's
coming
from
you
might
canary
rules
applied,
and
so
you
don't
really
split
those
up
actually.
B
F
So
I
guess,
like
my
perspective,
is
coming
from
a
mesh
people
in
them
that
use
these
jio
use
estio
ingress,
which
is
part
of
the
mesh,
but
doesn't
have
a
side
car.
From
your
perspective,
I
can
see
if
you're
running
an
api
gateway,
then
the
way
you
integrate
that
with
the
mesh
is
trying
to
sidecar
right
so
like
it,
it
doesn't
seem
like
if
you
have
that
case,
where
you
have
your
ingress
with
a
sidecar.
Why
would
you
want
to
do
any
routing
in
the
match?
Just
do
it
at
your
ingress
layer
right.
F
That's
where
I
feel
is
the
awkward
part.
Is
that,
like
we're
kind
of
trying
to
solve
like
the
wrong
problem
here,
I
feel
like,
like.
I
don't
think
the
use
case
here,
as
described
I
mean
the
high-level
use
case.
Yes,
I
want
to
split
traffic,
absolutely
that's
like
bread
and
butter,
but
the
actual
like
more
implementation.
Detail
use
case
of
I
want
my
ingress
to
be
part
of
the
mesh
and
like
they
do
different
parts
of
the
same
equation.
I
don't
think
that's
a
use
case
that
we
should
be
optimizing
for.
A
I
feel
like
there's
still
probably
to
to
john's
point,
I'm
trying
to
think
of
a
scenario
where
you
don't
necessarily
you
want
the
same
routes
to
apply
like,
especially
as
far
as
like
policy
or
even
canary
having
that
split
up
in
different
resources
might
be
awkward.
I
I
I
I
know
I'm
getting
into
how
here
but
like
the
way
I
would
think
about
it
is
in
the
in
this.
In
the
base
case,
you
would
typically
have,
I
would
think.
A
You'd
have
two
different
parent
refs
one
to
represent
mesh
traffic
and
one
to
represent
traffic
from
ingress,
and
so,
but
the
kind
of
the
route
delegation
logic
that
seems
present
in
the
dock
is
also
another
way
to
go
about
it.
So
maybe
that's
where
the
conversation
needs
to
start
happening
around
the
how
and
and
tracking
those
separately.
I
don't
know.
B
To
kind
of
bump
this
one
up
a
level.
I
think
one
of
the
questions
here
very
much
is
okay.
What
sorts
of
things
do
you
want
to
support
right?
If
it's
probably
okay
for
us
to
say
that
well,
yeah,
if
you're
using
an
ingress,
you
need
to
be
doing
canarying
at
the
ingress
rather
than
having
the
mesh
to
it.
B
B
B
All
of
these
are
things
where,
like
I
said
it,
it's
I'm
perfectly
happy
to
go
through
and
put
together
some
cases
with
hey
here's
you
know
here
are
things
that
a
user
will
probably
want
to
do
and
then
back
up
from
there,
and
I
want
to
be
explicit
about
saying
that
yeah.
When
I
was
writing
this,
I
was
trying
to
show
an
example
of
something
a
user
might
try
to
do
not
necessarily
show
an
example
of
something
that
I
personally
thought
was
the
best
way
to
get
it
done.
B
E
Yeah,
so
I'm
still
not
sure
understand
what
is
a
problem
you're
trying
to
solve
here
with
with
this
example,
because
with
http
route,
the
user
has
option
or
could
attach
the
route
to
both
ingress
and
mesh,
and
that
will
satisfy.
There
is
a
one
use
case,
or
they
may
choose
to
not
attach
to
attach
one
http
router
to
the
gate,
to
a
different
http
router
to
a
mesh
if
they
want
to
control
it
differently.
Both
of
them
are
perfectly
varied
choices
that
can
make
if
they
have.
E
You
know
the
same
implementation
for
gateway
and
for
mesh,
which
is
probably
very
going
to
be
very
common,
because
we
want
some
integration
between
them,
no
problem
if
they
want
to
use
an
external
ingress
again,
no
problem,
because
the
external
ingress
will
use
whatever
configuration,
not
http
route,
so
users
will
not
be
confused
too
much.
So
I.
E
E
B
B
A
A
A
This
ensures
an
implementation
knows
a
route
should
apply
to
particular
mesh
instantiation
and
not
something
else.
Another
master
at
ingress
gateway,
et
cetera.
I
started
working
on
some
goals.
This
is
what
I
was
able
to
come
up
with
in
the
wait
for
the
time.
I
spent
writing
this,
but
the
the
big
goal,
I
think,
is
to
create
a
consistent
way
to
represent
a
match
through
gateway
api.
A
But
this
is
something
that
I
think
we
should
decide
as
as
far
as
the
what
of
mesh
representation.
I
think
this
is
something
we
should
explicitly
decide
at
this
juncture
about
whether
or
not
this
is
a
requirement
for
the
spec
and
the
idea
behind
this
is,
I
think,
to
shane's,
prompting
I
put
some
more
detail
here.
A
Now,
whatever
scheme
we
use
for
mental
presentation
shouldn't
prevent
those
meshes
from
continuing
to
operate
in
that
way,
that's
kind
of
the
idea
behind
that
phrasing,
but
that
phrasing
should
likely
again
wait
a
little
time
to
spend
on
this
on
the
phrasing,
so
it
should
likely
be
changed
or
made
to
be
more
narrow
or
specific.
We'll
come
back
to
that
in
a
second
I
didn't
get
too
far
on
non-goals,
and
then
here's
where
I
wanted
to
drill
down
based
on
our
kind
of
conversation
we
just
had
around
scoping,
so
around
representation.
A
A
I
feel
like
that's
probably
the
more
the
most
basic
thing:
we've
got
to
be
able
to
associate
a
service
with
with
this
mesh,
or
maybe
we
associate
a
route
with
with
it.
This
is,
these
could
probably
be
collapsed
heck.
This
is
probably
just
needs
to
be
a
question
mark
as
well,
so
service
association.
Are
we
associating
a
service
to
the
mesh
or
listener
attachment
or
route
attachment?
G
I
feel
like
a
pr
that
created
a
provisional
gap
that
just
said
the
first
goal
is
actually
a
reasonable
place
to
start
for
something,
that's
massive,
I
know
it
may
sound
silly,
but
like
just
getting
that
in
and
then
people
can
start
like
not
just
you
keith
but
like
everybody
can
start
to
like
add
their
goals
on
top
of
that,
so
that
we're
building
iteratively
on
top
of
that,
it
might
be
a
good
way
to
get
this
going
faster.
I
can
just
see
this
burning
for
a
while.
I
can.
G
G
C
Yeah,
so
I
I
would
just
say
that
I
think
we're
all
running
into
the
limitations
of
technology
here
and
the
various
every
system
we're
using
has
its
own
flaws.
I
appreciate
docs
hackmd
github,
but
I
I
know
we
have
run
up
against
the
issues
of
github
review
scalability
with
even
more
recently
jeff's
route
delegation
gap,
where
we
put
you
know,
150
comments
on
it
and
get
and
it's
starting
to
come
to
a
crawl
earlier
pr's
had
two
300
and
it
fell
apart.
C
So
I'm
not
saying
no,
but
I
think
what
what
we
should
do-
and
this
is
an
overall
theme,
irrespective
of
technology-
is
focus
on
these
small
iterative
steps.
I
think
we're
all
in
agreement
that
if
we
get
stuck
too
long
on
a
big
thing,
we're
going
to
get
stuck
for
way
too
long,
it's
going
to
be
hard
to
recover
from
that
state.
C
I
think
what
we
may
want
to
agree
on,
though,
before
we
merge
a
pr
or
something
like
that
is
a
fairly
representative
set
of
goals,
for
example
right
like
if
we
just
say
this
is
one
goal
and
then
we
add,
you
know
additional
goals
at
that.
At
later
points
it
may
become
hard
to
understand
when
goals
are
complete
and
when
we
can
transition
to
the
next
phase
of
how
we
accomplish
those
goals,
for
instance.
C
A
I
think,
when
you're
talking
about
doing
things,
iteratively
smaller
chunks,
I
think
make
for
or
allow
for
tighter
deadlines,
because
you're
not
asking
for
quite
as
much
and
so
I've
personally
found
more
success,
doing
doing
just
that
scoping
things
down
and
have
some
type
of
I'm
not
opposed
to
that
at
all.
I
think
well,
not
tangential.
It's
a
kind
of
a
a
question.
A
I
think
that
between
the
two
different,
I
think
between
the
two
different
time
slots,
I
think
we've
got
pretty
decent
coverage
from
folks
in
the
in
the
space,
but
I
want
to.
I
do
want
to
call
that
out
and
be
sensitive
to.
If
we're
going
to
have
tight
deadlines,
then
we
want
to
make
sure
folks
have
the
chance
to
submit
things
I
think
exchange.
I'm.
G
B
G
I'm
not
sure
my
my
instinct
based
on
just
history.
My
history
is
that
if
we
can
just
get
these,
if
we
can
just
think
and
get
these
things
down
into
much
more
tiny
things,
we
won't
need
those
deadlines,
necessarily
because
everybody
who
is
trying
to
champion
this-
and
there
are
multiple
champions
and
that's
part
of
why
this
is
going
to
be
a
hard
one,
to
get
a
lot
of
like
to
get
tons
of
velocity
on,
because
there's
multiple
people
who
want
to
champion
on
this
and
that's
good,
but
it
will
take
longer.
G
G
We
just
need
to
get
a
signal
that
we're
trying
to
do
this
in
a
gap
and
then
see
if
we
can
just
encourage
people
to
make
the
smallest
contributions
they
can,
because
if
we
can
do
that,
I
imagine
we
can
get
the
speed
that
we're
trying
to
get
by
putting
a
timeline
without
having
to
put
a
timeline
and
potentially
making
it
frictional.
Where
somebody
feels
like
they
can't
contribute
something
that
might
be
very
valuable
at
some
point
after
the
timeline.
C
Yeah
I'll,
without
getting
too
too
into
the
leads
here,
I
don't
care
too
much
how
how
we
approach
this.
I
just
want
to
make
sure
everyone
has
a
say:
everyone
has
a
chance
to
contribute.
No
one
feels
like
they
missed
the
boat
and
also
that
we
don't
get
with
this.
We
are
at
very
high
risk
of
getting
just
completely
stuck
on
a
large
task,
a
large
dock,
a
large
review
somewhere,
and
so
my
biggest
concern
is
trying
to
avoid
that
state.
I
don't
care
too
much
how
we
do
that
open
to
any
approach.
G
I
get
that
I'm
I
am
when
I
was
at
the
last
meeting.
I
think
it
was
the
last
meeting,
maybe
as
long
before
that
I
was
in
the
gray
zone
of
like
I'm,
not
even
sure
if
we
should
do
this
in
gateway
api
and
over
the
course
of
the
last
week,
or
so
I
am
now
kind
of
more
firmly
in
that.
I
do
think
that
we
should
do
this
kind
of
territory.
So
for
what
that's
worth?
That's
what
I
would
like
to
see
represented
in
our
in
our
repository
right
now.
G
If
nobody
is
in
a
different
space
and
has
a
really
good
argument
against,
I
don't
have
most
of
it.
I
don't
have
a
good
arguments
against
and
part
of
it
is
I'm
seeing
the
value.
I
don't
see
the
how
yet
that's
that's
completely
unclear,
but
that's
not
what
we're
trying
to
solve
just
yet
right.
So
I
don't
know
for
what
it's
worth,
I'm
like
flipping
my
switch
a
little
bit
and
kind
of
going
a
little
bit
into
the
yes.
Let's
do
this
kind
of
territory.
A
G
Yeah,
you
know
what
I
put
a
wrench
in
the
system
here,
because
I
had
kind
of
a
different
idea
about
how
this
should
go,
but
I'm
not
exactly
driving.
I
might
start
driving
at
some
point
but
you're
driving.
So
I'm
good
with
going
with
your
intuition
on
this,
that
you
want
to
have
more
goals
up
front.
That's
fine!
I've
loaded,
something
out
there.
That
seemed
to
make
sense
to
me,
because
I've
seen
that
work
sometimes,
but
having
a
few
ready
to
go
gold
sounds
good.
D
G
A
Both
of
these
gaps,
I
think
my
goal,
and-
and
this
is
the
other
one
for
certain
messages
binding
it's
it's
very
empty.
I
ran
as
you
used
towards
the
end
of
toward
the
the
end
of
last
week,
so
apologies
there,
but
on
both
of
these
I
I'm
really
wanting
to
I'm
really
wanting
to
keep
this
very
high
level
and
get
folks
talking
about
what
we
want
to
solve
provisionally
for
mesh
and
honest
honestly,
the
more
that
I
think
about
it.
A
I
think
that
I
think,
maybe
even
at
the
risk
of
you
know,
being
too
500
foot
view
that
we
don't
even
get
something
like
useful.
I
I
wonder
if
it
isn't
a
useful
conversation
to
discuss
kind
of
what
getting
gamma
getting
mesh
and
gateway
api
looks
like
from
a
like
from
a
gap
standpoint
down
like
are
there
stages
to
this
I
mean,
obviously
it
would
be
experimental
starting
off,
but
does
how
much
does
that
experimental
stage
buy
us
as
far
as
change
the
api?
A
F
Yeah,
I
just
it
seems
like
we
keep
going
in
the
direction
of
like
more
and
more
and
more
abstract,
like
okay,
we'll
solve
the.
What
are
we
trying
to
solve?
How
are
we
going
to
write
the
doc
like?
How
are
we
going
to
write
about
what
doctor
wright
and,
like
I'm
wondering,
is,
do
others
feel
the
same
way?
I
feel
like
we're
like
we
haven't
done
anything
in
these
past
few
weeks.
F
It
feels
like
we're
talking
about
talking
a
lot
more
than
actually
just
trying
to
solve
problems,
but
maybe
that's
just
just
my
opinion
here
and
we're.
We
need
this
structure
and
I'm
more
used
to
dealing
with
people
that
are,
you
know
from
like
my
own
peace,
to
a
project
that
have
kind
of
a
more
shared
context.
F
G
F
G
I've
contributed
to
the
problem
a
little
bit,
but
you
know
it
is
I'm
with
you
on
this.
It's
like
we,
we
it's
at
the
last
couple
meetings
and
I
mean
it's
taken
a
couple
weeks.
I
get
that
so,
like
you
say,
it's
been
a
couple
weeks
and
we
haven't
got
a
lot
done.
It's
really
been
like
two
days,
though
right,
two
one-hour
meetings.
So
it's
not
it's
more
about
the
time
being,
stretched
out
than
how
much
time
we've
actually
put
in.
G
Like
this
exercise
of
not
having
to
howl
up
front,
I
think
that's
going
to
end
up
being
a
really
positive
thing
that
gets
us
on
the
same
page
and
kind
of
starts
a
foundation
for
how
we're
going
to
build
figure
out
the
how
we're
also
running
low
on
time.
So
maybe
the
action
item
should
literally
just
be.
You
know,
stay
the
course.
G
A
A
I
think
we've
got
some
really
smart
folks
in
the
in
the
group
here,
and
I
don't
think
that
we're
going
to
make
too
many
decisions
at
this
point
that
won't
either
come
up
before
we
pull
the
final
lever
or
that
are
gonna,
be
completely
awful
and
that
we
hate
forever.
So
I'm
gonna
continue,
like
I'm
gonna
kind
of
take
that
advice
and
continue
to
push
on
the
dock
and
if
we
start
getting
bogged
down
too
much,
possibly
pivot.
A
But
I
I
I'm
also
conscious
of
not
wanting
folks
to
felt
the
only
time
we
can
have
conversation
is
during
the
these
gamma
meetings.
On
on
tuesdays,
when
we
first
started
the
exploration
dock,
it
was
a
small
group
of
people,
but
we
had
a
lot
a
lot,
a
lot
of
conversation
as
you
can
see
in
the
exploration
dock,
and
I
don't
want
the
extra
process
to
take
away
from
that
spirit
of
conversation,
collaboration
and
thinking
about
and
thinking
about,
the
problems
that
we're
trying
to
solve.
A
So
google
docs
seem
to
have
have
done
that
on
that
on
expiration
doc.
So
I'm
gonna,
I'm
gonna
kind
of
stick
with
that
for
now,
and
I
don't
want
to-
I
don't
want
to
create
start
getting
to
the
business
of
creating
too
many
deadlines,
but
I
do
believe
in
time
boxing.
So
I'm
going
to
tend
to
like
say
that
I'm
gonna
try
to
time
boxes
for
two
weeks
for
the
next
couple
of
meetings
and
so
well.
A
We
already
have
a
pretty
nice
time
box
here
august
22nd
for
our
kind
of
progress
report
to
the
api
meeting
and
I'd
like
to
have
a
some
pr's
for
provisional
gaps
in
by
then
so
I'm
going
to
commit
to
focusing
on
these
two
gaps
and
would
love
feedback
from
everybody
else.
But
I'm
going
to
if
there
are
no
strong
objections,
I'm
going
to
go
ahead
and
try
to
time
box,
submitting
or
obviously
creating
pr's
for
these
two
gaps
by
the
api
meeting
august
22nd.
A
All
right,
so
I
will
make
sure
to
try
to
get
that
down
the
meeting
notes
and
and
get
that
done.
I'm
also
we've
got
about
five
minutes
and
I
feel
kind
of
bad
for
taking
the
time
here,
but
I've
got
a
solution
for
that.
If
you've
got
something
you
want
to
talk
about,
I'm
going
to
talk
about
how
you
can
talk
about
that
wow
that's
complicated,
so
I
think
that
we've
had
a
lot
of
conversation
in
docs.
A
A
B
B
A
B
So
do
we
continue
to
think
that
it's
not
going
to
be
or
sorry
do?
We
continue
to
think
that
it
would
be
a
good
idea
for
me
to
go
through
and
distill
some
of
this
stuff
down
into
various
user
paths,
focusing
on
how,
before
next
time,
around
I'm
seeing
an
odd
from
mike
anybody
else.
Definitely
all
right
I'll
do
that.
A
Yeah,
I
think
the
parallel
work
streams
will
be
useful
because
I
think
once
we
get
scoping
down
and
everything
on
the
what
and
the
y
via
the
gets
will
already
have
some
nice
kind
of
work
being
done
on
the
how
path
to
where
we
can
say.
Okay,
so
that
that's
going
to
be
a
no.
Let's
focus
our
efforts
here.
So
I
think
that's
really
useful
to
work.