►
From YouTube: API Vision Working Group #6
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
Cool
all
right:
well,
we'll
kick
things
off
today.
Arturo
is
now
on
parental
leave,
so
I'll
be
continuing
on
as
facilitator.
A
And
I
know
we
had
a
bit
of
an
issue
with
the
meeting
link.
So
if
everyone
comes
to
view
the
video
after
the
fact,
we
should
have
an
updated
meeting
link
now
we'll
make
sure
that's
working
moving
forward.
A
What
I
wanted
to
cover
first
today
is:
I
wanted
to
go
over
the
results
from
our
api
user
survey.
I
shared
this
in
our
working
group,
chat
or
channel
in
slack
and
really
just
wanted
to
have
more
of
a
discussion
versus
just
presenting.
A
So
what
I
want
to
do
is
just
kind
of
go
through
some
of
the
takeaway
slides
and
then
we
can
go
from
there.
I
can
drill
down
into
any
particular
any
particular
slide
or
question
that
was
asked
and
we
can
have
some
more
discussion
there,
so
the
first
finding
from
the
survey
is,
I
think
that
we're
doing
a
really
great
job
overall,
where
git
lab
as
a
whole
has
been
doing
a
great
job
with
their
apis.
A
A
So
I
think
that's
great
to
acknowledge
that
I
know
there
are
areas
where
we
can
continue
to
improve,
but
I
want
to
make
sure
that
we
share
that
up
front.
A
The
next
kind
of
theme
that
I'm
seeing
in
the
the
responses
is
something
I
think
we
talked
about.
I
think
we
talked
about
all
these
things.
In
the
first
meeting
we
had.
I
was
just
kind
of
going
back
over
that
meeting
ahead
of
this
one
and
feature
parity
or
feature
completeness
is
a
is
a
top
theme
I
mean
being
able
to
as
a
customer
or
api
user
be
able
to
use
any
of
the
features
that
we
were
exposing
through
the
product
as
an
api
is,
is
definitely
critical
to
them.
A
We
have
a
lot
of
different
personas,
a
lot
of
different
types
of
users,
not
only
internal,
but
we
have
customers.
We
have
third
party
maintainers
and
we
have
tech
partners
who
are
building
integrations.
So
if
we
don't
expose
those
features,
it
slows
them
down
and
causes
a
lot
of,
I
think,
frustration.
A
So
I
think
that,
more
than
anything,
I
think
that
should
be
considered
as
a
priority
in
whatever
decisions
we're
making
moving
forward.
A
A
We've
had
some
customers
who
have
looked
at
how
they
might
be
able
to
parse
our
documentation
to
pull
out
the
actual
endpoints
and
and
do
things
a
bit
more
dynamically
that
way
the
most
heavily.
I
guess
used
tool
that
users
are
leveraging
when
working
with
their
apis
is
clis
cli
tools
and
sdks
they're,
the
top
two.
A
So
I
think
anything
that
we
do.
We
need
to
keep
keep
those
tools
in
mind,
keep
sdks
and
libraries
in
mind
and
and
if,
if
sdks
and
libraries
are
not,
if
they're
lagging
behind
dramatically,
then
that's
going
to
impact
our
users
as
well,
and
I
know
that
we've
had
some.
Some
users
express
concerns
around,
for
example,
using
graphql
through
cli,
and
some
of
the
usability
concerns
there.
A
I
think
another
kind
of
low-hanging
fruit
item
that
continues
to
come
up
and
we
can
look
at
some
of
the
charts
and
data
that
I
have.
But
this
seemed
to
be
one
of
the
more
common
responses
in
text
form
like
outside
of
the
data
everyone's
asking
for
an
open
api.
Spec,
that's
up
to
date,
and
I
think
that's
something-
that's
really
low-hanging
fruit
and
will
help
them
to
automate
using
our
docs.
A
And
my
last
key
finding
slide
is
that
rest
continues
to
dominate
I'll,
show
a
chart
here
in
just
a
second
for
this
one,
but
that
the
general
sentiment
has
been.
You
know
pick
an
api
and
stick
to
it.
However,
rest
is
just
seemed
to
be
more
common
for
those,
at
least
that
responded
to
the
survey
and
the
sentiment
I'm
getting
is
that
if
we
were
to
choose
graphql
first,
we
you
know
absolutely
can't
abandon
rest.
I
think
it's
still
heavily
used.
A
So
one
way
I
kind
of
looked
at
this
is
by
stacking
up
the
data
for
those
who
preferred
rest
or
had
no
preference
versus
those
who
prefer
graphql
and
added
up
to
no
preference
column,
and
so
my
takeaway
is
that
95
of
the
users
who
respond
to
the
survey
would
be
happy
if,
if
rest
was
feature
complete,
essentially
if
it
was
prioritized
while
42
would
be
happy
if
graphql
was
privatized-
and
I
will
share
the
slide
real
quick
on
this
one
and
we
can
go
into
any
of
these
deeper.
A
But
when
I
was
first
looking
at
the
data,
this
is
what
I
shared.
I
think
we
have
like
250
responses
early
on
on
the
left
and
it
seemed
to
be
pretty
split
between
preferring
rest
and
no
preference
and
then,
as
I
clean
the
data
up,
you
know
I
can
talk
about
the
methodology
and
some
of
the
decisions
I
made
there,
but
as
I
started
to
kind
of,
remove
and
filter
out
some
of
the
data
that
didn't
seem
as
trustworthy.
A
A
And
the
last
two
slides
I
wanted
to
touch
on
before
we
open
it
up
for
discussion.
What
I'm
seeing
is
next
steps
based
on
this
data
is
I'm
gonna
continue
having
you
know
more
individual
conversations,
direct
interview,
conversations
with
top
customers
and
users
over
apis.
A
I've
also
started
a
gap
analysis
which
I've
shared
somewhat
internally
to
our
team,
but
I
want
to
share
this
to
the
working
group
and
see
if
other
teams
can
start
contributing
to
our
gap.
Analysis,
and
I
think,
with
that
data
we
can
really
define
a
path
forward
for
more
api
first
and
our
rest
versus
graphql
strategy.
A
What
I'd
like
to
continue
to
do
from
there
is
also
prioritize
and
identify
what
issues
we
want
to
work
on.
First.
I
think
there
are
some
things
that
we
can
continue
to
to
work
on
in
the
meantime
that
are
low-hanging
fruit
that
we
know
we
want
to
to
start
on.
So
a
couple
of
those
are
the
stories
we
have
or
issues.
A
We
have
around
automating
documentation
and
tooling
working
on
the
open
api
spec,
and
I
think
we
can
start
doing
some
experimentation
around
how
we
might
deliver
a
rest
wrapper
for
our
graphql
endpoints
or
if
there
are
other
ways
to
look
at
that,
to
automate
delivering
both
rest
and
graphql
apis.
A
A
A
Are
there
opportunities
to
use
labels
to
start
surfacing
up
issues?
I
think
that
labels
may
not
be
used
every
time
we're
touching
the
apis,
so
it
could
help
to
start
to
see.
You
know
what
effort
has
has
been
involved
in
like
ongoing
work
with
our
apis
and
making
sure
that
we
can,
you
know
kind
of,
do
some
analysis
and
and
better
prioritize
based
on
labels
all
right
well
from
there
I'll
open
up
to
some
discussion,
and
if
you
want
me
to
you,
know,
share
more
on
any
particular
slide.
I
can
do
that
as
well.
B
Well,
first
of
all,
thanks
grant
for
presenting
that
that's
very
helpful.
So
do
you
have
a
particular
recommendation
about
how
to
manage
prioritization
of
the
effort
here
that
you
would
think
is
if
you
were
if
it
was.
If
it
was
your
call,
what
would
you
recommend.
A
Yeah,
I
mean,
I
think
some
of
the
items
that
I
mentioned
on
this
slide
are
where
I
feel
like
we
can.
We
can
start
there's
low
hanging
fruit
there.
I
think
we,
you
know,
we
definitely
need
to
get
a
better
understanding
of
where
our
major
gaps
are.
If
we
wanted
to
look
at
this
as
like
feature
parity,
where
are
we?
Where
do
we
have
features
in
the
galapa
product
that
aren't
exposed
at
all
in
an
api?
A
And
where
do
we
have?
You
know
endpoints
exposed
and
rest
versus
graphql?
I
think
we
can
make
some
decisions
based
on
that
we
can
start
to
see
which
features
are
most
highly
requested.
You
know
which
ones
are
causing
the
most
pain
points
and
start
to
close
up
gaps.
I
think
long
term
yeah.
I
guess
where
I
expect
to
see
this
going
is
you
know?
A
I
think
we've
learned
from
this
that
we
can't
do
away
with
rest,
but
at
the
same
time
it
doesn't
seem
like
it
would
be
very
palatable
and
get
lab
to
to
completely
go
rest
first,
and
it
might
be
a
challenge
technically
to
go
rest
first,
so
you
know,
I
think
that
we
need
to
find
a
way
and
experiment
with
how
we
can
support
rest
on
top
of
graphql.
How
can
we
automate
our
tooling
and
actually
get
serious
about
that,
so
that
may
at
least
give
us
a
direction
to
start
moving
forward?
A
You
know,
maybe
this
means
graphql
is
first
and
if
you,
if
you
want
to
be
a
modern
application
and
and
have
the
the
latest
and
greatest
this
quick,
you
know
we.
We
recommend
customers
to
use
that,
but
maybe
we
can
have
rest
supported
in
some
kind
of
policy
like
one
or
two
milestones
after
it's
exposed
in
graphql
or,
however,
we
want
to
define
policy
around
that.
It
also
depends
on
how.
B
Custom
and
handcrafted
we
wanted
each
endpoint
to
be
so
you
could,
I
could
easily
consider
imagine
a
rest
wrapper
over
graphql
that
was
able
to
automatically
generate
endpoints.
That
wouldn't
be
the
prettiest
end
points
in
the
world,
but
you
know
it
wouldn't
be
aesthetically
very
pleasant,
but
I'm
pretty
sure
you
could
create
a
a
uri
to
basically
do
any
field
down
down
a
path
through
the
graphical
tree
and
just
create
query
parameters
for
each
argument
that
you
needed.
B
I
I
can
imagine
that
working
I
mean
it
would
be,
it
might
be.
It
ended
up
being
somewhat
ugly,
but
I
think
it'll
be
functional.
You
might
and
we
could
expose
that
through
a
different
endpoint,
perhaps
to
now
api
v4
api,
v5,
potentially
right.
C
B
A
Yeah,
I
mean
it
definitely
seems
iterative.
It
seems
like
we
could
expose
a
feature
in
rest
that
doesn't
exist
there
today
and
get
feedback,
and
I
think
that's
that's
definitely
aligned
with
with
our
culture
and
yeah.
I
think
it
would
be
a
step
forward,
so
you
know
if
there's
a
way
to
define
that
an
issue
get
some
more
feedback
from
the
rest
of
the
team.
A
I
know
we,
we
have
a
pretty
lightweight
team
on
the
call
today,
so
I
definitely
want
to
extend
the
discussion
in
the
next
call,
but
I
think
that's
seems
like
a
really
logical
starting
point.
B
Oh
yeah,
the
other
thing
is
you
mentioned
at
the
beginning,
talking
about
cli
tools,
so
I
know
we've
recently
released
our
own
officially
supported
cli
tool.
Have
you
seen
any
pickup
in
that
in
usage
and
did
any
of
the
customers
mention
that
they're
aware
of
it.
A
No,
no
customers
mentioned
that
specifically
yeah.
That's
a
good
question
where's
that
slide
so
yeah.
So
this
is
the
slide
and,
and
it
helps
probably
to
go
through
each
of
these
slides.
I
shouldn't
want
to
take
up
the
entire
meeting
time
presenting,
but
I
think
one
thing
I
noted
on
this
is
that
it's
not
like
there
was
any
set
of
tools
here
that
was
just
minimal
like
you
know,
that
was
like
much
lower
than
the
others,
but
cli
stood
out.
Sdk
stood
out
as
the
top
used
tools
yeah.
C
Yeah,
thank
you
very
much
for
sharing
this
talking
about
the
sdks.
I
wonder
if
there
was
more
precise
feedback
on
that,
like
the
people
say
they
were
mostly
up
to
date,
or
I
think
you
mentioned
that
some
of
them
were
a
little
bit
behind
and
is
that
an
issue
or
something
we
should?
We
should
look
into
more.
A
A
One
thing
I
did
want
to
note
is:
I
feel
that
we've
got
a
lot
of
foundational
work
that
we
could
do
first
before
we
start
trying
to
also
maintain
sdks.
I
know
that
if
that
was
to
be
something
supported
by
the
integrations
team,
you
know
we're
already
spread
pretty
thin,
so
I
think
we'd
have
to
think
about
how
we
structure
support
for
an
sdk
yeah.
I
mean
I
have
spoken
to
a
number
of
maintainers
and
you
know
the
feedback.
Is
that
they're
really
interested
in
seeing
where
we're
headed
with
graphql
versus
rest?
A
A
You
know
from
the
users
of
the
sdk
and
they
have
to
pass
that
just
be
a
pass
through
to
us
to
say
we
need
this
endpoint
exposed
so
that
we
can
add
it,
and
and
for
some
that
are
depending
highly
on
rest,
and
that
means
that
if
it's
not
there,
then
they
can't
expose
that
feature
and
they're
they're
getting
a
lot
of
requests
coming
through
to
them.
C
Yeah
that
makes
sense
yeah
I
was.
I
was
wondering
if
it
would
make
sense
for
us
to
to
own
those
sdks
but
yeah.
I
guess
that
would
be
a
lot
of
work
on
top
and
there
makes
sense
to
do
the
other
steps
foundational
work
first,
but
maybe
we
can
find
some
some
things
we
can
support
them
more
like
have
like
kind
of
a
more
direct
channel.
C
They
can
ask
for
ask
questions,
or
I
know,
or
I
I
would
guess
it
would
be
hard
for
them
to
keep
the
sdks
up
to
date,
because
they
don't
get
a
notification.
When
the
api
has
a
new
endpoint
or
something
yeah.
Maybe
there
can
be
some
direct
channels,
but
yeah.
I
see
this
would
be
a
step
that
we
would
take
when
we
figured
out
the
other
things.
A
Yeah,
no,
I
think
that's
that's
a
great
point
and
I'm
not
absolutely
not
closed
off
to
the
idea.
I
think
I
think
we
need
to
ask
more
questions
around.
What's
involved
how
we
would
support
that
and
or
support
you
know
one
or
many
sdks
like
what
does
that
look
like,
but
I
like
the
idea
of
incrementally
just
trying
to
provide
better
pathways
better
channels.
I
also
think
that
you
know
if
we
are
closing
up
gaps
in
terms
of
feature
parity
and
automating.
B
I
think
I
think,
with
all
things,
to
be
very
cautious
about
just
the
mini
about
wanting
to
maintain
sdks,
because
you
end
up
with
with
having
multiple
sdks,
not
multiple
languages,
multiple
bindings,
you
need
to
maintain
focusing
I'm
glad.
You
mentioned
the
of
an
api
specification
because
that's
definitely
a
path
towards
a
single
source
of
truth
from
which
multiple
sdks
can
build
out
api
bindings.
That's
a
a
better
use
of
our
time
than
trying
to
quite
make
individual
contributions
to
the
go
lane
sdk
and
the
node,
the
ruby
one
and
so
forth.
A
Right
yeah,
it's
kind
of
it
becomes
quite
expansive
once
once
we
open
that
door
yeah,
I
you
know,
and
it
could
be,
that
we
we
start
with
just
one
sdk
as
a
as
a
primary
at
some
point
in
time,
but
yeah.
I
think
that
I
will
admit
I
don't
know
how
much
is
involved
to
support
an
sdk
at
this
point.
I'd
want
to
do
some
research
and,
and
try
to
to
you
know,
get
a
better
understanding
of
that
and
how
we
would
also
resource
to
support
it.
A
So
I
think
it
would
definitely
be
additional
a
lot
of
additional
effort
on
our
end.
B
I
can,
I
can
see,
there's
probably
some
logic
in
supporting
and
probably
also
dog
fooding
a
go,
laying
sdk,
especially
with
our
own
tools,
and
some
bits
of
that
are
hard
to
automatically
generate.
You'll
need
to
sort
of
do
lots
of
code
degeneration
so
stuff
like
enums
and
things.
So
anything
is
like
a
time.
Language
that'll
be
a
little
bit
harder.
So
that's
probably
if
we
did
focus
on
any
of
them.
A
Yeah,
no,
I
get
the
same
sense,
but
I
think
we
can.
We
can
get
a
more
objective
analysis
of
that,
and
I
also
like
the
idea
of
of
incrementally
moving
that
direction.
It
doesn't
have
to
be
all
or
nothing,
but
you
know
I
wonder
you
know:
how
much
are
we
contributing
today
to
to
the
go
sdk,
for
example?
A
Maybe
that's
something
we
could
just
start
doing
more
of
and
and
that
we
can
get
some
empathy
as
well
by
seeing
what
some
of
the
gaps
are
and
whether
we're
sole
maintainers
or
official
maintainers.
We
can
still
be
maybe
coming
up
with
a
way
to
contribute
more
and
get
more
of
a
sense
of
the
challenges.
B
One
idea
here
might
be,
for
example,
that
if
we
have
like
one
sdk,
one
or
two
that
we
want
to
encourage
like
golden,
for
example
right,
we
could
include
stuff
in
our
merge
request
templates
that
suggest,
if
you
have
changed
the
response,
schema
or
you've
added
it
added
a
new
field
or
added
an
end
point.
Have
you
considered
notifying
the
maintainer?
B
A
Cool
well,
I
know
we've
got
two
minutes
left,
maybe
I'll
just
for
our
other
items
here
just
wanted
to
remind
everyone
to
share
some
status
updates.
I
know
we've
got
a
number
of
open
issues
in
our
boards
and
I
know
like
they're
working
through
various
stages.
So
I
see
that
there's
there's
work
being
done.
That's
that's
awesome.
Maybe
we
could
kind
of
share
an
update
of
if
there
are
any
blockers
or
anything,
any
challenges
that
we
need
to
help
move
things
forward.
We
can
surface
those
up
and
and
communicate
async.
A
All
right
with
that,
we
can
end
today
and
let's
continue
this
discussion
a
little
bit
more
in
the
next
meeting,
I'll
make
sure
that
everyone
is
aware
of
these
slides
and
has
a
chance
to
to
go
through
them
and
we'll
have
one
more
discussion
on
this
next
time,
but
yeah
thanks.
Everyone
appreciate
it.
Thank.