►
From YouTube: API Vision working group #2
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
Okay,
so
welcome
again
to
the
a
api
working
group.
So
after
the
last
meeting
I
created
some
issues
with
our
discussion.
I
mean
the
first
meeting
was
more
like
kickoff
and
I
think
what
we
can
do
is
like
a
for
the
meetings.
Maybe
we
can
work
mainly
on
the
on
days
on
the
issues
asynchronously
and
then,
when
we
are
together
in
the
meeting,
maybe
we
can
catch
up
and
make
a
brief
summary
to
their
team
members,
as
I
think
we
can
go
over
all
the
issues.
A
So
at
the
moment
we
mainly
have
four
things.
So
the
first
one
is
improve
the
graphql
api
deprecation
process.
A
So
I'm
not
sure
if
maybe
luke
was
working
on
this,
but
he's
working
as
synchronously,
so
maybe
marcus
or
alex
can
update
into
this
one.
If
not,
maybe
we
can
move
to
the
next
one.
But
if
you
know
anything
about
this,
what
is
the
status
of
this
and
what
is
the
progress.
B
I
commented
on
the
first
issue
that
look
luke
looked
into
and
he
proposed
using
the
deprecation
issue:
template
for
api
deprecation,
so
especially
graphql
applications
and
extending
it
with
a
few
steps.
Just
so,
the
process
is
clear
like
when
we
need
to
announce
the
applications
and
there's
also
like
application
entries
for
the
release
post,
that
we
can
create
in
advance
and
yeah.
C
Yeah
and
the
the
other
one
is
about
enco,
considering
whether
we
would
have
a
longer
deprecations
process
for
graphql.
This
is
particularly
important
because,
of
course,
if
you
have
graphql
queries
are
typed,
so
they
you'll
get
different
kinds
of
failures:
failures.
If
a
user
uses
a
deprecated
field
or
a
query
parameter
in
for
a
rest
api,
if
you
pass
an
ignored,
query
parameter
or
you
expect
a
field
that
is
not
provided
that
you,
it
can
be
ignored.
C
That
will
fail
in
a
more
breaking
change
way
for
the
client
and
graphql.
So
there's
a
consideration
of
whether
we
keep
stuff
around
for
longer
and
graphql
part
in
order
to
minimize
breaking
changes
for
downstream
clients.
A
Okay,
so
so
we
are
working
on
that
and
maybe
we
still
have
to
work
before
a
15.0
right,
because
maybe
we
have
a
a
as
is
a
major
release.
Maybe
we
need
to
do
something
before
that
right.
C
The
only
thing
well,
it
depends
what
we
do.
If
we
get
lots
of
buy-in
right
now
I
mean
we
could
possibly
hold
off
removing
some
of
our
deprecated
deprecations.
C
It
might
just
be
a
case
of
making
a
decision
now
for
the
next
cycle,
saying
from
now
on,
we
will
keep
deprecations
around
for
longer.
There
would
be
it.
I
think
it's
basically
just
about
making
a
policy
decision.
It
wouldn't
be
about
making
large
changes
if
anything
would
be
about
sort
of
avoiding
making
changes
that
we
would
otherwise
have
made.
D
C
Doing
nothing
in
this
case
is
the
safest
option,
because,
because
this
is
the
removal
of
these
deprecated
elements
that
causes
the
breakage
so.
D
And
I
guess
I'm
curious
if
there's
any
objection
for
any
on
the
call
and
going
that
route.
While
we
keep
having
some
more
discussion
and
coming
up
with
some
conclusions.
C
Not
on
the
call-
but
I
know
brett
walker
on
the
issue
commented
just
to
advocate
in
that
we
should
be
removing
technical
debt
where
possible.
But
there
is
a
you
know,
good
argument
for
that
on
some
cases
we
might
have
to
consider
things
on
a
case-by-case
basis,
but
I
mean
I
mean
I
I
sent
him.
I
I
want
to
propose
this.
I
I
would
be
an
advocate
of
keeping
stuff
around
as
long
as
it's
not
causing
other
problems
right.
You
know
all
other
things
being
equal.
Of
course,.
D
Cool
yeah,
maybe
we
can
try
to
promote
this
question
and
get
feedback
from
those
who
might
be
advocating
for
the
other,
the
other
side
and
and
and
take
the
discussion
there,
but
yeah,
but
maybe
there's
some
use
cases
where
we
we
say:
let's
go
ahead
and
move
forward
with
it
and
then
for
everything
else.
Let's,
let's
hold
off
and
and
kind
of
flesh
this
out
a
bit
more.
C
A
Okay,
moving
on.
E
Yeah,
so
cutting
culture
is
actually
the
current
status
perfectly
in
here
comments,
as
you
can
see,
I
have
a
link
to
it.
So
it's
pretty
not
pretty
it's
a
pretty
consistent
right.
Now
we
don't,
and
actually
this
is
because
you
know
it's
a
manual
process
and
we
have
many
older
endpoints
that
haven't
been
updated
for
you
know,
since
they
got
released,
let's
say
the
documentation
state
as
is
and
the
time
they
were
released.
E
E
A
Okay,
next
one
is,
we
are
kind
of
defining
what
are
these
the
users
of
the
api,
different
consumers
personas
or
like
tooling?
Maybe
your
grant
can
update
on
on
this
one.
D
Yeah
sure
so
the
focus
I've
had
has
been
on
the
survey
and
thinking
about
setting
up
customer
interviews,
so
I've
gotten
access
to
qualtrics
and
I've
put
together
a
skeleton
survey
just
based
on
some
of
the
feedback
we've
gotten
in
the
issue.
Some
of
the
questions
you
would
raise
victor
and
I
wanted
to
expand
on
that.
Consider
any
other
questions
we
wanted
to
include
and
see
how
to
get
that
embedded
into
our
documentation,
so
just
just
kind
of
getting
started
on
that,
but
open
to
other
thoughts
and
questions
that
we
might
want
to
ask.
D
I
know
we
don't
want
to
get
it
to
be.
We
don't
want
it
to
be
too
lengthy
and
we
can
follow
up
in
in
calls
with
with
customers
who
are
interested.
I
think
similar
to
this
issue.
I
mentioned
our
that
updated
our
handbook
page
to
include
additional
exit
criteria
for
updating
our
personas.
D
So
there's
some
discussion
and
another
issue
I'll
link
to
there
talking
about
enterprise
personas
that
are,
you
know,
using
our
apis,
trying
to
understand
those
personas.
So
I
think,
throughout
this
process,
if
we
get
clarity
on
particular
personas
that
are
users
of
our
apis,
we
can
flesh
those
out
and
update,
update
our
documentation
to
account
for
those
and,
let's
see,
yeah
and
then
the
last
note.
D
I
haven't
made
too
much
progress
on
this
in
yet,
but
I'd
like
to
start
identifying
customers
to
reach
out
to
that,
are
you
know
large
customers
using
our
apis
and
and
go
that
route?
You
know
so
one
one
angle
is
getting
survey
feedback
and
the
other
is
kind
of
using
information.
We
already
have
identifying
our
existing
customers
that
we
know
are
using
apis
larger
enterprise
customers,
especially
and
starting
to
schedule.
Some
calls
with
with
those
teams.
D
So
you
know
I
shared
a
link
to
that
survey.
If
there's
something
that
you
think
would
be
valuable
to
capture
in
in
that
survey,
you
know,
let
me
know
I
don't
think,
there's
anything
specific
otherwise
at
this
time,
but
I'll
definitely
ping
everyone.
If
I
think
of
something.
B
Marcos,
you
added
something
there
yeah.
I
just
said
the
point
that
we
have
some
large
open
source
instances
like
debian
and
gnome,
for
example,
and
they
could
be
interesting
too,
because
they
probably
have
a
lot
of
tooling
that
they've
built
themselves
because
they
usually
don't
use
enterprise
licenses,
even
though
they
could
get
one
for
free.
F
D
Yeah,
I
think
that's
useful-
I
mean
we
could.
We
could
also
capture
you
know,
capture
like
links
to
the
salesforce
accounts
or
links
and
drop
them
in
that
issue.
D
That
could
also
help
I'm
hope,
I'm
open
with
both
but
I'll
try
to
document
them
somewhere
that
we
can
all
discover
that
the
list
and
and
feedback
I'll
probably
will
once
I
get
going,
start
capturing
the
feedback
in
dovetail
and
make
that
accessible,
yeah
I
haven't
haven't
set
the
the
framework
up
for
myself
yet,
but
yeah
feel
free
to
do
slack
or
drop
a
salesforce
link
into
that
issue.
F
Yeah,
I
will
stay
away
from
the
stairs
constantly
because
it's
hard
to
find.
Sometimes,
on
the
other
hand,
I
can
really
even
now
I
have
a
few
enterprise
contacts
who
who
are
pretty
heavy
users
great,
so
just
that's
anyone
that
can
connect
you
with
them.
D
Yeah,
so
on
this
one
I
haven't
haven't
made
too
much
progress
on
my
end,
I
think
that
you
know
the
last
material
thing.
That's
coming
to
mind
at
least
right
now
is
the
conversation
in
slack.
Luke
and
paul
were
sharing
some
some
resources
there
for
what
we
already
have-
and
I
still
I
haven't,
had
a
chance
to
go
in
too
deep
on
that
so
yeah.
I
think
if
we
can
keep
organizing
issues
into
that
epic,
that
that
will
help
and
start
to
get
a
sense.
D
I
think
some
teams
are
aware
of
of
different
dashboards
or
different
tools
that
maybe
not
everyone's
familiar
with
one
thought
is,
it
could
be.
It
could
be
great
to
also
get
a
page,
like
maybe
a
handbook
page
or
some
documentation
that
really
kind
of
captures
how
to
how
to
go
and
and
get
get
data
about
our
apis
for
our
internal
teams.
D
So
I
think
if
we
just
keep
organizing
them
there,
I
know
on
my
end,
I'm
gonna
dig
a
bit
deeper
and
try
to
see
what
seems
to
be
most
important
for
us,
and
one
thing
that
comes
to
mind
is
tied
back
to
deprecations.
I
think
we
already
have
some
things
there
that
can
help
us
to
see
how
heavily
some
of
these
fields
are
being
used.
So
if
we
are
seeing
that
certain
fields
are
dropping
entirely
in
usage,
maybe
we
can
start
to
remove
those
as
a
priority
versus
you
know.
A
Okay,
yeah:
let's
move
to
the
next
point,
I
think
that's
for
me
how
I
picture
this
is
like
to
have
like,
as
I
say,
like
catch
ups
here
in
the
call
and
then
work
asynchronously
so
and
related
to
that
a
I
mean.
Last
after
the
previous
meeting,
I
created
some
issues
and
assigned
people,
but
there
is
still
a
lot
of
people
that
they
don't
have
any
assignment
issues
at
the
moment.
A
So
so
I
think
for
those
people
here
in
the
call.
I
think
that
you
can
maybe
assign
to
the
issues
that
you
you
find,
that
is,
they
are
more
interesting
for
you
to
work
or
you
can
leave
feedback
on
any
issue
or,
if
create,
even
create
new
issues.
A
If
you
think
that
we
are
missing
important
things
and
yeah,
and
if
anyone
now
has
a
you
know
better
ideas
to
organize
this
group
or
the
work
happy
to
hear
that
here
or
a
honest
luck
or
in
any
way,
you
know
so
yeah
so
feel
free
to
to
give
us
feedback
about
what
is
the
best
way
to
organize
the
world.
A
D
This
isn't
fully
fleshed
out,
but
one
one
thing
I
was
thinking
about
this
morning
is
how
we
might
be
able
to
start
using
labels
like
we
do
with
our
own
projects
and
things
to
like
come
up
with
some
rationale
for
how
we
want
to
prioritize
and
then
start
using
like
priority
labels,
for
example,
if
we
think
something's
higher
impact
based
on
rules.
We're
defining
in
this
call
that
might
help
us
kind
of
service
a
few
issues
to
the
top
and
get
a
little
more
clarity
around.
What's
most
important.
A
You
know
at
the
end
is
like
in
some
way
like
a
responsibility
to
to
make
this
happen
or
make
progress,
so
it
doesn't
have
to
make
progress
every
single
week,
but
I
mean
after
some
time
you
know
we
can
see
some
progress
on
the
issues
or
if
it
is
blocked
shared
here,
and
maybe
other
people
can
jump
and
help
into
that.
A
A
So
the
next
point
that
I
have
here
is
like
we
are
talking
about
a
lot
of
things
that
we
can
do
on
our
api,
but
I
know
if
we
are
missing
an
issue
that
is
like
investigate
what
is
the
api,
like
kind
of
the
state
of
the
art
or
what
is
doing
other
big
players
in
the
industry,
or
maybe
we
already
have
that
information?
A
I
don't
know,
but
if
you
think
that
that
could
be
worth
to
investigate
or
to
have
more
people
like
in
one
issue
with
all
the
information
together,
we
can
create
that
issue
and
work
on
that.
Oh,
it's
not
I'm
not
sure,
I'm
just
asking
about
that.
C
I
think
I
think
it's
a
really
good
idea,
knowing
how
we
stack
up
against
other
people
and
what
they're
doing
so.
Yes,
having
somebody
who
understands
that
and
having
their
one
place
sounds
like
a
really
good
plan.
G
Yeah,
I
agree
it's,
I
think
what
would
be
also
nice
to
have
like
a
list
of
things
or
other
applications
that
you
have
an
api
and
how
they
use
it
and
yeah.
For
example,
I'm
thinking
about
stripe
has
a
very
nice
api
documentation.
They
have
like
code
snippets
and
yeah.
Maybe
we
can
like
yeah,
have
different
categories
like
graphql.
A
Okay,
is
anyone
interesting
to
work
on
that
that
maybe
people
that
they
don't
have
at
the
moment
any
issue
assigned
or
I
can
create
the
issue
and
then
we
can
decide
later.
C
I
think
there's
also
a
good
kind
of
being
split
up.
It'd,
be
a
good
idea
to
identify
services
or
endpoints
that
we'd
that
we'd
like
to
investigate
and
have,
and
rather
than
have
one
person
try
and
collect
all
that
information,
which
sounds
overwhelming,
try
and
get
individuals
to
do
a
survey
and
report
back
on
stripe
or
something
else.
And
what
have
you
and
then
try
and
summarize
that
together,
because
that
I
think
is
probably
too
much
for
one
person.
A
Yeah
and
I'm
I'm
also
trying
to
like
assign
issues
to
always
to
different
people
like
more
than
one
so
in
some
way,
you
know,
like
is
kind
of
a
certain
responsibility,
but
also
like
it's
not
just
only
can
be.
Some
misses
can
be
very
overwhelming
for
people.
So
if
you
see
that
something
is
very
big,
it's
a
start
to
like
split
splitting
the
aces
into
smaller
ones.
So
we
can
make
a
good
progress.
C
There
was
one
thing
that
occurs
to
me:
is
that
there's
some
important
overlap
there
between
that
and
what
grant
was
talking
about
with
talking
to
the
heaviest
api
users?
It's
also
good
to
know
for
the
people
who
use
our
api,
what
are
other
apis
that
they
use
and
how
do
they
use
those,
because
that
kind
of
that
suite
of
tools
is
also
an
interesting
consideration.
You
know:
are
we
doing
the
same
thing
in
the
same
way
as
the
other
people
that
they
interact
with.
A
Okay,
we
have
a
three
minutes
minutes
left,
so
if
a
anyone
else
wants
to
commence
a
any
of
any
any
other
topic,
we
still
have
a
three
minutes.
A
Cool
okay,
so
yeah
so
have
a
great
week
and
yeah
see
you
see
you
next
time.
Thank
you
very
much.