►
From YouTube: API Vision working group #3
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
another
to
another
episode
of
the
api
vision
working
group.
A
So
I
have
the
first
thing
of
the
agenda
and
basically
is
that
to
see
that
we
have
several
leases
at
the
moment
and
we
have
this
board
that
you
can
see
all
the
issues
for
the
working
group,
and
I
I
see
that
at
the
moment
it's
a
bit
chaotic,
but
I
think,
as
we
progress,
we
can
start
splitting
issues
refining
then,
and
I
think
that
as
we
progress
with
the
group
early,
you
know
we
are
going
to
see
like
that.
You
know
like
we
are.
A
We
have
like
issues
more
specific
about
things
that
we
have
to
do,
but
at
the
moment
I
can
see
that
we
still
have
to
split
issues.
We
find
them-
and
maybe
it's
a
little
bit
chaotic
and
saying
that
I
think
that
what
we
can
do
is
say
continue
like
with
the
summary
of
the
all
the
issues
that
we
are
mainly
working
at
the
moment.
A
So
the
first
one
I
have
here
is
api's
tape
of
the
art
I'm
bringing
this
here
today,
because
I
think
we
have
no
updates
on
that
issue.
But
I
can
see
that
this
issue
is
going
to
give
us
a
lot
of
insights
in
into
other
issues,
because,
as
we
know
how
other
like
good
companies
are
doing
with
the
apis,
probably
we
are
going
to
get
ideas
and
more
information
about
what
we.
A
What
we
can
do
with
our
api
as
well
and
look
has
been
working
on
the
deprecations
of
the
graphql,
maybe
grant
you
can
summarize
a
little
bit.
B
B
My
do
my
best
here
yeah,
so
he
was
working
on
yeah,
creating
the
ecosystem
process
for
stewardship
of
graphql,
deprecation
removals
and
he's
stating
here
that
this
is
turning
into
more
of
a
self-service
deprecations
issue.
Template
update
some
future
developer,
docs
updates
and
hopefully
a
process
update
that
might
be
triage,
bot
driven
so
combined.
Hopefully,
this
will
help
us
to
kind
of
accomplish
what
that
issue
was
trying
to
do
with
with
a
little
bit
of
with
very
little
human
oversight.
B
The
other
issue
luke
mentioned
here
is
encourage
graphql
deprecations.
We
kept
around
and
definitely
were
possible,
so
we
were
having
some
discussions
about
maybe
low
overhead
around
maintaining
graphql
fields
that
aren't
being
used
like.
What
is
you
know
is
what
is
the
value
gained
and
deprecating
a
field
unless
there's
maybe
a
performance
or
security
issue
that
that
makes
it
a
priority?
B
So
he
mentioned
that
brett
raised
a
problem
here
that
I'll
need
to
go
check
out,
I'm
not
familiar
with,
but
we
were
asking.
We
wanted
to
ask
for
some
other
opinions
on
this,
so
I
think
luke
went
and
did
that
and
brett
raised
a
problem
of
cruft.
As
the
downside
to
the
proposal
luke
says,
I
tested
out
what
it
looks
like
if
we
move
each
deprecation
into
its
own
module.
In
many
cases,
it
leads
to
a
clean
self-contained
deprecation,
I'll
change.
The
proposal
to
be
for
only
deprecations
that
can
be
fully
self-contained.
B
C
Should
we
include
this
in
the
in
the
issue
about
at
least
link
this
together
with
the
deprecation
worker
that
we
are
doing
so
when
we
type
a
specific
endpoint
as
deprecated,
we
can
automatically
add
some
a
message
in
the
warning
header
to
the
client
and
we
can
even
change
the
documentation
to
you
know
to
let
client
know
that
there's
something
going
on
and-
and
you
might
want
to
change
this
endpoint
in
two
milestones
and
things
like
that.
D
C
C
Do
we
do
anything
else?
You
know
on
the
graphql
that
tells
the
users
this
is
actually
deprecated
like
in.
B
Well,
I
was
going
to
say
no,
we
don't,
but
actually
I
think
I
think
I've
seen
some
fields
listed
as
deprecated
under
graphql,
but
maybe
it's
the
removal
itself
like
when
when
it's
gonna
be
removed,
I
don't
know,
can
anyone
else
speak
to
that
one?
Are
you
familiar.
A
So
I
think
that
maybe
what
we
can
do
is
create
a
new
issue
about
what
you
are
saying
fabio
and
then
maybe
start
a
discussion
around
that,
because
I
know
that
we
there
is
one
issue
that
is
about
api
version
5..
A
But
apart
from
that,
we
don't
we
don't
have
like.
We
still
have
to
discuss
a
lot
of
things
about
the
the
apis
in
terms
of
deprecation
like
like
how
often
we
deprecate
something.
What
is
the
process
like?
Is
the
headers?
The
feathers
are
going
to
respond
with
that,
or
is
the
documentation
like
really
clear
about
that
that
employee
is
deprecated?
A
A
Luke
was
working
mainly
on
a
graphql
deprecations,
but
but
at
the
end
we
have
to
have
like
some
similarities
about.
If
we
deprecate
something
in
breast
api,
shall
we
deprecate
the
same
on
graphql
or
like
how
is
the
process
between
both
apis,
because
that
is
another
important
point
here
like
to
have
like
a
kind
of
similar
vision
between
the
whole
apis,
yeah
yeah.
B
Yeah
and
fabio
yeah,
you
did
you.
I
was
looking
for
that
issue
as
well,
and
you
got
to
it
before
I
did
so
yeah.
There
is
an
issue
there
in
it
in
the
proposal.
It
does
mention
both
rest
and
graphql,
so
I
I
think
that
covers
it,
but
if,
if
something's
missing,
I
think
we
should
carry
some
more
discussion
into
that
issue.
C
Yeah
yeah,
the
idea
is
to
you
know
as
we
deprecate
something
in
the
api.
It's
more
like.
We
see
that
holistically,
so
we
updated
the
documentation.
We
update
the
headers
and
we
have
a
process
to
mark
something,
that's
deprecated
and
actually
then
removing
the
code.
So
a
kind
of
a
holistic
process
that
can
apply
to
both
like
rest
and
graphics,.
A
Okay,
moving
on
apa
documentation,
a
andy.
E
Yeah,
I
I
assign
myself
to
an
issue
to
look
into
how
we
can
how
we
can
automate
the
rest
api
documentation,
yeah.
I
haven't
looked
into
that
too
much
yet,
but
I
yeah,
I
think
my
plan
is
to
try
to
come
up
with
iterations,
because
there's
already
a
lot
of
documentation
and
if
he,
if
we
introduce
automation
now
they
will
probably
break
all
this
documentation.
E
E
Yeah,
I
think
the
original
issue
already
had
some
comments
about
this
and
yeah.
I'm
not
sure
I
thought
about
this,
and
maybe
this
will
be
a
good
approach,
but
this
will
be
like
a
big
iteration.
This
will
basically
mean
to
move
off
the
documentation
to
some
open
api
thing
either
that
or
we
have
to
maintain
both
documentation's
our
own
and
the
open
fdi
one
yeah.
So
I'm
not
sure
about
this,
and
I'm
also
not
super
familiar
with
open
api
spec.
E
E
E
Well
then,
katie,
I
think
that's
the
next
one.
F
Yep,
just
an
update
from
the
style
guide
perspective,
because
I
think
in
the
last
update
axel
mentioned,
that
we'll
start
looking
at
the
api
style
guide
and
seeing
where
we
can
consolidate
improve,
do
fixes
there
and
maybe
make
it
a
little
bit
more
standardized.
But
we
haven't
also
not
much
progress
there
at
all.
Axel's
been
on
holiday
and
I'm
covering
his
group
work
for
him
at
the
moment.
So
we
haven't
been
able
to
get
going
with
that.
B
Cool,
I
have
the
next
next
point,
so
I've
been
working
on
the
issue
to
find
api
user,
personas
and
consumers
and
if
they
feel
like
we're,
making
pretty
good
progress
here,
I've
gotten
a
lot
of
good
feedback.
B
I
got
some
last
bits
of
feedback
end
of
week
last
week,
I'm
going
to
work
through
that
early
this
week
and
hopefully
get
an
mr
out
to
add
the
survey
to
an
info
box,
for
example,
to
our
api
docs
pages
directly,
so
maybe
top
level
I'm
open
to
how
this
looks
or
how
I
want
to
start
somewhere.
So
maybe
it'll
be
top
level
we
can
add
from
there.
B
But
once
the
current
survey
that's
running
in
the
banner
on
the
docs
site
ends,
it
should
be
ending,
at
least
by
the
end
of
this
month.
I
will
replace
that
that
banner,
so
this
is
just
a
way
to
get
it
out
there
and
start
getting
some
feedback
as
soon
as
we
can,
and
so
I
added
a
preview
link
there,
and
you
can
also
go
into
the
issue
to
see
see
more
on
that.
B
So
yeah
I'll
think
about
this.
So
I've
got
these
two
issues:
the
next
one
global
api
observability
as
well,
and
I
think
they're
both
data
feedback
sources,
for
I
think
I
hope,
will
inform
our
prioritization
for
the
rest
of
our
efforts.
So
so
for
one
you
know,
I
think,
if
we're
hearing
a
lot
of
feedback
that
points
to
you
know
if
they're
saying
everything
looks
great
apis
are
great,
but
the
docs
just
need
a
lot
of
work,
for
example,
okay.
That
kind
of
that
tells
us
something
you
know
more
likely.
B
It's
gonna
be
a
little
more
complicated
than
that,
but,
but
hopefully
you
know
we
can.
We
can
kind
of
glean
what's
kind
of
top
of
mind
for
the
heaviest
users
of
our
of
our
api
docs
and
of
our
apis
between
survey
and
customer
interview
feedback,
and
we
can
start
to
really
narrow
in
and
prioritize.
So
that's
what
I'm
hoping
to
get
out
of
that.
Second,
the
second
item,
the
global
api
observability.
I
think
same
thing.
B
D
An
important
part
of
that
issue
was
also
defining
the
api
personas.
So
is
there
a
iteration.
E
B
Yeah
thanks
for
reminding
me
of
that,
we
we
are
hoping
to
better
understand
our
personas
as
well
yeah
and
so
there's
an
exit
criteria
or
criterion
in
our
working
group
to
update
our
personas.
If,
if
there's
a
need
so
that
might
be
refining
those
that
are
there,
it
could
be
adding
new
personas
if
we
feel
like
that's
necessary.
B
Okay,
I'll
move
to
the
next
one
global
api
observability.
Frankly,
just
no
updates.
Yet
here
I've
been
focused
on
the
survey
aspect
and
and
the
issue
above
but
yeah
I
was
thinking
what
could
be
helpful
is
to
see
if
there
are
any
other
volunteers
to
help
share
this
epic
they've
created.
B
I
did
have
we'll
talk
about
in
a
second,
I
met
with
gerja
gorge
and
had
a
coffee
chat
with
him,
and
we
know
that
there
are
some
issues
and
epics
out
there
around
the
graphql
blueprint.
So
there
might
be
some
issues
related
to
observability
that
that
we
can,
you
know,
run
with
those
that
already
exist
or
add
new
issues.
So
the
epic
itself,
I
think,
could
break
into
a
lot
of
issues,
and
I
would
like
to
see
any
other
volunteers
who'd
like
to
help
participate
in
that.
B
A
So
one
one
thing
that
maybe,
and
you
can
do
grant
is
because
at
the
moment
we
have
the
top
level
epic
and
then
we
have
another
epic
right
and
a
couple
of
issues.
So
I'm
not
sure
if
maybe
we
can
like
prioritize
the
issues
in
some
way
or
create.
Maybe
I
don't
know
exactly
what
you
need
at
the
moment,
but
maybe
make
something
more
specific
or
a
couple
of
issues,
and
then
you
know
even
to
jump
into
the
epic,
maybe
jump
into
a
smaller
reasons.
A
B
B
Yet
so,
once
I
get
a
better
understanding
of
the
lay
of
the
land
the
like,
where
things
are
right
now,
then
I
think
it's
going
to
be
easier
to
say:
okay,
here's
here's
some
of
the
gaps
that
we
can
start
focusing
on.
I
know
one
thing
that
comes
top
of
mind
is
just
making
sure
we
have
really
clear
dashboards
around
maybe
deprecated
graphql
fields
yeah.
I
thought
I
thought
that
would
be
valuable
to
be
able
to
see
or
making
decisions
around
deprecations.
B
But
that's,
I
think,
that's
an
assumption
about
what
isn't
most
important
right
now.
I
I
don't
have
the
full
the
full
picture
yet
so
that's
where
I
think
you
know.
I
think
this
would
probably
be
a
really
good
one
for
gorge.
I
thought
he
might
be
able
to
make
it
to
this
one.
So
maybe
he
could
help
or
point
me
into
someone
that
that
would
be
interested.
D
I
I
I
read
all
of
that.
I
think
I
think
that
the
key
thing
here
is
defining
what
we
want
those
dashboards
to
be,
and
I
think,
if
maybe
you'll
be
hoping
that
people
have
opinions
on
that
I'll,
try
and
contribute
myself
as
to
go
to
that
issue
and
and
list
out
or
add
some
issues
for
that
input
about
exactly
what
what
graffana
dashboards
we
need.
That
will
help
us
define,
obviously,
which
data
is
missing
in
the
logs
and
maybe
we
already
have
it
and
it's
going
to
start
building
things
up.
B
Awesome,
I'm
just
taking
a
note
down
on
that
yeah.
I
think
that
I
think
that
makes
sense.
I
think
that
might
be
essentially
what
we're
looking
for
is
what
dashboards
do
we
want?
There
could
be
more
to
it,
maybe
other
tooling,
to
to
make
it
easier
to
to
capture
that
data,
but
you
know
maybe
grafana
and
what
we
have
today
elasticsearch
right.
I
think
maybe
that
covers
all
of
our
use
cases.
E
B
A
Do
you
mean
the
graphql
blueprint
update
yeah?
So
apparently
we
have
this
a
graphql
api
blueprint,
an
effort
but
and
actually,
if
like,
they
are
like
actively
working
on
that.
So
one
idea
that
we
have
is
that
maybe
because
we
are
working
with
the
api
vision,
we
can
like
trying
to
bring
that
into
this
group
and
grand
and
gregor
they
have
a
coffee
chat,
and
there
is
an
update
from
honest
luck
about
that,
but
yeah.
A
B
B
Some
attempt
to
you
know
work
on
some
issues
after
the
blueprint
was
drafted
and
then
I
think
there
were
things
like
rapid
actions
and
engineering
allocations
and
and
all
these
other
things
that
that
probably
pulled
people
off
of
this.
Unfortunately,
but
he
he
seems
he
so
we
kind
of
covered
that
yeah,
the
api
vision
working
group
yeah.
B
What
we're
what
we're
looking
at
the
scope
of
our
effort
is
broader
than
just
graphql,
so
we
want
to
consider
you
know
rest
and
web
hooks
as
well,
and
he
seemed
to
be
absolutely
on
board
with
us
shaping
this
from
here,
using
the
graphql
blueprint
page
and
updating
that.
So,
if
we
wanted
to
have
you
know
an
api,
broader
api
vision,
blueprint
and
then
maybe
graphql
is
a
sub
page
under
that,
so
we
can.
We
can
shape
that
as
we
want.
We
can
shape
the
issues
as
we
want
he's
a
part
of
the
group.
B
He
can
participate
as
well
and
and
likely
will
be
so
so
I
think
we
can.
We
can
start
to
take,
take
that
and
and
and
those
who
are
participating
and
and
start
contributing
as
much
as
we
can
to
that
so
bill.
I
think
what
I'm
looking
at
is
build
on
top
of
of
the
work
that
was
already
done,
just
that
it's
a
bit
broader
scope
than
just
graphql.
B
So
yeah,
if
anyone's
working
in
a
particular,
you
know
category
of
the
api
vision.
You
might
look
at
those
look
at
the
epic
there
and
see
if
there
are
issues
that
are
relevant
or
look
at
the
graphql
blueprint
and
see
be
thinking
about
how
we
might
make
changes
there
as
well.
A
Okay
and
and
the
last
point
that
we
are
like
almost
on
time,
so
if
you
have
any
idea
how
we
can
organize
this
better,
you
know,
I'm,
you
know
happy
to
hear
any
feedback.
Any
ideas
you
have,
so
you
can
speak
now
or
asynchronously
or
leave
a
note
or,
like
so
yeah
anything
that
we
can
do
to
improve
the
group.
I'm
really
happy
to
to
make
any
changes
and.
A
Okay,
yeah,
so
I
think
that's
it
so
we
we
will
continue.
Working,
asynchronously
and
yeah.
Have
a
good
week
see
you.