►
From YouTube: API Vision working group #4
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
everyone
again
to
the
api
vision,
working
group
and
I'm
going
to
start
sharing
my
screen
with
the
current
dashboard.
I
think
everything
is
public.
A
I
guess
so
it's
not
a
problem
to
serve,
but
basically
I
want
to
discuss
ideas
how
we
can
improve
our
current
board,
because
I
think
that
at
the
moment
is
not
completely
clear
like
this
is
the
current,
a
dashboard
that
we
have
and
for
me
it's
difficult
to
know.
What's
you
know
what
is
the
status
of
everything
like
you
know
like
it's
clear
who
is
working
on
what?
A
But,
apart
from
that,
we
cannot
see
the
progress,
so
I'm
thinking
that
maybe
we
can
introduce
some
workflow
labels
so
that
way,
maybe
we
can
iterate
of
a
four
different
states.
So
we
can.
We
can
use
any
workflows
that
we
want,
so
it
doesn't
need
to
map
exactly
one
by
one
with
what
we
use
for
a
engineering.
B
I'll
go
first,
if
no
one
else
wants
to.
I
I
mean
I
liked
your
ideas,
arturo
just
having
like
in
dev
and
and
review
workflow
review.
I
think
the
one
comment
on
that
is
in
development.
They
may
sound
specific,
maybe
there's
not
any
development
necessary.
Necessarily
it's
just
like
in
progress.
B
C
I
mean
why
can't
we
go
with
our
simple,
in-depth
and
in
review?
Yes,
in-depth
is
not
exactly
in
progress,
but
as
this
is
mostly
an
engineering
working
group
in
that
should
be
perfectly
fine
to
work
on
the
issue.
So
we
can
say
in-depth
is
in
progress
in
review,
probably
won't
be
useful,
but
we
can
finish
with
something
like
I
mean
when
issue
is
closed,
it's
also
reflected
in
the
board,
so
it
should
be
fine.
At
least
we
can
have
an
open
issue,
maybe
ready
for
development
when
it's
there
in
depth
and
closed.
A
Yeah
I'm
happy
to
go
with
that
way.
I
think
maybe
also
useful
could
be
blocked,
because
if
someone
is
blocked,
maybe
like
you
know,
something
is
ready
for
them
to
start
working
on
that
then
in
there
maybe
block,
and
then
it's
open
or
closed
right.
So
I
think
that
that
is
going
to
work.
Yeah.
A
Cool
okay,
so
yeah
I'm
going
to
modify
the
dashboard
later
and
see
how
it
works
cool.
So
next
point
is
sarah.
D
Hey
thanks,
satoru,
okay
folks,
you
probably
have
seen
me
posting
in
the
working
group
slack
channel,
but
thanks
so
much
for
all
the
feedback
already
on
the
work.
We're
doing
we're,
starting
to
kind
of
get
some
headway
into
drafting
some
api
terms
of
service
to
deal
really
with
the
kind
of
gaps
that
we're
seeing
that
there's
some
developers
who
aren't
actually
captured
by
any
of
our
other
agreements.
So
there's
nothing
in
place,
saying
how
we
expect
them
to
behave
and
to
set
out
ownership
and
licensing
things
like
that.
D
But
as
part
of
that,
one
of
the
questions
we've
come
upon
at
the
moment
is
at
what
point.
We
start
collecting
personal
data
because
we
have
a
placeholder
for
privacy
within
those
terms,
and
we
just
couldn't
find
a
lot
of
clarity
around
when
we
start
collecting
things
like
ip
addresses.
If
they're,
you
know
just
send
a
connecting
via
api
key,
so
I
was
wondering
if
there's
any
kind
of
clarity
you
folks
might
be
able
to
give
to
me
to
kind
of
get
help
was
going
to
move
up
forward
with
this
blogger.
A
So
we
may
need
to
investigate
that,
and
I
think
probably
the
best
thing
is
like
you
have
a
specific
questions,
for
example
that
one
about
the
api,
but
maybe
you
have
any
other
question,
maybe
you
can
create
an
issue
and
then
we
continue
from
there.
I
think,
unless
someone
already
have
the
answer
to
that,
because
I
I
don't
have
the
answer
like
where
we
start
collecting.
For
example,
lately
I
like
or
you
know
when
that
happened
in
our
system.
E
D
D
Obviously,
during
the
course
of
the
analysis,
if
we
were
to
find
that
there
was
more
than
that
by
all
means,
obviously
do
let
us
know
because
right
now,
we've
kind
of
done
enough,
what
other
companies
are
doing
and
some
are
like
very
explicit
in
their
privacy
collection
and
detail
a
lot
of
different
types,
while
others
are
like
completely
quiet.
D
So
I
can't
understand
if
that
means
they're,
not
collecting
it
or
they're,
just
not
being
transparent,
possibly
the
latter,
but
obviously
we
want
to
make
sure
we're
being
as
transparent
as
we
can
as
well.
So
I
will
pop
in
that
request.
I
might
fall,
but
you
directly
on
that
arturo
just
to
make
sure
I'm
popping
it
into
the
right
place.
If
that's
okay,.
A
So
maybe
that's
we
have
to
investigate
for
how
long
in
kivana,
for
example,
other
systems
like
for
how
long
we
collect
that,
because
maybe
it
could
be
like
maybe
only
30
days
30
days,
but
I'm
not
sure
so,
yes
having
the
issue,
we
can
start
a.
You
know
like
giving
you
feedback
about
that.
That's
awesome
thanks.
D
Cool
well,
not
no
albert,
if
I
have
anything
else
I'll
pop
into
channel,
but
again
thanks
for
all
the
help
so
far,
especially
yeah
yeah
granted
arturo.
I
know
we've
been
throwing
a
lot
of
questions
at
you,
so
thanks
very
much
for
that
and
have
a
good
one
talk
to
you
later.
B
F
Sorry
I
just
would
like
to
pick
up
on
a
previous
topic.
I
see
arturo.
You
mentioned
the
clients
that
use
the
api
topic.
A
Yeah,
I
I
so
this
is
related
to
the
a
like
the
client
that
we
are
using
on
the
on
them
or
the
apis
that
you
were
working
on
collecting
like
some
of
the
headers
and
other
things
to
understand
what
are
the
main
clients
so
grant.
I
think,
created
a
an
epic
to
work
on
different
aspects
about
the
user,
personas
consumers
and
different
things,
and
I
think
that
what
we
can
do
is
create
an
issue
for
that
to
investigate
the
clients
and
maybe
honestly
we
have
to.
A
B
Yeah
and
thanks
arturo
for
putting
that
one
on
my
radar
yeah,
I
hadn't
hadn't
gone
through
these
points.
Just
yet
so
maybe
I'll
talk
through
those
and
share
updates
and
if
there's
any
discussion
we
had,
we
can
open
it
up.
So
we
had
the
issue,
define
api
user,
personas,
etc.
B
So
as
arturo
was
was
sharing,
I
promoted
that
to
an
epic.
I
broke
out
a
number
of
issues
underneath
that,
so
you
can
see
progress
where
you
know
the
api
user
survey
is
now
there.
It's
live
it's
on
our
docs
site.
We
have
50
responses
already.
So
that's
that
seems
like
a
pretty
great
start.
B
B
Based
on
that,
so
there's
the
issues
I
have
so
far,
and
that's
where
that
question
came
from
are
there
anything?
Are
there
any
other
issues
that
were
missing
under
that
epic?
That
I'm
not
thinking
of
and
arturo
pointed
that
one
out
so
yeah?
I
think
doing
an
investigation
on
the
clients
and
seeing
if
we
can
pick
up
that
issue
from
victor
that
that
would
be
great,
and
I
think
I
skipped
a
question
here.
Natalia,
do
you
want
to
verbalize
that.
C
B
B
The
one
thing
I
guess
I
would
suggest
is
to
include
there's
a
a
an
area
where
you
can
put
in
your
company
name.
So
if
you
select
certain
options
just
put
in
gitlab
that
way,
we
can
filter
out
those
responses
and
get
certain
data,
and
we
could
also
just
do
specific
analysis
around
internal
users
et
cetera,
so
we
can
segment.
However,
we
want,
I
think,
just
so
we'll
kind
of
key
it
off
of
the
company
name.
B
B
A
lot
of
a
lot
of
developers
are
kind
of
would
like
to
be
able
to
depend
on
something,
that's
consistent
and
automatic,
and
they
can
they
can
you
know
kind
of
create
tooling
around
that
another
interesting
highlight
so
far
on
the
question
I
know
everyone's
really
interested
in
is
consistency
between
rest
and
graphql
and
preference
between
the
two,
I'm
you
know
jury's
still
out.
I
want
to
keep
capturing
responses,
but
so
far
the
the
heaviest
responses
is
around
no
preference.
B
So
it
seems
like
these
are
developers
who
are
willing
to
go
and
use
rest
or
graphql,
and
then
the
next
priority
is
around
rest
around
40
of
responses.
So
far,
and
I
said
40
to
50
percent
no
preference,
because
I
was
also
kind
of
looking
at
segmenting
for
enterprise
only
and
and
then
comparing
to
like
more
broadly
and
so
with
the
inter
kind
of
like
filtering
on
more
enterprise
types
of
users,
no
preference
actually
increases
quite
a
bit
and
then
the
preference
for
rest,
I
think,
was
staying
around
the
same.
Around
40.
B
Okay,
moving
on
to
the
next
issue
that
I've
been
kind
of
tracking
is
around
global
api,
observability
and,
ultimately,
just
no
time
yet
to
focus
on
this.
On
my
end,
so
no
progress
yet
I
would
still
appreciate
any
engineering
counterpart
who
wants
to
raise
their
hand
and
and
help
drive
this
issue
or
epic.
B
What
I'm
thinking
about
doing
this
week
is
is
going
and
taking
a
look
at
the
graphql
blueprint
issues
and
pulling
in
those
that
are
relevant
here
and
also
defining
questions
that,
I
think,
will
help
us
to
to
drive.
I
think
we
were
talking
about
last
time.
If
we
just
had
a
list
of
dashboards,
we
need
that.
That
would
probably
be
a
good
place
to
start,
and
I
want
to
define
questions
that
we
want
to
answer
and
that
should
help
us
to
identify
what
dashboards
we
need.
A
Do
you
have
like
a
specific
priorities
within
the
epic,
because
I
I
guess
that
is
going
to
be
like
we
start
having
like
we
start
with
issues,
then
we
promote
those
issues
into
epics.
So
I
think
the
next
thing
is
to
identify
what
are
the
the
first
thing
that
we
want
to
achieve
for
each
epic
right,
because
otherwise
it's
like
everything.
If
there
is
no
priority,
everything
is
a
priority
right
so
or
maybe
not
priority,
but
some
order
right.
B
Do
you
so,
do
you
mean,
under
these
two
epic
cells,
referring
to
api
user
personas
or.
A
Both
and
in
general,
it's
like,
I
think
that,
maybe
for
maybe
for
you
and
me,
is
like
to
go
over
the
epics
and
try
to
see
what
is
the
the
order
and
clarify
what
is
the
order
with
the
group
right.
B
Right
yeah,
so
I
have
a
couple
of
thoughts
on
that
on
the
user.
Personas
epic,
I
feel
like
it's
pretty
well
ordered,
so
I
think,
there's
kind
of
two
two.
I
guess
streams
of
work
here.
One
is
the
survey,
so
I'm
collecting
the
data
and
we'll
then
analyze
that
and
share
that
back
and
then
I'm
going
to
continue
with
customer
interviews
and
I'll
probably
define
some
scope
to
that.
B
But
let's
say
we
want
to
have
15,
20
conversations
and
then
analyze
that
feedback
and
share
it
out
and
then
work
on
the
blueprints
and
personas.
So
I
think
that's
pretty
well
ordered
api
observability,
I'm
not
sure
yet.
I
think
like
I
said
I
want
to
kind
of
pull
in
the
issues
and
then
define
questions
and
try
to
order
it
there.
B
So
I'm
still
working
on
that,
but
I
think
more
broadly,
my
hope
is
to
get
get
some
of
the
data
and
feedback
from
those
conversations
and
from
the
survey
to
help
us
define
a
kind
of
a
prioritization
framework.
So
maybe
we
can
start
adding
some
labels
where
they're
priority
labels
or
something
else
that
are
based
on
some
agreed
logic.
A
A
A
Doesn't
look
like
okay,
so
yeah
so
have
a
nice
week
and
see
you
next
time.