►
From YouTube: API Vision working group #1
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
to
the
api
vision,
working
group:
this
is
the
first
meeting,
the
kickoff
meet
him,
and
this
is
arturo.
I'm,
the
engineering
manager
of
the
ecosystem
integrations
team,
and
I'm
here
with
a
bunch
of
people
that
this
also
belongs
to
the
integrations
team,
and
the
reasons
for
this
group
is
that
we
are
responsible
of
the
api
and
because
it's
a
very
in
my
opinion,
is
very
close.
Cutting
concern
right.
A
lot
of
people
is
working
and
updating
the
api.
A
I
think
that
we
need
some
time
to
work
and
resolve
some
of
the
main
problems
that
we
we
found
with
the
with
the
apis,
especially
the
division,
how
how
to
deprecate
the
apis
at
the
long
term,
and
that's
the
reason
for
this
working
group.
We
will
discuss
later
like
or
review
the
topics
and
priorities,
and
we
already
have
the
handbook
page
and
a
slack
channel,
and
also
I
created
this-
a
working
group,
api
label
that
we
can
use
in
any
issue.
A
C
A
Yeah
so
my
idea,
my
my
idea
is
first,
I
mean
first,
is
the
frequency
my
idea
is
to
to
to
see
our
face
to
face
every
two
weeks.
This
is
the
first
time
that
I'm
running
a
working
group
I'm
participating
in
one.
A
So
any
feedback
is
welcome,
but
my
used
to
be
working
on
issues
or
have
discussion
in
initials
during
two
weeks
and
then
every
two
weeks
we
we
can
meet,
face
to
face
and
maybe
wrap
up
and
have
other
discussions
that
maybe
we
need,
but
my
main
point
is
to
be
inclusive
with
other
people
that
maybe
they
cannot
participate,
and
I
think
every
two
weeks
a
is
a
a
good
frequency
to
keep
track
of
things,
and
you
know
maybe
longer
is
like
we
just
forget,
or
we
are
like
doing
things
just
at
the
very
last
moment.
A
So
as
I
think
two
weeks
is
fine,
unless
someone
has
to
feedback
on
that.
So
if
a,
if
you
agree
with
that,
we
can
move
into
the
next
point.
B
I
might
I
might
vocalize
for
for
luke
as
well.
I
know
he.
He
left
a
note,
he's
he's
not
present
this
morning,
but
he's
suggested
that
yeah
it
could
be
a
challenge
and
this
might
not
be
as
inclusive
having
the
bi-weekly
meeting.
So
she
wanted
to
raise
that.
B
I
I
think
that
yeah,
that's
a
good
point,
but
I
do
see
a
lot
of
value
and
being
able
to
just
meet
every
couple
weeks
do
a
bit
of
a
check-in
and
make
sure
we
do
push
any
of
the
updates
out
into
issues
in
the
notes
making
sure
that's
public,
but
I
want
to
make
sure
that
his
his
comment
is
acknowledged.
I
think
that's
that's
fair.
Let's
make
sure
we're
making
making
this
as
inclusive
as
possible
as
async
as
possible,
and
arturo
you've
already
suggested
using
issues
as
heavily
as
we
can.
A
Cool
by
the
way
I'm
going
to
be
on
parental
live
in
april,
so
I'm
one
of
the
facilitators,
but
grant
is
the
other
one.
So
you
know
any
and
anything
that
you
need
just
go
after
us,
but
otherwise
you
know
everyone
can
help
in
any
other
way.
So,
even
though
we
have
our
roles,
it's
not
like.
Okay,
you
are
the
facilitator
and
a
member,
so
you
have
to
do
this
and
I
have
to
do
this.
A
A
I
was
writing
most
of
the
things
that
we
should
cover,
so
I'm
going
to
share
my
screen
just
to
have
this.
A
A
The
question
here
is:
there
is
any
priorities
or
anything
that
we
have
to
discuss.
First,
the
goals
in
general
is
we
need
to
define
the
responsibilities
of
the
api,
the
general
vision,
because
sometimes
it's
not
clear
like
if
this
dress
first
graphql
first
like
what
is
the
approach
that
we
have
to
take
for
that
we
can
use
and
define
user
personas
consumers
of
the
apis.
A
I
want
to
review
also
the
apis.
The
general
architecture,
permissions
and
coverage
performance
like
there
are
a
lot
of
things
here.
Testing
is
another
big
topic:
the
applications
and
the
life
cycle,
standards
and
documentation.
How
we
create
documentation
like
how
can
we
automate
the
creation
of
the
documentation
and
and
also
the
learning,
and
how
to
contribute
into
the
apis,
and
we
can
also
improve,
for
example,
creating
learning
paths,
deep,
dives
and
other
things
in
order
to
help
to
the
contributions
and
the
exit
criteria.
A
I
set
the
foundation
of
coexist
development
and
strategy
going
forward,
improve
the
api
or
capture
the
work,
because
I
think
that
maybe
we
are
not
able
to
resolve
all
the
issues,
but
at
least
we
can
keep
track.
What
is
important
so
clarify
the
life
cycle
of
the
api,
like
in
terms
of
the
applications,
what
we
have
to
do
in
terms
of
api
version,
5
graphql,
how
we
deprecate
fields,
improve
the
documentation,
creative
learning
paths
and
content
and
defined
levels
of
performance,
stability
and
appropriate
checks
and
monitoring
and
with
all
those
topics.
A
What
do
you
think
are
the
more
important
or
what
is
the
first
thing
that
we
have
to
start?
One
of
them
is
for
me
that
I
and
we
can
discuss
later,
like
15.0
release,
because
maybe
we
have
coming
the
applications,
but
apart
from
that,
we
can
take
this
in
in
any
way.
So
so,
if
you
see
that
there
is
one
topic
that
is
important,
which
we
have
to
discuss
first
just
say:
speak.
D
Victor
you
and
muted
yourself,
faster
than
I
did.
I
would
like
to.
E
Propose
something
that
we
can
communicate
outside
of
gitlab.
I
think
the
vision
is
a
bit
too
big
word
here,
but
maybe
it's
it's
related
to
the
vision,
without
that
it
won't
work.
But
the
idea
is
to
to
have
a
recommendation.
E
D
So
so
you
want
to
start
the
discussion
with
taps
versus
spaces,
basically
and
so
start
with
once
and
for
all
yeah.
I
think
that
that
that's
a
good
start.
I
think
my
basic
recommendation
for
working
groups,
and
especially
when
they
are
starting,
is
to
take
a
quick
look
on
one
hand,
is
there
anything
long
term,
something
that
will
take
longer
that
the
earlier
you
kick
it
off
and
the
longer
it
will
take
the
better?
D
D
Coming
to
that
and
making
it
as
actionable
as
possible,
so
that
everyone
we
we
have
a
forum
here
to
discuss
topics
and
that
might
be
even
an
option
to
do.
Is
this
not
bi-weekly,
especially
as
we
are
starting
discussion
and
kicking
off
topics,
it's
a
little
bit
finding
ourselves
as
a
working
group
and
and
where
we
are
targeting,
then
the
next
big
step
should
be
really
okay.
What
is
actual,
what
can
people
take
over?
D
They
take
as
a
task
and
come
back
basically
on
the
next
meeting
or
the
next
rhythm
that
we
can
add
to
the
the
board
and
really
work
towards
those
goals
that
we
are
setting,
but
they
are.
I
have
no
idea
right
now
and
I
think
that's
that
that's
really
the
the
most
complex,
but
also
to
some
extent,
the
most
interesting
aspect
at
the
beginning.
Any
comments
on
that.
Otherwise
I
will
simply
come
up
with
some
suggestions
based
on
some
recent
actions.
All
right.
C
One
of
the
things
that
I've
noticed
by
looking
at
the
agenda
is
that
there's
a
common
team
that
seems
to
be
underlying
a
lot
of
the
question
and
it
that
is
graphql
documentation
to
some
extent,
and
I
think,
by
unlocking
that
first,
there
are
a
lot
of
other
questions
which
we'll
get
answers
to
as
we
move
along,
and
so
you
know
like
even
thinking
of
like
the
rest
versus
graphql
and
what
to
recommend.
C
I
think
that
by
first
defining
better
practices
for
graphql,
we
will
see
the
real
shape
of
what
we
have
right
now
with
graphql,
which
will
unlock
future
decision
making
as
to
whether
or
not
what
to
recommend
and
how
to
work
with.
And
perhaps
if
we
get
the
better
state
of
documentation
and
we
understand
really
properly,
they
will
either
say.
C
Oh,
the
state
is
worse
than
we
thought
and
perhaps
then
the
recommendation
can
be
in
the
direction
and
then,
if
graphene
is
better
shaped
than
we
thought,
but
we
just
hadn't
documented
that
then
I
will
probably
unlock
some
other
course.
I
think
by
being
very
pragmatic
and
documentation.
First
then,
other
things
that
are
more
opinion
based
will
have
to
be
founded
onto
that
research.
I've
done.
B
I
might
add
to
that
point
I,
like
everything
you
have
to
say
frederic.
I
I've
had
this
thought
that
it
would
be
helpful
to
kind
of
see
from
a
data
perspective,
what
is
most
heavily
used
from
an
endpoint
perspective,
a
field
perspective
seeing
from
a
performance
perspective
like
where
we
have
the
the
most
issues
that
maybe
we
can
kind
of
break
down
and
prioritize
from
that
from
that
perspective
as
well,
because
then
we
can
see
like
if
we
can
see
across
you
know
a
couple
columns.
B
You
know
we
have
a
feature.
We
have
an
endpoint
in
graphql.
We
have
an
endpoint
in
rest.
Here's
the
performance,
here's
the
usage.
I
think
we
can
make
a
lot
of
decisions
and
prioritize
based
on
that.
I
don't
know
how
easy
or
challenging
that
is.
I
would
assume
more
on
the
challenging
side,
but
that
I
think
also
could
give
us
a
bit
of
a
basis
and
I
think,
similar
to
what
you're
saying
frederick
around
documentation.
It
could
lead
us
in
a
certain
direction.
D
D
So
we
had
a
bigcustomer.com
who
was
using
the
api
in
a
way
that
suddenly
a
change
that
was
to
some
extent
it
was
a
breaking
change,
but
not
as
obvious,
because
it
was
basically
changing
a
parameter,
how
it
was
able
to
use
it,
and
this
was
due
to
a
security
fix.
So
this
made
it
even
more
complex.
D
But
the
observability
that
to
see
who
is
using,
that
is
that
one
customer
using
90
of
the
bandwidth
of
this
endpoint
and
how
they
are
using
it
in
detail,
was
so
many
minimal
that
it
was
not
really
foreseeable
what
we
are
breaking
to
some
extent
with
the
change
and
which
is
another
topic
of
exactly
that.
Incident
is
good
if
you
how
to
do
future
processes.
D
When
you
have
such
a
breaking
change
that
you
need
to
do
against
api,
when
you
know
that
you
will
be
breaking
it
for
the
customer,
so,
but
I
think
observability
is
definitely
a
big
topic
that
we
have
a
clear
understanding
so
that
we
are
not
optimizing
for
something
that
only
we
use.
For
example,.
B
Yeah,
I
agree,
I
think,
that's
a
good
place
to
start.
I
guess
the
caveat
too
is
self-managed,
but
but
definitely
from
a
dot-com
perspective.
It's
a
tangible
place
to
start.
E
I
would
have
one
question
with
respect
to
that
again.
I
am
super
interested
in
how
we
can
support
our
users,
who
want
to
integrate
with
our
apis
instead
of
improving
performance
and
stability
of
existing
apis.
So
that's.
This
is
the
standard
I'm
speaking
about,
and
I
don't
see
at
how
will
observability
help
us
with
coming
up
with
the
recommendation
to
those
who
want
to
use
the
apis
and
want
to
build
things
around
those
apis.
C
Why
and
comparing
both
approach,
for
example
saying
well,
if
you
want
to
use
this
kind
of
data,
we
have
noticed
a
trend
that
rest
or
graphql,
whatever
is,
is
more
efficient
by
x
amount
of
percentage
like
you're
15
faster,
and
so
you
can
encourage
your
customer
by
the
performance.
I
think
that
would
be
one
of
many
other
criteria.
There's
easier
ease
of
integration
right
now,.
E
E
This
is,
this
is
that's
a
fair
point,
I'm
just
translating
it
to
the
generic
recommendation
terminology,
because
I
I
take
part
in
a
project
where
I'm
the
maintainer
of
the
gitlab
traffic
provider
and
right
now
we
are
blocked.
Actually
we
are
looking
into.
Shall
we
integrate
more
with
addressed
apr
or
shall
we
integrate
with
the
graphql
api?
And
we
don't
know
and
as
we
don't
know
where
there
is
some
gitlab
employee
as
well?
E
F
G
Yeah,
my
recommendation
would
be
to
look
at
the
various
problems
we
have
today
with
regard
to
api
and
and
start
to
tackle
the
bigger
problems,
or
at
least
the
most
painful
problems.
First,
and
I'm
not
still
sure
like
whether
you
know
we
will
have
graphql
taking
over
rest
or
if
that
ever
happened.
No,
we
have
certain
use
cases
they're
great
for
rest.
Api.
Certain
use
cases
are
great
for
for
graphql,
I'm
not
sure
like
whether
we
no
we
have.
G
We
can
make
a
decision
today
in
this
in
this
working
group,
but
I
think
we
can
tackle
a
lot
of
interesting
problems
like
feature
parity
documentation
or
cover
even
future
parody
from
the
point
of
view
of
observability.
G
Like
you
know,
we
might
have
good
observability
or
like
good
enough
with
rest
api,
but
not
with
drop
ql
and-
and
things
like
that,
so
I
think
we
could
probably
look
at
various
pain
points
from
the
customer
perspective
from
the
developer's
perspective
and
start
addressing
those
first
and
I
think
will
help
at
least
for
me
to
have
a
much
lower
narrower
scope
for
this
working
group
that
you
know
we
can
start
focusing
on
and
and
think
about
that
problem.
More.
G
More
tangible
kind
of
problem
to
solve,
and
then
we
can
start.
You
know
discussing
things
that
are
more
in
the
long
term
or
more
kind
of
strategic
for
the
long
term.
A
Yeah
I
I
see
that
this
is
going
to
be
a
big
topic,
so
for
for
me,
today
is
more
like
what
what
are
your
thoughts
in
general
and
what
what
we
will
discuss.
First,
you
know
and
then,
after
that
we
can
start
creating
issues
and
I'm
going
to
catch
up
with
grant
about
that
and
where
we
start
and
then
but
yeah.
A
But
I
see
that
that
is
going
to
be
one
of
the
first
topic
that
we
have
to
discuss,
because
we
only
have
four
minutes
left
and
I
want
to
talk
a
little
bit
about
the
15.0
release,
because
that
is
a
a
major
release.
So
maybe
we
have
some
some
things
to
discuss
about
that
one
or
a.
I
know
that
luke
already
posted
some
comments
here.
Grand
I'm
not
saying
if
you
want
to
not
sleep
verbally
so
makes
a
summary
about
those
points.
B
Yeah
I'll
do
my
best.
I
review
them
just
briefly
before
the
call
but
yeah
so
luke.
I
think,
had
two
two
kind
of
key
comments
here.
He
was
pointing
us
to
an
epic
that
we
already
have
around
improving
the
graphql
api
deprecation
process,
and
I
think
the
crux
of
this
is
is
that
we
should
be
planning
two
milestones
ahead
of
a
major
release
before
we
do
a
deprecation.
B
B
I
think,
as
a
kind
of
a
counterpoint
or
comment
to
that,
there's
also
a
discussion
ongoing
in
the
thread
here
around
create
a
oh
yeah
there's.
The
link
is
where
it
says
here
create
a
ecosystem
process
for
stewardship
of
graphql
deprecation
removals,
good
good
discussion,
good
thoughts
around
and
maybe
another
approach
is,
is
maybe
we
shouldn't
have
to
force
deprecations
or
removals
of
graphql
fields
where
there's
not
as
much
of
a
burden
on
us
to
maintain
it,
except
for
maybe
in
cases
where
there's
security
performance.
B
So
I
would
encourage
everyone
to
take
a
look
at
that.
You
know
share
your
thoughts
around
that
I'm
not
going
to
make
a
proposal
or
anything
here
just
want
to
verbalize
the
discussion
there
and
that
that
could
also
influence,
maybe
how
we're
looking
at
removals
for
15,
if
we
want
to
you,
know,
leave
some
of
these
fields
around
longer.
We
don't
see
security
or
performance
issues
if
we're
going
that
direction.
Maybe
we
want
to.
We
want
to
you
know.
B
I
think
there
were
a
few,
maybe
comments
down
further
along
and
maybe
I'll
verbalize
the
one
I
have,
and
I
see
one
from
tim,
so
I
had
a
question
here.
Everyone
can
just
respond.
We
don't
have
to
go
into
discussion
today,
but
I'm
trying
to
get
a
sense
of
if
we
do
have
tools
to
analyze
usage
of
graphql
fields,
specifically
those
of
the
deprecated
fields.
B
I
think
that
would
also
really
help
when
it
comes
to
looking
at
deprecations
if
everyone's
moved
off
there's
a
preference
for
another
field
that
maybe
that's
something
we
can
start
to
fully
remove.
If
we
know
there's
not
any
usage,
of
course
considering.
Maybe
where
self-managed
comes
into
play
there
and
I'll
see
one
more
comment
here
for
tim.
If
you
want
to
verbalize
that.
D
Yeah,
I
think
that
observability
is
key.
We
have
so
so
minimal
inside
how
it
is
used
and
and
what's
happening
and
how
many
customers
are
using.
I
think
that
that
would
be
really
helpful,
especially
the
graphql
area,
to
have
the
right
amount
of
data
to
answer
some
questions
at
a
later
point,
and
at
the
meantime
also,
as
I
said
really,
the
big
topic
is
that
we,
I
think
we
can't
make
straight
away
okay.
Next
week
we
are
making
a
decision,
graphql,
rest
drop,
everything,
delete
the
code,
etc.
D
That
is
not
what
we
are
most
probably
going
to
do
here
is,
but
we
can
dive
into
strategic
decisions.
We
can
take
a
look
at
okay.
What
are
the
possibilities
along
the
way
and
figure
out
basically
pros
and
cons
of
different
approaches,
and
I
think
that
is
also
very
much
goes
hand
in
hand
with
observability.
That
would
help
us
on
on
those
parts
to
have
a
better
understanding.
A
Okay,
so
yeah.
Thank
you
very
much
to
everyone
joining
the
working
group.
I
think
unless
someone
else
wants
to
say
anything,
I
think
that
was
a
our
kickoff
meeting.
So
what
I'm
going
to
do
is
I'm
going
to
try
to
create
maybe
a
couple
of
issues,
especially
specifically
for
this
cast.
For
example,
I
think
the
15.0
deprecations
and
probably
start
talking
about
you
know
like
address
api
and
graphql,
and
what
is
the
approach
and
we
can
keep
working
on
those
issues
discussing
things
and
and
yeah.
B
And
I
just
wanted
to
say
thanks
everyone
for
raising
some
very
good
questions.
I
know
we
don't
have
answers
in
one
day,
but
I
think
laying
them
all
out.
There
is
the
best
place
to
start.
So
if
you
didn't
get
a
chance
to
vocalize
or
make
note
of
some
of
your
concerns
or
priorities,
go
back
in
the
dock.
Add
those
you
know
and
start
participating
in
the
issues
and
yeah
really
appreciate
it.
Hopefully,
our
trooper
and
I
can
can
really
be
facilitators
of
this
of
discussion.
B
We
just
want
to
help
steer
it,
but
everyone
here
is
is
really
keeping
us
on
the
tracks
and
going
the
right
direction.
So
the
participation
is
key.
Yeah
thanks.
Everyone.