►
From YouTube: GraphQL Working Group - October 1, 2020
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
Hey
how's
it
going
hey,
it's
going
well,
how's
it
going
with
you
pretty
good.
I
was
just.
I
was
just
reading
through
the
update
on
that
pr,
thanks
for
all
the
work
you
put
into
that.
That
is
an
incredibly
like
comprehensive
response,
really
appreciate
it.
I
I
haven't
digested
it
all
yet,
but
I've
got
some
time
later
today.
To
reread
it.
B
A
E
F
F
B
F
F
F
F
F
F
So,
let's
get
going
welcome
everybody
thanks
for
joining
we've
got
a
pretty
nice
agenda,
actually
relatively
tight.
So
that's
great!
It
means
we
should
be
able
to
spend
some
good
time
on
each
of
the
things
that
we
have
up
I'll
go
over
the
agenda
overall
in
a
moment,
but
at
the
top
first
a
reminder
that
by
all
of
us
attending
we
all
agree
to
the
membership
agreement.
Participation,
guidelines
and
code
of
conduct
should
be
well
known
by
everybody.
Here.
F
I
think
you
don't
have
too
many
folks
who
haven't
heard
that
before,
but
just
in
case
there's
links
in
the
agenda.
If
you
want
to
go
look
at
those
and
then,
as
per
usual,
usually
go
around
and
introduce
ourselves
and
we
can
use
the
order
that
is
listed
in
the
agenda.
F
And
if
you
don't
see
yourself
there,
then
please
just
send
the
pull
request.
So
we
have
a
good
record
of
who
is
here
and
I'm
off
the
top
so
introduce
myself.
First,
hey
everybody!
My
name
is
lee.
B
On
to
you,
benji,
hey
sorry,
I
was
editing
the
notes,
hey
everyone,
I'm
benji,
I'm
part
of
the.
I
work
on
the
graphile
projects
and
I'm
working
on
the
tagged
type
rfc.
G
H
Yeah,
I'm
here
hey,
this
is
antoine.
I
work
netflix
and
doing
some
refill
and
federation
stuff.
I
A
Yeah,
sorry
about
that,
I
had
to
step
away
for
a
second
dan
schafer
and
shape.
J
Hey
this
is
raphael.
I'm.
H
J
On
the
changing
graphical
platform,
michael,
is
joining
the
meeting
later.
Thank
you.
K
I
just
joined
ue
from
the
guild
hi.
Everyone.
F
L
Think
we
missed
you
hi
everybody,
it's
early
here
good
morning
from
sydney,
I'm
andy,
I'm
working
on
crafting
java
and
lesson.
F
Glad
you
could
join
welcome
all
right
everybody
thanks
for
being
here.
I
appreciate
it.
It
looks
like
we
already
have
some
excellent
flushing
out
of
the
notes,
thanks
to
our
perennial
notetaker
benji.
Is
anybody
able
to
jump
in
and
help
out
benji,
especially
since
many
of
our
agenda
items
today
are
led
by
benji?
I
think
it
will
be
worthwhile
to
have
an
additional
note
taker.
G
I
can
yeah
I
can
try
and
do
that.
F
Let's
take
a
quick
look
over
the
agenda
that
we
have.
We
are
going
to
talk
about
query
ambiguity
or
more
specifically,
terminology
ambiguity
around
the
term
query
the
dunder
type
name
and
how
it
fits
into
subscriptions,
schema,
coordinates
tag
type
and
then
an
update
from
the
graphql
js
working
group.
B
I
think
we
can
just
squeeze
this
into
the
next
topic,
but
I
I
wanted
to
solicit
feedback
on
the
new
way
that
I've
organized
the
action
items.
F
F
B
Yes,
so
we've
not
been
I'll
turn.
My
video
on
we've
not
been
particularly
disciplined
with
regard
to
filing
the
action
items
for
the
last
little
while
so
I
thought
it
would
be
quite
useful
not
only
to
make
sure
that
we
filed
them,
but
also
to
keep
track
of
where
they've
come
from,
and
that
way
we
can
sort
of
see
the
progress
of
each
individual
meetings,
action
items
and
hopefully
we'll
see
that
the
the
older
items
over
time
will
get
closed.
B
We
have
the
action
items
label
which
we
apply
to
all
of
those,
so
we
can
easily
filter
them
out
and
then
the
idea
is
that
when
someone
thinks
that
their
item
is
ready,
for
you
know
ready
to
be
closed,
I've
created
the
ready
for
review
label
that
we
can
apply
to
it.
I
believe
the
intention,
certainly
from
the
template
is
that
the
items
will
get
closed
during
the
working
group
meetings.
So
I
think
that
gives
us
an
easier
way
of
flagging
the
ones
that
we
think
are
ready
to
be
closed
and
broadly
yeah.
B
I've
gone
through
and
I've
filed
a
whole
load
of
the
old
ones.
Some
of
them,
I'm
afraid,
contain
multiple
to-do's,
because
there
was
a
lot
to
catch
up
on
and
many
of
them
are
probably
already
worthy
of
being
closed.
So
this
might
be
a
lot
of
closing
going
on
during
this
call,
but
yeah.
I
just
wanted
to
get
us
into
a
state
where
the
last
five
months
had
already
been
entered.
F
I'm
also
catching
up
on
the
work
that
you
did
because,
since
I
know,
you've
created
a
lot
of
these
in
the
last
day,
and
certainly
the
last
couple
of
weeks,
but
let's
pop
through
some
of
these,
which
of
these
do,
we
think
we
can
close
out
quickly
and
maybe
it'll
be
helpful.
If
I
just
share
my
screen
really
quick.
F
Okay,
this
first
one
benji-
this
one
is
on
you.
Is
this
completed
yeah,
so
this
was.
F
Great
so
since
these
I'm
going
to
filter
these
down
to
what
are
marked
ready
for
review,
based
on
your
suggestion,
so
presumably
these
are
the
ones
we
can
first
work
through
and
close
out,
and
then
we
can
go
back
and
see
if
there's
any
follow-ups
or
updates.
We
want
to
solicit
yep.
So
this
one
is
good
clarify
the
problem.
That
field
coordinates
is
addressing
and.
F
All
right
sounds
like
we.
You
have
made
good
on
this
follow-up
and
we're
going
to
talk
about
today.
So
I'm
going
to
call
this
one
good,
create
issues
for
action.
Items
for
previous
calls,
meta,
good
and
discuss
flow
support
in
the
typescript
version
of
graphql
js,
and
any
quick
update
on
how
we
want
to
think
about
this
one.
This
was
reopened.
C
Yeah
so
like
I
make
a
comment
and
close
it
because
I
forget
about
fall
that
we
should
discuss
it
on
working
group
before
closing
so
updating
this
on
graphql
js
working
group
o,
and
we
will
tell
detail
details
later
but
about
this
question.
So
my
main
concern
was
that
we
don't
have.
I
like
don't
have
enough
resources
enough
time
to
support
full
time
things,
but
since
dotan
and
uri
is
volunteer
to
have
spontaneous
prototypings,
so
issue
resolved
itself.
F
It
can
be
closed
all
right.
We
will
close
all
of
these
issues
here.
Let
me
just
do
this
to
easy
way.
Can
I
mark
all
these
clothes
this
way,
yep.
Okay.
Mark
is
closed.
Something
went
wrong.
Come
on
get
him.
F
M
F
B
Created
to
narrow
them
down
to
the
ones
that
are
assigned
to
you
lee,
because
many
of
them
are
like
read
over
this
than
the
other,
which
you
I
think
you've
done.
You
tend
to
be
quite
quick
with
those.
F
Read
over
the
graphical
custom,
scalar
pr,
I'm
gonna
leave
this
open
because
I
wanna
go
back
and
I
wanna
only
call
this
one
done
once
I've
once
I've
actually
advanced
this
and
merged
it.
So
I'm
gonna
leave
that
open
and
get
to
that
later
today,
I
think
that's
duplicate
of
424
down
at
the
bottom
as
well.
F
It's
yeah
it
is
and
that
one
actually
is
done,
because
the
editorial
pass
was
completed
so
slightly
different.
But
this
last
one
is
a
is
a
final
pass
before
we
merge,
which
I
think
you
brought
up
a
comment
on
earlier,
which
is
great
and
that's
I'll
go
bottom,
the
top,
since
these
are
older
vision
for
the
code,
page
yeah-
that
one's
definitely
still
on
me
that
one's
open.
F
I
don't
know
how,
where
the
priority
of
that
one
is
to
release
it's
these
other
ones,
check
box
to
issue
template
to
confirm
agreements
are
signed.
F
The
reason
why
you
probably
haven't
seen
it
is
because
he
has
done
the
good
front
work
of
making
sure
if
you've
already
signed
such
an
agreement,
that
you,
you
won't
be
bothered
by
the
bot.
So
I
think
that
one
is
good
and
license
is
missing
in
the
scalars
sub
subproject.
F
I
think
we
still
have
to
figure
out
exactly
how
we
want
to
do.
The
legal
framework
brian
was
looking
in
to
if
what
I
had
proposed
actually
made
sense.
I'm
going
to
leave
that
one
open
I'm
talking
to
brian
later
today
and
I
can
bring
that
up
pr
merging
policy
that
grants
more
contributors
access
to
the
working
group
repo.
F
I
think
we
have
that
policy
figured
out,
but
I
need
to
add
the
more
maintainers,
so
that
piece
is
still
on
me
and
moving
the
deprecated
directive
on
input
fields
rfc
to
stage
two.
I
think
I
missed
getting
this
done,
but
this
is
ready.
K
C
Vr
is
is
merged
into
crafty.js,
not
released
yet
because
we
walked
on
some
like
typescript
issue,
and
it's
like
dotan
is
volunteering
to
help
with
this
issue,
so
we
will
resolve
and
publish
exchanging
graphic
js,
but
for
spec
we
still
missing.
I
still
need
to
add,
like
a
node
rule,
for
requiring
that
deprecated
field
is
optional,
so
it's
not
there
yet
so
yeah
actually
like.
I
try
to
promote
it
to
traffic
today,
but
like
later,
I
read
it
and
like
so.
C
F
Temporarily,
remove
myself
as
an
assignee
until
you
see
that
piece
done,
if
I'm
thrilled
to
hear
that
doton's
volunteering
to
help
get
that
done,
that's
awesome
and
once.
B
We
do
that
then
I'll
move
it
to
two.
I
lost
audio
for
a
moment
there.
This
one
probably
needs
splitting
up
into
multiple
different
actions,
so
I
can
do
that
if
that's
useful.
C
So
it's
not
because
probably
a
confusion,
so
it's
already
merged
into
corrupted
js.
It's
just
not
released
yet
because
of
other
issue
that
blocking
release,
so
it's
merged,
but
not
released.
So
that's
why
we
don't
get
any
feedback
on
it.
So,
but
it's
in
master
and
dot
on
pumping.
F
F
F
F
Great
point:
all
right:
I'm
gonna
stop
sharing
my
screen,
so
we
can
see
each
other
while
we
talk
through
the
rest
of
the
issues,
thanks
again
benji
for
organizing
that
that
was
much
smoother
than
previous
meetings.
I
love
that
organization
screen
okay
and
with
that
we'll
go
on
to
our
next
agenda
item,
which
is
yours
to
drive
benji.
B
So
we
mentioned
this
in
a
working
group
meeting
a
little
while
ago,
and
it
turns
out
just
want
to
make
sure.
Can
everyone
hear
me
yeah
yep
good,
because
I
had
audio
issues
just
now,
linux
hooray.
So
there
was
there's
an
issue
that
a
lot
of
people
new
to
graphql
find,
and
especially
it's
hard
in
when
you're
trying
to
write
documentation
for
something
that
the
term
query
can
be
used
in
many
different
ways.
B
B
Query
queries
queried
that
has
been
used
anywhere
and
I've
tried
to
put
them
into
buckets
based
on
the
meanings
that
I
feel
that
they
have
and
then
I
tried
to
come
up
with
good
names
for
those
buckets
using
terms
that
are
generally
already
used
in
the
graphql
spec,
perhaps
in
the
more
technical
parts
of
the
spec,
for
example
the
the
actual
code
and
not
code.
But
you
know
the:
what
would
you
call
them?
The
the.
B
No,
the
in
spec
md,
the
like
referenced
code,
like
parts
of
the
spec.
F
Oh,
I
don't
remember
if
I
had
a
term
for
that.
I
know
you're
talking
about
though,
but
those
yes.
B
So
so
I've
outlined
in
pull
request.
777
I've
actually
gone
through
and
made
these
edits
to
the
spec.
I'm
not
expecting
these
to
be
merged,
as
is
it's
more
so
that
we
can
see
these
changes
actually
in
context
and
in
a
lot
of
cases.
As
I'm
note
in
this
pull
request,
I've
I've,
where
I've
been
in
dire,
whether
I
should
make
the
edit
or
not
I've
gone
ahead
and
made
the
edit,
because
we
can
always
go
it's
easier
to
go
back
and
be
consistent.
B
That
way,
rather
than
to
then
try
and
find
all
the
places
again.
So
in
a
lot
of
the
graphql
spec,
we
talk
about
queries
where,
generally,
what
we're
saying
applies
actually
to
all
of
the
operations,
queries,
mutations
subscriptions
and
potentially
future
operations.
So,
in
a
lot
of
places,
we've
changed
query
to
operation
what
I've
changed.
B
And
yeah,
I
guess
I
could
go
through
the
terms
that
I've
introduced
or
I'm
not
sure
what
the
best
way
of
surfacing.
What
I've
done
here
is
for
discussion.
F
F
Do
this,
but
at
the
same
time
it
has
this
sort
of
common
understanding
beyond
the
context
of
graphql,
of
that
it.
It's
also
overloaded
in
that
sense,
but
I
don't
know
how
to
tease
that
apart.
You
know,
like
query,
can
sometimes
mean
the
text
of
a
thing.
It
can
sometimes
mean
a
a
particular
like
a
a
read
versus
a
write,
but
in
the
general
way
people
know
it
to
mean
a
request.
F
Kind
of
you
know
an
ask,
and
I
don't
know
exactly
how
to
grapple
with
that.
Just
yet
that
making
making
the
terminology
here
more
crisp
is
definitely
a
good
thing,
but
at
the
same
time,
for
a
new
reader,
especially
in
this
like
section
one
which
is
an
overview
and
then
in
other
parts
of
the
spec
that
are
a
bit
more
non-normative
and
more
describing
why
something
is
important
rather
than
what
it
is.
F
Those
feel
like
they've
taken
a
legibility
hit,
and
maybe
it's
just
a
matter
of
like
exactly
how
we
want
to
tune
this.
But
I'm
sort
of
curious
to
hear
your
perspective.
As
you
were
going
through
this,
I,
I
presume
you
meant
you
kind
of
noticed
a
similar
thing
and
how
you've
been
thinking
about
that.
B
What
specifically
that
term
query
means,
does
it
mean
fetch?
Does
it
mean
issue
a
request
to
your
server?
Does
it
mean
introspect
this
particular
thing
and
interrogate
it
and
various
other
things?
So
I
definitely
agree
and,
as
I
mentioned,
I've
gone
too
far
deliberately
in
the
in
the
modifications
of
it,
but
partly
what
I
would
like
is
for
us
to
come
up
with
a
glossary
that
we
can
then
use
for
these
terms
in,
in
the
more
precise
parts
of
the
spec
and
also
in
the
wider
in
the
wider
ecosystem.
B
People
are
referring
to,
for
example,
the
fields
at
the
root
level
of
the
query
type
as
queries.
There
is
like
the
word
query
beyond
the
spec
is
overloaded,
like
everywhere.
As
you
comment,
it's
it's
useful
outside
of
graphql.
You
can
think
of
it
as
just
a
you
know,
it
is
just
a
normal
english
word
that
is
used
in
many
places
and
I
think
if
we
can
come
up
with
a
way
of
reducing
that
ambiguity
without
necessarily
going
quite
as
far
as
I've
gone
in
this
pull
request,
I
think
that
would
definitely
be
beneficial.
A
A
few
things
that
seem
relatively
uncontroversial,
I
think
anywhere
that
we
are
referring
to
like
a
literal
query,
as
in
we
mean
specifically
the
query
operation
type,
I
feel
like
we're
fairly
inconsistent
in
whether
we
surrounded
with
back
ticks
or
not,
and
I
thought
I
can
place
was
like.
Okay
in
the
query.
You
know
when
you
use
this
particular
operation.
Name,
that's
something
to
say
hey!
A
A
And
maybe
this
is
just
my
sort
of
internal
bias
and
how
I've
seen
it
used.
But
it's
usually
a
query
and
I
colloquium
just
like
yeah,
it's
probably
a
query
and
I
almost
wonder
if
a
non-normative
note
of
just
being
like
there
will
be
times
when
we
will
refer
to
an
operation
as
a
query
and
like
it
just
explicitly
say
like
if
we
mean
only
queries
and
not
mutations
and
not
subscriptions
we'll
say
so.
A
But
if
we're
like
hey,
you
know,
if
you,
if
you're,
requiring
a
server
and
asked
for
you
know
me
first
name,
you
would
expect
to
get
something
back
in
you
know.
The
me
first
name
shape
that
flows
to
me
in
a
way
that,
like
I,
actually
think
changing
the
from
the
work
query,
I
don't
know
like
the
places
where
you're
using
it
in
just
like
normal
english.
Oh
yeah,
if
you
query
a
server,
I'm
like
yeah.
Okay,
if
you
send
a
request
to
the
server,
does
no
harm.
A
G
And
one
of
the
things
I'll
add
is
that
in
our
like
own
internal
documentation,
so
like
account
for
this
ambiguity,
we
also
use
the
term
documents
because
I
think
I've
seen
that
used
quite
a
lot
in
various
official
documentation
places
to
mean,
like
the
the
request
payload,
the
text
that
the
client
sends
to
the
server
and
obviously
a
document
document
can
contain
like
what
many
operations,
I
guess
so
that
that
might
be
another
like
aspect
of
this.
C
I
What
dan
said
kind
of
was
where
I
was
thinking
of
going
as
well
of
just
like,
because
the
ambiguity
is
not
just
within
the
spec
right.
The
ambiguity
is
within
english
as
a
language
and
kind
of
the
way
people
tend
to
use
that
outside
of
graphql
as
well.
I
was
also
thinking
of
like
there's
room
for
us
to
leave
a
non-normative
note
saying
like
this
is
a
confusing
english
word.
You
know,
we've
used
it
in
this
way,
but
other
people
will
use
it
in
other
ways
and
that's
like
just
something
to
be
aware
of.
I
I
would
prefer
that
we
pick
specific
words
with
specific
meanings
and
you
know
define
those
up
front,
even
if
it's
a
little
harder
to
parse
in
english,
rather
than
saying
hey,
we're
just
going
to
use
query
for
everything,
because
that's
what
the
word
people
know:
clarity,
trumps,
accessibility
for
a
technical
document.
In
my
opinion,.
F
I'm
with
you,
the
part
of
the
spirit
of
this
particular
technical
document
is
that
we
hope
that
it
is
accessible.
We've
put
in
a
lot
of
work
to
make
sure
that
the
english
is
not
super
dense
and
that
there's
a
lot
of
explanation
along
the
way
so
that
a
non
super
technical
person
could
kind
of
start
at
the
top
and
read
it
and
make
sense
of
it
in
a
way
that
a
lot
of
the
other
rfcs
that
I've
read
have
been
much
much
more
difficult
to
parse.
F
But
the
spirit
of
what
you're
saying
I
I
completely
agree
with
being
being
crisp
with
language
is
super
important,
especially
in
the
cases
where
we're
actually
describing
something
right.
We're
we're
explaining
how
something
works.
Then
ambiguity
in
that
case
can
be
actually
really
damaging
in
in
places
where
we're
speaking
in
a
high-level
way,
then
I
think
it's
okay
to
kind
of
lean
back
on
the
you
know.
F
The
general
kind
of
concept
of
a
query
is
a
is
a
little
bit
of
an
overloaded
term
and
some
of
these
places,
where
we're
replacing
a
word,
I
you
know
we
could
especially
if
it's
right,
on
top
of
an
example
where
we're
literally
just
describing
the
example
you're
about
to
read.
We
can
you
know
if
we
ins,
if
we
want
to
replace
the
word
query
with
the
word
document
or
operation
or
whatever
we
can
say
in
parens
or
something
in
in
this
example,
a
query
because
it
literally
is
like
it's
technically.
F
Yes,
it's
an
operation
but
like
the
the
example
is
showing
you
a
query,
but
that
might
also
be
benji
to
your
point
about
kind
of
going
too
far
and
pulling
it
back
where
sometimes
when
we
say
query,
we
literally
mean
a
query
operation
and
that's
the
example.
That's
sitting
right
in
front
of
you
as
a
query
operation,
and
that
could
be
okay,
and
I
actually
really.
I
appreciate
the
strategy
that
you're
taking
here
just
like
pushing
it
to
the
extreme
and
seeing
where
it
feels
bad
and
scaling
it
back.
A
Yeah
I
one
of
the
things
I'd
be
curious
about
is
a
little
bit.
What
what
are
this
is
sort
of
the?
What
if
we
replaced
everything?
What
is
the
version
that
is
for
likewise
from
the
non-controversial
version
where
it's
just
like
yeah?
You
know
this
is
just
clearly
a
like
clearly
ambiguous
right
now,
it's
just
like
in
the
following
query
and
the
you
know
example
below
it
is
a
mutation
and
it's
like
okay
cool
like
this.
A
This
is
clearly
creating
confusion,
and
I
wonder
if
there's
sort
of
like
there's
clearly
going
to
be
a
spectrum
here
of
like
some
of
these
changes,
where
edward's
going
to
yes,
this
is
this
is
clearly
better
prose
and
on
some
of
those,
like
oh
shoot
like
now,
we
use
operation
three
times
right
before
we
describe
aquarius
that
can
be
confusing
and,
like
almost
just
like
flap,
a
better
term
land,
the
uncontroversial
ones
are
the
ones
that
you
suspect
to
be
uncontroversial,
and
then
we
can
iterate
from
there.
A
I
think
the
other
thing
I
would
consider
is
are
there
places
where
we
can
make
the
current
text
that
is
ambiguous
but
reads
smoothly
unambiguous
by
changing
the
examples
around
it
where,
for
example,
if
we
say
you
know
hey
in
the
in
the
following
query,
and
it's
a
you
know,
unmarked
query,
where
it's
just
a
selection
set
that
I
guess
could
have
been
a
query.
A
Literally
just
add
the
query
keyword
and
it's
like
okay.
Now
this
is
a
query
instead
of
a
selection
set,
so
that
when
we
say
in
the
following
query,
it's
actually
accurate.
That
might
be
another
way
of
making
making
the
pros
unambiguous,
while
also
making
the
pros
still
flow
in
whatever
sort
of
like
crazy
way.
It
works
right
now.
B
Yeah,
that
seems
that
seems
reasonable.
I
certainly
like
the
idea
of
pulling
certain
classes
of
changes
out
of
here
that
are
non-controversial
getting
them
merged,
separately,
rebasing
and
then
seeing
what
the
next
round
is.
If
there
is
another
one,
one
of
the
things
that
I
really
would
like
to
achieve
with
this
is
where
the
spec
states
things
about
queries,
which
happens
a
lot
so
like,
for
example,
it
says
something
like
a
graphql
query,
on
the
other
hand,
returns
exactly
what
a
client
asks
for
and
no
more
like.
B
Yes,
that
is
true,
but
also
that's
true
of
all
operations.
It's
not
only
true
of
queries
and
potentially
putting
the
word
query.
There
makes
it
seem
like
okay,
so
for
queries.
This
is
true,
but
maybe
mutations
and
subscriptions
work
in
a
different
way,
and
maybe
it
will
for
a
future
operation.
We
don't
know,
but
there's
also
things
like
graphql
query
execution
may
choose
to
only
include
sorry,
I'm
reading
the
wrong
bit.
I've
lost
the
bit.
B
At
that
point
and
many
times
that
is
actually
resolved
as
part
of
the
the
more
code-like
parts
of
the
spec,
but
the
prose
itself
does
leave
that
ambiguity
in
there
where
you're
like
well.
Okay,
if
that
works
for
queries,
what
is
the
rule
for
mutations
and
that
as
much
as
anything
is
one
of
the
things
I'd
like
to
remove?
As
you
say,
it's
a
technical
document,
so
it
should
be
being
precise.
A
Evan,
can
you
go
into
more
detail
about
the
ambiguity
that
led
to
querydocquery.com,
because
that
that
to
me
is
wherever
that
ambiguity?
Is
that
actually
feels
like
the
one?
That
is
very
clear?
I
mean,
as
you
mentioned
very
clearly,
not
prose
and
very
poorly
something
that
is,
you
know,
misunderstood
or
overwritten
in
people's
minds.
I
L
L
Meantime
that
sorry,
can
you
see
in
the
momentum
that
the
worst
and
very
good
ambiguity
comes
actually
not
from
the
spec
but
from
the
variable
builds
into
json
payload
we're
sending
over
http?
In
my
experience,
like
nobody
really
reads
the
spec
in
in
the
way
we
are
doing,
but
if
you
look
at
the
http
request,
we're
sending
and
query
contains
mutation
subscriptions
or
actually
query,
and
this
causes
a
lot
of
confusion.
If
you
talk
with
people
in
my
experience,
so
it's
definitely
overloaded.
B
We've
discussed
that
quite
a
lot
as
part
of
graphical
working
group
and
the
graphql
over
http
working
group
as
well.
It's
a
common
issue
and
really
it
should
be
operation
because
we
already
have
operation
name
in
there.
It
would
make
sense
or
even
document
it
probably.
A
A
A
document
like
there
is
almost
a
and
hearing
hydration
of
like
if
you,
if
you
have
used
graphql
for
a
while
and
it's
like
oh
yeah,
I
can
send
a
document,
it
can
contain
multiple
operations
and
I
can
select
the
operation,
but
if
you're
doing
the
hello
world
get
me
name,
you
do
send
a
query
to
the
server,
and
I
mean
in
some
way
is
that
is
both
like
there's
a
little
bit
of
post-stock
character,
proper
hack.
A
That's
also
why
it's
named
query,
because
originally
you
didn't
have
the
ability
to
send
mutations,
because
mutations
didn't
exist
like
the
derivation
of
how
we
got
there,
I
think
is,
is
relevant
in
that
it
tells
us
how
we
got
there
and
therefore
the
things
that
we
should
read
and
change,
but
it
also
tells
us
the
things
that
we
thought.
Okay,
this
is
what's
going
to
make
this
move
clear
to
somebody
who's
never
seen
graphql
before
and
one
of
the
like.
A
B
B
If
we
change
the
name
of
it,
then
it's
gonna
break
graphql
servers
and
such
one
interesting
point
we
have
coming
up
is
potentially
if
we
get
to
a
point
where
we
can
release
the
version,
one
of
the
graphql
over
http
spec
and
we
start
requiring
the
the
content
type
headers
and
things
like
that
that
currently
are
either
ignored
or
optional.
We
could
at
that
point
introduce
this
and
we
can
always
do
it
so
that
like,
if
we
receive
query
we'll
just
rewrite
it
transparently
to
the
document,
for
example,
which
would
be.
F
Cheap
yeah
there's
something
that's
nice
about
the
ability
to
understand
it
quickly.
You
you
send
a
query.
You
get
a
response,
there's
just
two
terms
there,
and
even
though,
in
practice,
what
you're
really
doing
is
you're
sending
a
request
which
contains
a
document
which
contains
operations,
one
of
which
is
a
query
which
then
returns
the
response.
F
It's
like
that's
a
lot
to
that's
technically,
what's
happening
there,
but
most
people
don't
really
care
that
there's
like
a
thing:
that's
parsing
their
file
and
turning
it
into
some
intermediate
representation,
along
which
they're
at
these
terminologies
the
most
common
happy
path.
Is
I
send
you
a
query
and
you
send
me
a
response
and
there's
something
really
nice
about
framing
up
the
the
actual
tools
that
people
use
in
that
way.
So
I
I
actually.
F
I
think
it
could
make
sense
that
you
know
we're
getting
a
little
bit
off
the
off
the
charted
path
here,
but
for
graphql
http
to
keep
query
around
just
even
for
that
kind
of
early
education
path
to
help
people
understand
what's
going
on
here,
because
it's
easy
to
describe,
and
that
might
be
kind
of
back
to
my.
F
My
very
first
point
kind
of
what
I'm
getting
at
that
kind
of
query
is
easy
to
understand
in
context
if
you,
if
you
are
already
familiar
with
the
usage
of
the
term
in
a
way
that
document
operation
and
request
are
not
and
even
within,
I
think,
we've
like
you.
You've
made
almost
all
correct
suggestions
here,
even
though
you've
kind
of
pushed
it
to
the
extreme,
and
we
can
peel
it
back.
F
But
as
I
sort
of
read
through
the
actual,
like
recommendations
that
you
have
on
on
what
we
swap
out,
I'm
realizing
that
there's
a
lot
of
places
where
you
would
recommend
we
use
the
word
operation
where
I
would
think
like
is.
It
is
operation
the
right.
F
Use
document
would
we
use
request
and
it
actually
gets
like.
I
find
myself
kind
of
getting
lost
in
those
three
particular
terms
about,
what's
most
appropriate
in
the
moment,
because
it's
it's
not
that
it's
unambiguous.
It's
kind
of
it's
like
irrelevant,
right,
like
when
you
say.
Oh,
this
applies
to
an
operation
versus
this
applies
to
a
document.
It's
like
both
of
those
actually
could
be
true
in
a
particular
circumstance,
and
how
do
we
want
to
describe
it
in
in
those
moments.
B
Yeah,
absolutely
it
wasn't
actually
easy
to
edit
because
it
did
take
time
thinking
through
which
of
these
does
this
actually
apply
to
and
really
which
concept
does.
This
belong
to
and
yeah.
H
B
Put
time
into
that,
I'm
trying
to
make
sure
it
was
the
right
decision
each
time,
and
I
think
you
raise
a
good
point
that
sometimes
it
doesn't
matter
like
if
it
applies
to
a
document,
then
it
applies
to
a
request,
because
a
request
contains
a
document.
If
it
applies
to
a
you
know
the
query
type,
then
it
applies
to
all
these
things
because
all
of
them
may
well
boil
down
to
the
query
type.
B
But
I
again,
I
think
it's
where
maybe
precision
is
useful
in
that
case,
because
if
you're
implementing
graphql,
when
you
read
the
spec,
you
want
to
know
which
part
of
your
implementation
you
care
about
this
particular
sentence
for
and
that
may
be
relevant,
maybe
not
in
all
the
places.
I've
done
it
obviously,
but
certainly
in
a
few.
B
E
B
G
Sorry
did
someone
else
want
to
say
something.
This
is
like
a
potentially
like
dumb.
I
don't
know
not
not
valuable
thing,
but
I
just
like
thinking
through
like
that.
There's
parallels
here
in
other
domains
right,
so
you
send
an
http
request
and
you
could
send
like
a
get
method
or
a
post
method
right.
G
So
maybe
there's
some
value
in
kind
of
looking
at
what
like
other
specs
do
so
like
looking
at
the
http
spec
like
whenever
it
talks
about
like
a
request,
it
always
talks
about
a
get
request
and-
and
that's
like
a
like
standard
that
they
have
in
the
http
spec
almost
so
it's
always
unambiguous,
like
it
never
just
talks
about
like
a
request.
It's
always
a
get
request
to
kind
of
reduce
the
ambiguity
there.
So
I
don't
know
if
there's
any
yeah,
I
don't
know
if
that's
helpful
or
not,
but
yeah.
B
I
think
it
is
inspirational
and
it
actually
reflects
one
of
the
things
that
I've
done
in
this,
which
is
the
query
as
a
standalone
word:
I'm
not
really
allowed
to
exist.
B
So
when
you
actually
refer
to
a
query,
it
would
always
say,
for
example,
query
operation
and
I
think
what
that
means
is.
If
we
don't
then
follow
the
word
query
with
operation
or
document
or
variables
or
whatever
else
then
it
can
be.
Then
you
know
if,
if
query
exists
on
its
own,
then
it's
being
used
as
a
broad
generic
term.
Whereas
if
it
is
query
operation,
then
it
is
well
defined
and
I
think
we
can.
We
can
do
that
quite
cleanly.
B
We
don't
need
a
naked
query
like
in
any
of
the
technical
aspects
of
the
spec.
B
So
I
think,
there's
two
things
I'd
like
to
get
out
of
this.
B
The
first
thing
is
broadly
the
the
definitions
that
I've
come
up
with,
like
the
the
glossary
I'd
like
to
get
feedback
on
that,
make
sure
that
people
are
happy
with
that
and
that
doesn't
need
to
be
during
this
call
like
by
all
means,
follow
up
afterwards
and
then
I
guess
the
next
action
would
be
if
everyone's
happy
with
the
definitions
that
I've
got,
it
would
be
putting
a
few
of
these
edits
into
into
the
specs
so
pulling
out.
B
There
is
another
separate
question
which
is:
should
we
look
at
actually
adding
a
glossary
and,
if
so,
for
now,
should
that
just
be
like
a
read
like
a
markdown
file
in
the
repo
that
is
separate
from
the
spec?
Whilst
we
build
up
the
terminology
or
what's
the
best
approach
there,
if
we
even
need
one.
F
I
feel
like
a
glossary
should
should
be
an
inherent
part
of
this
spec
md
document
in
the
same
way
that,
like
there
already,
is
an
appendix
to
the
spec
that
describes
all
of
the
grammar
rules
all
of
the
algorithm
rules,
and
it
would
make
sense
that
every
time
like
a
term
is
defined,
that
that
has
like
a
first
class
thing.
That
way
the
tool
can
kind
of
automatically
help
us
manage
that
and
they
can
be
linked,
which
would
be
nice.
F
So
when
you
see
a
word
you
and
it's
linked,
you
know
that
it
isn't
just
like
a
clinical
use
of
the
word.
It's
actually
referred
to
as
some
definition
that
exists
in
the
document
that
that's
not
a
thing
that
I
expect
you
to
do
in
this
particular
edit.
But
I
think
that
could
be
the
right
sort
of
like
long-term
direction,
for
a
glossary
to
take.
I
Yeah,
I
think,
like
to
dan's
earlier
point
of
like.
What's
the
non-controversial
version
of
this
request,
I
think
the
non-controversial
version
is
a
glossary
and
a
non-normative
note
that
query
is
really
confusing
and,
like
that's
the
thing
that's
like
just
will
help
people
already
reading
the
spec
and
working
with
it,
but
doesn't
change
the
language
or
you
know
open
any
of
those
other
questions.
F
I
think
even
before
then
just
you
know
I
just
kind
of
reading
through
the
changes,
a
bunch
of
them.
I
don't
pan
out
and
in
part
of
this,
like
first
uncontroversial
change,
but
a
handful
of
them
definitely
do.
There's
where
you
add
in
a
partic,
you
don't
replace
a
term.
You
add
a
word
just
to
make
the
the
phrase
more
clear,
like
those
should
be
non-controversial
the
place
where
we
say
query
and
we're
actually
just
wrong
that
it's
like
we're
talking
about
something
specific
in
a
way
that
query
is
super
confusing.
F
That's
like
maybe
20
of
this
pull
request,
but
there's
definitely
a
handful
of
the
changes
in
here
that
are
going
to
be
really
non-controversial
that
might
help
kind
of
tease
down
what
these
definitions
are.
So
I
feel
like
that
could
be
factored
out
independently.
That
would
be
very
easy
to
review.
Then
this
non-normative
note,
I
I
think
the
idea
of
it
is
non-controversial
exactly
how
we
frame
it
might
be,
but
you
should
take
a
stab
at
it.
I
think
that
will
be
really
useful.
F
I'd
love
to
have
a
version
of
it
that
actually
allows
us
to
use.
The
word
query
sort
of
on,
without
any
additional
words
around
it
within
the
document.
I
I
think
that
was
that
evan
was
at
your
point.
Was
that
dan's
point
of
when
you
see
the
word
query
in
this
doc?
Here's
here's
how
to
interpret
it
like.
We
understand
that
this
word
is
a
little
bit
of
an
overloaded
term.
F
That
seems
fine
to
me
like
it
doesn't
seem
ambiguous
that
we
point
to
a
example
which
is
itself
a
query
and
say
that
it's
a
query,
you
know
technically
it's
we
could
be
more
specific,
but
we're
kind
of
introducing
an
example
that
doesn't.
I
think
that
could
be
fine,
and
if
we
have
a
non-normative
note
that
makes
that
kind
of
clear.
So
when
someone
wants
to
get
pedantic
on
us,
they
go
when
you
said
corey,
or
do
you
mean
all
things,
it's
like
no
we're
usually
describing
example.
F
C
The
just
reading
really
one
part,
so
they
will
basically
miss
normative
note
on
the
query,
especially
since,
like
with
citation,
I
really
like
it,
and
it's
very
useful
so
like
people
excite
stuff
and
so
like,
I
think
it's
better
when
parts
of
us
becca
self-contained,
I
agree
about
examples,
might
be
like
more
illustrative
in
a
sense,
but
like
algorithms
and
things
should
be
sedatable.
C
F
F
Cool
so
benji,
it
sounds
like
you
have
some
thoughts
on
next
steps
and
you're
also
asking
for
people
to
drop
comments
with
more
specific
feedback
in
your
issue
or
pull
request.
B
Yes,
please:
I
want
to
make
sure
that
the
terms
that
I
would
do
any
further
edits
with
are
the
correct
terms
and
then
also
with
regard
to
the
the
glossary.
I
think.
Obviously,
a
glossary
is
a
very
it's
a
significant
undertaking
because
it
doesn't
just
relate
to
this
one
word.
It
relates
to
lots
of
words
so
yeah
absolutely.
F
B
So
this
was
this
was
an
interesting
one.
Whilst
I
was
going
through
doing
the
previous
stuff,
I
was
reading
through
the
document
in
in
quite
good
detail
and
realized
that
type
name
was
was
talked
about
and
realized
that,
if
you're
doing
a
subscribe
operation
with
the
graphql
reference,
implementations
or
graphql
js-
and
you
do
a
subscription
to
the
double
underscore
type
name
field-
you
get
an
error
because
it
doesn't
return
an
async
iterable
now,
obviously
doing
this
doesn't
really
make
sense.
This
isn't
a
thing
that
returns
a
you
know.
B
It's
not
a
real-time
piece
of
information,
but
also
getting
an
error
back.
Maybe
doesn't
feel
like
the
right
thing
to
do
here.
So
I'm
not
sure
whether
we
just
say
this
is
an
edge
case.
No
one's
going
to
do
this,
we
don't
care
or
whether
we
ought
to
put
some
wording
here
or
whether
I
honestly,
I
don't
know
what
the
right
thing
is
to
do
here.
I
just
noticed
it
and
it
seemed
like
it
wasn't
right.
B
I
I'm
honestly,
I
think
that
might
be
a
reasonable
thing.
One
thing
to
keep
in
mind,
which
is
quite
interesting
if
you
send
a
regular
graphql
resolve
to
so
an
execute
to
the
subscription
type
for
that
field.
It
will
resolve
and
it
will
give
you
the
writing
thing.
So
it's
only
actually
the
subscribe
and
not
the
execute
that
causes
this
issue.
So
it's
not
technically
that
that
field
can't
exist
on
the
subscription
type.
It's
that
it
cannot
be
subscribed
to
so
yeah,
even
more
educatey.
J
B
Yeah
or
just
leave
it
as
is,
and
put
a
non-normative
note
in
there
in
the
spec
saying.
If
someone
does
this,
it
will
it'll
throw
an
error.
Doesn't
matter
like
they're,
not
doing
something
sensible,
I
just
don't
want
it
to
look
like
an
oversight.
F
This
one
was
tricky,
I
feel
like
anything
we
we
do.
I
mean
you've.
You've
found
one
of
the
the
rare
logical
inconsistencies
across
the
spec.
It's
like
you
can't
fix
a
logical
inconsistency
with
an
additional
rule.
You
just
move
the
logical
inconsistency
right,
so
there's
another
rule
somewhere
that
says
any
selection
set
you're
always
allowed
to
ask
for
dunder
type
name,
and
so
then
we
break
that
one
by
saying
in
this
particular
case,
there's
a
validation
rule
that
fails
so
then
that
one
is
broken
and
like
how?
F
How
broadly
would
we
like
to
spread
this
particular
edge
case
across
the
spec
in
terms
of
managing
it?
So
I
don't
know
what
the
right
answer
is.
I
don't
have
a
strong
opinion,
but
leaving
it
be,
might
be
the
the
most
reasonable
thing
or,
having
a
small
note
specific
to
subscriptions
that
this.
This
might
not
be
a
reasonable
thing
that
works
open
to
ideas,
though.
C
I
actually
feel
like
we
should
support
type
name,
because
we
have
this
property
that,
on
every
level,
you
can
figure
out
what
what
type
is,
and
in
some
cases
like
for
schema
os
clients.
They
actually
do
some
useful
things
like
normalization
and
stuff.
Obviously,
you're
not
should
not
cache
like
topo
subscription
normalize
it.
But
basically
we
we
add
one
additional
rule
in
every
corner
and
say
saying
you
should
inject
type
name
so,
for
example,
injecting
type
name
and
we
say
on
subscription.
You
should
not
inject
type
name
on
top
level.
C
I
feel
like
right
now
we're
pushing
pushing
corner
keys
into
coins
instead
of
addressing
it,
and
what
what
I
propose
can
be
a
wall
like
we
have
rule
that
subscription
can
contain
only
single
field
and
what,
if
we
allow
it
to
be.
C
A
single
non
non-introspection
field
and
as
much
as
prospection
fields
you
want
so
like
you
can
do
any
number
of
introspection
fields.
That's
how
would
you.
C
No,
like,
like
other
other
introspections
fields,
accessible
like
schema
and
type
accessible,
only
on
query,
but
in
future,
if
you
add
something
that
accessible
from
subscription
like
some
other
thing,
so
basically
we
can
say
like
for
right
now
for
practice
purpose
you
can
put.
You
should
put
something
beyond
introspection
field.
You
cannot
just
send
in
respect
underscore,
but
if
you
put
something
that
does
not
underscore
type
name,
you
can
also
put
underscore
under
underscore
type
name.
In
addition
to
that,
so
we
don't
add
something
new.
We
just
change
our
existing
validation
rule.
C
I
don't
think
we
should
regulate
the
respection
fields
the
same
way
we
regulate
like
normal
fields,.
J
While
that
would
be
okay,
I
I
think
the
initial
issue
is
still.
What
do
we
do
with
underlying
type
name?
You
could
just
automatically
open
up
like
a
stream
that
has
just
one
item
and
then
is
finished
like
consumed
after
you
consume
the
type
name.
That
would
be
one
one
way
to
deal
it,
but
I
think
that
this
is
the.
C
J
B
Alternatively,
like
another
solution
could
be
just
to
ban
like
we
already
know
that
subscription
with
just
done.
The
type
name
doesn't
work
like
it
returns
an
error
in
the
reference
implementation
and
probably
in
other
implementations.
B
I
haven't
checked
them,
so
we
could
just
say
that
the
the
validation
for
the
subscription
operation
is
that
it
must
have
one
field
and
that
field
cannot
be
an
introspection
field
that
is
already
the
status
quo.
That
is
already
what
all
useful
subscriptions
do.
So,
though
it
is
technically
a
breaking
change,
it's
not
really
like.
No
one
is
sensibly
requesting
thunder
type
name
there,
and
I
think
that
would
probably
just
just
solve
it
like
in
a
subscription
request.
You
may
only
have
one
field
and
that
field
is
not
an
introspection
field.
B
To
a
van's
point,
there
actually
was
an
issue.
I
forget
whether
it
was
from
graphical
itself
or
whether
it
was
from
a
graphical
explorer
from
the
one
graph
guys,
but
there
was
an
issue
where
the
dunder
type
name
was
being
added
to
subscriptions
like
accidentally
and
was
causing
subscriptions
to
break,
and
that
was
something
that
someone
had
to
fix
at
some
point.
So
ivan's
point
that
he
raises
is
actually
like.
It
is
an
issue
that
has
been
faced
in
the
graphql
ecosystem,
but
I'm
not
necessarily
like.
B
F
The
spec
actually
already
calls
out
that
introspection
fields
are
counted
in
the
rule
that
only
one
entry
must
exist
in
the
top
level
selection
set
of
a
subscription
and
there's
an
example
that
shows
some
subscription
has
a
new
message
field
and
then
also
type
name,
and
that
that's
a
counter
example
that
fails
and
so
that
that's
the
scenario
that
you're
talking
about
right,
that
type
name
field
was
getting
added
automatically
and
was
therefore
causing
a
problem.
F
So
I
yeah,
I
feel
like
no.
No
option
is
a
great
option,
but
maybe
there's
an
acceptable
option
and
benji
what
you're
describing
I'm
I'm
kind
of
on
board
with
that's
great,
because
that's
actually
what
the
pr
is.
F
Amazing
great
work-
I
I
I'm
kind
of
I'm
also
with
yvonne
that
you
know
getting
this
getting
this
introspection
ability
everywhere
is
is
actually
really
important.
So
I
I
don't
want
to
take
it
lightly
if
we,
if
we
kind
of
officially
block
that
here
and
I
kind
of
want
to
unders,
better
understand
the
implications
of
doing
that-
and
maybe
it's
okay,
but
certainly
type
name
on
its
own-
that
that
just
I
don't
think
that
ever
makes
sense
like
that
would
require
so
much
additional
mechanics
to
like
you.
F
Don't
have
a
subscription
source
so
like
what
is
the
subscription
supposed
to
do,
and
is
that
even
a
reasonable
use
case
to
subscribe
only
to
the
type
name
of
the
top
level
of
the
subscription?
It's
that's,
probably
not
a
useful
thing,
and
so,
since
there
isn't
a
use
there,
then
maybe
it's
okay.
If,
if
introspection
at
that,
very
top
level
for
subscription
goes
away,
but
I
don't
know,
can
anybody
else?
Think
of
any
other
reason
why
this
could
really
hurt
us
in
the
long
run.
B
F
If
we
want,
if
we,
if
we
expand
from
any
other
introspection
fields
at
the
top
level,
we'll
have
to
make
sure
that
our
memory
is
good
and
we
come
back
to
this
issue
and
make
sure
that
whatever
we're
expanding
works
for
subscriptions.
But
that's
that's
pretty
theoretical.
So
I
think
I'm
on
board
with
your
proposal.
F
L
B
Sorry
andy,
so
I've
opened
a
pull
request
for
this
with
the
spec
edits.
Are
you
talking
about,
maybe
including
a
copy
of
this
discussion
in
in
the
issue,
in
the
pull
request
itself.
L
No,
I
know
I
understood
that
we
don't
want
to
do
anything
about
it
right.
What
do
they
miss?
Did
they
get
this
wrong
about
the
underscorers
for
typing
problem
and
subscriptions?
We
we
want
to
open
up
requests
or
we
don't.
B
I
think
that
the
conclusion
we've
come
to
is
that
the
pull
request
that
I've
raised,
which
basically
says
that
there
is
a
single
exception
of
the
subscription
route
operation
type
to
where
dunder
type
name
is
valid.
I
think
we're
proposing
that
that
might
be
worth
merging,
because
nothing
currently
works
with
it
anyway,
it
doesn't
seem
to
have
any
penalty,
it's
just
like
an
artifact
and
that
we
a
loophole
that
we
can
close
without
pain.
I
think.
B
Do
some
more
spec
edits
to
actually
make
that
mergeable,
but
broadly
that's
the
proposal?
I
think
currently,
okay,.
F
Yeah,
I
think
you
can.
You
can
certainly
clean
up
the
pull
requests
to
kind
of
factor
in
what
we've
discussed,
but
you
can
keep
everything
in
that
one
and
we
can
mark
that
as
a
as
a
proposal
since
it'll
actually
result
in
a
spec
change.
F
F
There's
like
a
subscriptions
validation
piece.
That's
the
right
place
to
do
that.
B
Yep
I'll
add
that,
to
the
I'll
add
that
to
that
pull
request.
C
I
have
a
question
about
allowing
type
name
in
addition
to
so
like
I
agree,
it's
separate.
It's
totally
separate
issue
in
a
sense
because
it's
not
addressing
like
initial
concern
just
asking.
If
somebody
wants
you
to
do
that
with
proposal,
is
something
that
people
interested
in
or
it's
like,
very
theoretical,
because
I
feel
like
from
time
to
time
everybody
every
like
advanced
client
that
inject
type
name
will
go
through
this
issue
of
discovering
this
problem
and
fixing
it
and
adding
more
one
more
thing
into
your
source
code.
F
Okay,
moving
on
schema
coordinates
check
in
mark
I'll
hand
it
to
you.
G
Cool
thanks,
yeah
I'll
hand
back
over
to
benji,
then
for
notes
for
this.
If
that's
okay,
so
yeah,
I
talked
about
this
two
meetings
ago
and
we
had
a
good
discussion
over
this.
Just
a
like
super
quick
reminder
for
folks,
so
the
schema
coordinates,
formerly
fields
coordinates.
Rfc
is
sort
of
canonicizing.
G
G
So
I
have
a
rfc
for
this.
I
guess
I
should
put
the
link
in
there,
but
last
time
we
discussed
this.
The
action
item
was
to
crisp
up
the
problem
statements
and
to
sort
of
concretely
talk
about
what
the
use
cases
are.
So
I
think
I
think
I've
done
that.
G
So
I
would
appreciate
kind
of
you
know,
feedback
on
that,
hopefully
we're
in
a
place
where
this
is
like
non-controversial,
and
so
I
think
the
action
item
now
is
for
me
to
turn
that
into
a
like
actual
spec,
edit,
the
algorithm
or
whatever.
We
want
to
call.
It
is
kind
of
described
in
the
epr
already
through
examples,
but
I
think
turning
that
into
a
like
formal
spec
thing
is
where
I'm
struggling
a
little
bit.
So
I
I've
been
like
trying
to
do
that
like
deciding.
G
G
Core
execution
notes
or
conventions,
or
something
like
that
yeah.
So
this
is
mostly
to
kind
of
like
let
you
know
that
I'm
still
alive
and
thinking
about
this,
and
also
just
like
voicing
the
I
don't
really
know
how
to
turn
this
into
a
like
proper,
like
I
don't
know
where
to
put
this
in
the
spec.
Basically
so
yeah
just
kind
of
checking
in
and
yeah
I'll
talk
about
it.
F
It
is
an
interesting
question
of
of
where
such
a
thing
goes
once
we
agree
on
it,
because
this,
the
specs
purpose,
is
to
kind
of
describe
what
is
and
what
isn't,
graphql
and-
and
this
doesn't
really
help
us
do
that,
and
so
that's
probably
part
of
the
reason
why
it's
it's.
You
struggled
a
bit
to
try
to
figure
out
where,
to
put
it,
I
could
see
it
going
in
an
appendix
that,
just
kind
of
like
describes
schema,
coordinates
and
how
to
refer
to
them.
F
It
could
also
be
folded
in
sort
of,
as
as
we
introduce
these
concepts
of
like
how
to
find
them.
The
other
place
that
it
might
be
relevant
is
where
we
talk
about
errors,
so,
especially
since
one
of
the
early
motivations
here
is,
when
you
have
machine
generated
errors
that
want
to
be
able
to
refer
back
to
particular
places
within
the
the
schema
that
might
be.
That
might
be
a
worthwhile
place
to
introduce
this
idea.
G
Yeah,
I
know
that
that
makes
sense.
I
think
I
personally
like
the
idea
of
the
appendix
section
the
most
just
because
I
mean
the
errors
thing
makes
sense,
but
then
there's
also
like
equally
strong
use
cases
of
like
graphql
ides,
like
graph
iql
and
apollo
and
stuff
like
like
hover
over
the
thing,
and
it
shows
you
in
the
hyperlink
the
the
schema
coordinates.
So
then
it's
like
okay.
G
Do
we
do
it
in,
like
the
errors
section
of
you
know
the
spec
or
somewhere
else,
and
maybe
like
we
have
it
as
an
appendix
thing
and
like
we
link
to
it
from
the
errors
section.
If
you
see
what
I
mean,
so
I
I
think
I
mean
look.
I
I
can.
I
can
just
get
going
on
that
and
then
like.
If
it's
the
wrong
place
in
the
pr,
someone
can
tell
me
to
move
it
and
I'll
do
that.
I
guess
so.
I
guess
I'll
forge
your
heads
with
that.
G
There
were
a
couple
of
like
open
questions.
One
was
what
do
we
do
about
enums,
which
is
something
I
had
like
totally
not
considered,
but
I
think
the
suggestion
in
there
is
just
like
make
it
the
same
as
as
like
field
attributes.
So
you
can
just
do
like
you
know,
foo
dot
bar
same
as
you
would
with
a
with
a
type
and
field.
So
I
think
the
approach
here
is
going
to
be
like,
as
as
exactly
as
you
would
expect.
G
F
So
maybe
it's
fine
that
this
is
continues
to
overload
that.
G
Yeah,
I
don't
believe
you
can.
I
mean
correct
me
if
I'm
wrong,
but
if
you,
if
you
have
like
an
identifier
as
an
enum,
so
like
user
could
be
an
enum,
you
couldn't
also
have
like
a
user
type
that
would
clash.
F
F
F
And
maybe
this
is
the
right
decision,
but
I
wanted
to
make
sure
you
kind
of
had
an
opinion
that
this
is
the
right
thing
to
keep
it,
because
the
the
benefit
of
what
you're
proposing
is
that
it
looks
pretty
similar
to
what
people
are
probably
familiar
with
in
languages
like
typescript
and
swift,
and
like
probably
the
domain
in
which
someone
will
be.
If
they're,
on
the
consuming
side
of
these.
G
Yeah
yeah.
No,
that's
definitely
like
a
great
point.
I
think
the
fact
that
it
resolves
to
an
ambiguous
thing
is
is
good
and
that
that
makes
this
okay.
I
guess
it
would
be
nice
to
be
able
to
like
visually
see.
Oh
this
is
this.
Is
an
enum
not
a
tight
if
it
was.
G
Then
we'd
have
a
bigger
problem,
at
least
it's
not
ish
yeah
yeah.
So
I
I
I
don't
know
like
I.
G
F
Yeah
for
what
it's
worth,
I
think
it's
probably
the
right
move.
My
thought
was
like.
I
saw
your
section
on
separators
and
colons
or
hashes,
or
something
like
that
and
was
thinking
like
oh
yeah.
Maybe
you
would
use
a
colon
for
one
of
these
and
a
dot
for
another,
and
you
could
then
tell
oh
that's
an
enum
and
that's
not
because
of
the
separator
yeah
like.
Is
that
too
fiddly
are
people
gonna
be
confused
by
that.
G
Yeah,
that
was
gonna
say
like
literally
that
yeah
I
agree.
F
One
thing
that
might
be
helpful
as
you're
continuing
to
evolve.
This
is
just
to
literally
list
out
all
the
possible
types
and
like
especially
if
this
is,
if
you're
thinking
like
what
is
the
form
of
this,
that
would
that
would
fit
as
a
section
or
as
an
appendix
it
probably
is
like
for
a
type
here's
how
you
describe
it
for
a
field.
F
To
avoid
that
case,
where
you,
even
if
there's
wonder
like
you,
can't
describe
this
one,
it's
like
if
there
are
cases
where
you
can't
describe
them
like
a
union
like
it,
would
be
interesting
to
just
like
touch
on
unions
and
say,
like
you
can
refer
to
the
name
of
a
union,
but
it
doesn't
make
sense
to
refer
to
a
member
of
a
union
with
a
schema
coordinate.
So
like
that's,
not
a
thing
that
is
done
here.
F
Just
so
that
you,
you
are
clear
about
what
is,
does
have
a
schema,
coordinate
and
what
doesn't
and
then
hopefully
that
helps
you
avoid
additional
follow-ups
like
this
enum
value.
That
was
just
kind
of
off
your
radar
and
showed
up
that.
Luckily,
the
suggestion
here
is
clear,
but
we
would
we
would
want
to
make
sure
that
there's
no
other
sort
of
missing
pieces
to
it.
G
Okay,
yeah,
that
makes
sense
so
enumerate
all
the
different
like
use
cases
that
you
could
have
for
this
all
the
different
things
you
could
select
and
show
an
example
for
that.
That
makes
total
sense
and
one
other
thing
I
wanted
to
call
out,
which
is
kind
of
like
a
non-goal
of
this
thing,
I'm
not
doing,
which
was
discussed,
which
is
the
idea
of
like
wild
cards
and
and
this
kind
of
like
wider,
more
more
generalized
like
selection,
language,
like
you
know,
document.queryselector
that
kind
of
thing,
but
for
graphql.
G
That's
something
that
this
is
not
but
kind
of
don't
want
to
close
the
door
to
that.
If
someone
wants
to
build
that
spec
in
the
future,
maybe
I
don't
know,
but
that's
just
like
something
bubbling
through
my
brain.
D
F
D
We
we've
got
something
that
partly
we've
been
playing
with
to
differentiate
something
for
directors.
We
did
have
to
do
just
that
and
prefix
it
with
an
out
sign.
So
if
I
mean
we
we've
done
that,
but
I
don't
know
anyway,
I
just
like
bring
it
up.
Mark's
gonna,
think
about
it.
G
G
G
F
You
should
be
clear
if
your
coordinates
are
pointing
to
things
within
a
document
or
things
within
a
schema.
So
if
they're
pointing
within
a
document,
then
you
need
to
be
able
to
say
at
this
particular
branch.
This
directive
on
this
field,
if
you're
pointing
with
a
schema
there's
just
only
ever
one,
you
know
that's
just
the
definition
of
the
directive.
You're
talking
about
that
might
help
resolve.
G
Yeah,
I
think,
also
to
clarify
the
the
scope
or
the
intended
scope
of
this.
Rfc
is
just
for
schemas
rather
than
like
documents,
because
we
I
mean
there's
already
like
a
language
like
the
fields
array
thing.
D
For
the
queries
you
still
have,
you
still
have
uses
of
directives
in
schemas,
not
just
the
definition
of
the
directives.
G
H
B
I
gotta
find
the
relevant
tab.
Oh
gosh,
I
was
busy
taking
notes
and
I've
opened
too
many
things,
and
now
I've
lost
where
I
am,
I'm
gonna
open
it
from
the
from
the
notes.
B
There
it
is
okay,
so
yeah.
This
is
broadly
an
update.
We
spoke
about
tag
types.
I
think
a
couple
of
working
groups
ago
where
previously
to
that
we'd
raised
the
idea
that
we
were
going
to
introduce
this
potentially
introduce
this
new
type.
So
I
worked
up
the
original
rfc
for
that
we
got
a
decent
amount
of
feedback
on
that.
So
thank
you
to
everyone
who
has
contributed.
B
B
There
are
still
a
few
ongoing
discussions,
so
I
guess
one
thing
I
could
do
here
to
update.
You
is
say
what
sort
of
things
have
changed
in
what
we're
proposing
for
the
tagged
type.
So
one
of
the
most
recent
changes
which
I
haven't
yet
reflected
in
the
spec
edits,
because
I
only
wrote
this
up
yesterday-
is
that
we
currently
don't
think
that
we're
going
to
allow
for
tag
types
to
be
valid
against
both
input
and
output.
B
So
at
the
time
that
you
define
a
tag
type,
you
will
declare
whether
or
not
it
is
an
input
or
an
output.
Tagged
type
further:
it's
rather
controversial
whether
or
not
we
add
the
tag
type
to
output,
as
we
always
knew
it
would
be.
So
I
have
taken
some
time
to
write
some
of
the
justifications
as
to
why
we
might
want
to
allow
the
tag,
type
and
output.
B
It
definitely
makes
sense
to
solve
the
problems
now,
for
example,
if
we
were
to
just
decide
that
the
tag
type
is
going
to
be
input
only
for
now,
and
we
just
called
it
in
the
sdl
in
the
schema
language.
If
we
just
said
tagged,
foo
is
this,
then
in
future
it
would
potentially
limit
how
we
would
then
add
it
to
output.
It
might
be
a
tagged
output
foo
and
at
that
point
the
the
like
consistency
might
be
limited.
B
B
I
have
also
outlined
almost
a
flowchart,
not
exactly
a
flowchart,
it's
just
a
numbered
list,
but
a
a
list
of
when
you
would
use
the
various
output
types,
whether
you
would
use
a
an
interface
a
union
or
a
tagged
type.
I
don't
think
that
interfaces
really
enter
into
this
discussion
too.
Much
excuse
me.
B
I
don't
think
they
factor
in
too
much,
because
I
think
the
rules
around
interfaces
are
are
relatively
clear,
so
if,
for
example,
you're
building
a
field
that
will
return
one
of
many
object
types
and
it
would
make
sense
for
the
client
if
all
of
those
object
types
were
to
return
a
set
of
fields
that
relate
to
that
field.
So,
for
example,
if
you're
searching
for
products
within
a
store,
it
might
make
sense
to
make
sure
that
whatever
it
returns
will
always
have
a
name,
a
price
and
maybe
a
description
or
something
like
that.
B
So
there
you
would
use
like
the
shoppable
product
interface
or
whatever.
If
that
applies
to
your
data
most
likely,
you
want
an
interface
and
that's
kind
of
the
end
of
that
discussion.
If
you
don't
have
the
commonality
in
your
types,
then
you're
not
going
to
be
using
interface.
So
then
it
comes
down
to.
B
Why
would
you
use
a
union
versus
attacked
and
I
think
for
my
reasoning
for
this,
and
it
is
challenging
because,
as
has
been
pointed
out,
there
is
definitely
overlap.
The
tag
type
introduces
a
lot
more
flexibility
versus
the
union.
So,
for
example,
a
the
tag
type
can
do
like
a
union
over
not
just
object
types,
but
also
other
unions
interfaces
other
tags.
It
can
do
it
over
scalars
over
enums.
B
It
can
do
it
over
lists
of
any
of
these
previous
things
as
well,
so
it
does
allow
for
a
much
richer
expression
and
now,
obviously
it's
not
saying
it
could
be
any
of
these
things
you
have
to
define
which
ones
you're
going
to
allow.
So
it's
not
allowing
it's
not
almost
like
next
to
an
any
type.
It
is
still
very
strongly
typed
and
you
can
define
which
ones
make
sense,
but
that
can
be
useful
for
particular
data
sources
that
do
allow
for
this
polymorphic
data.
B
If
it
makes
sense
to
use
an
interface
use,
an
interface,
if
you
think
that
you're
going
to
be
returning
object
types,
but
you
might
in
future
also
want
to
return
scalars
or
return
lists
or
enums
from
your
field.
Then
it
would
make
sense
to
use
a
tagged
output
because
it
saves
you
that
it
gives
you
that
option
for
the
future.
B
Would
you
like
to
do
something
where
you
have
a
polymorphic
output
type,
and
you
want
that
to
match
your
polymorphic
input
type
and
to
be
of
a
similar
structure,
or
even
potentially,
even
a
symmetric
structure?
If
so,
potentially
use
the
tagged
output
type.
B
And
this
one's
more
interesting,
are
you
considering
non-technical
users
as
using
an
interface
like
graphical,
or
something
like
that
within
your
schema,
because
if
you're
exposing
that
kind
of
interface
to
users,
the
fragment
syntax,
is
very
programmery,
you
know
dot
dot
spread
on
selection
set,
whereas
the
the
tagged
queries
is
very
much
just
like
querying
an
object
type.
So
it's
consistent
with
the
rest
of
your
schema,
so
it
can
actually,
I
believe,
be
a
lot
simpler
for
people
who
are
new
or
new
to
graphql
or
less
technical
to
use
it.
J
B
Only
yes,
so
at
the
moment
the
proposal
is
that
this
is
still
the
same
type.
So,
whereas,
like
the
input
type
and
the
object
type
are
two
different
types
in
graphql:
we're
proposing
that
the
tagged
would
be
one
type
which
would
have
a
property
that
declares
whether
or
not
it
is
valid
for
input
or
valid
for
output,
and
the
reason
for
that
is,
it
saves
the
option
value
if,
in
future,
we
do
want
to
allow
a
tag
to
be
both
input
and
output.
B
It
allows
for
that,
and
also
broadly
the
the
capabilities
of
attacked,
don't
really
differentiate
between
those
two
use
cases.
So
fields
don't
accept
arguments
and
things
like
that.
J
Yeah,
but
there
were
a
lot
of
issues
or
I
think
when
I
read
this
first
time
they
it
doesn't
felt
clean
the
implementation.
You
had
to
do
a
lot
of
checks
like
if,
if
you
introduce
output
types
into
the
tech
type,
it
becomes
an
output
type
and
if
you
just
have
input
types
in
it,
it's
an
input
type.
So
there's
a
lot
of
validation
around
that
you
suddenly
have
to
do,
whereas
at
the
moment
it's
very
clear
what
is
in
an
output
type,
so
having
yeah.
B
All
you're,
absolutely
right,
that
is
what
was
previously
proposed.
All
of
that
has
been
put
in
the
bin.
So
now,
when
you
declare
your
tag
to
type,
you
declare
whether
or
not
it
is
an
input
or
an
output
variant.
So
there
is
none
of
this
validation.
There
is
no
dependency
on
the
other
types
in
the
schema.
You
can
look
at
a
tag
type
and
you
will
know
immediately
whether
that
is
an
input
or
an
output
type,
and
there
is
no
need
to
know
what
is
going
on
in
the
rest
of
the
schema.
B
You
basically
have
a
property
there
yeah,
so
we
don't
need
another
keyword.
We
don't
need
an
extra
type
in
the
introspection
system.
We
don't
need
an
extra
like
set
of
fields
for
various
places
and
I
don't
think
adding
those
things
actually
would
give
us
any
value,
because
I
don't
think
that
we
would
want
to
evolve
the
input
and
output
versions
of
tagged
in
separate
ways.
I
don't
think
hopefully
this
won't
come
back
to
bite.
F
F
Yeah,
certainly
the
dynamic
dynamically
determining
whether
that
type
is
allowed
to
be
used
in
an
input
or
output
context
that
always
felt
like
the
most
fragile
piece
of
the
original
proposal,
and
so
I
I
really
like
that.
This
does
away
with
that.
By
making
it
explicit
they,
they
do
kind
of
feel
like
different
kinds
of
things
right
like
when
you
describe
it
at
a
high
level.
F
They
feel
like
the
same
thing,
but
I
remember
the
first
time
going
through
feedback
in
the
the
detailed
out
spec
edits,
the
the
behaviors
of
a
input
tagged
and
the
behaviors
of
an
output
tag
are
are
pretty
different
right
like
they.
Actually
they
do
different
things,
and
and
do
you
do
you
think
it's
like
what
what's
actually
the
cost
of
of
just
we
haven't
attacked
out
the
tagged
input
tag
as
opposed
to
this
sort
of
property
keyword.
F
B
Yeah,
I
think
part
of
the
the
value
of
the
tagged
is,
is
the
intention
that
it
is
effectively
a
stripped-down
version
of
almost
a
an
intersection
of
the
input
and
output
base
object
types,
so
it
only
like
every
you
have
fields
that
don't
have
arguments.
They
have
nullability
broadly
it
kind
of
yeah
that
it
describes
the
same
thing
whether
it
were
an
input
or
an
output.
If
it
only
had
scalars
in
it,
it
would
be.
B
It
would
look
identical
for
both
really
it's
just
whether
you
put
the
input,
keyword
or
output
keyword
next
to
it
potentially
but
yeah.
It
might
make
sense
to
use
different
things
for
it,
and
that
doesn't
necessarily
mean
that
we
have
to
complicate
the
introspection
too
much
for
it
as
well.
For
example,
they
could
both
use
the
the
new
members
field.
I
apologize
about
my
background
noise
if
you're
picking
that
up
so
they
apologize.
H
B
They
may
still
use
the
the
members
field
in
introspection
to
find
out
what
the
fields
are
and
what
their
types
are,
whether
they're
nullable
and
other
such
things,
because
that
works
the
same
for
both
one
potential
issue.
There
is,
of
course,
on
an
output
tagged.
It
only
makes
sense
to
have
output
types,
whereas
on
an
input
tag
it
only
makes
sense
to
have
input
types,
and
it
might
well
be
that
because
of
that,
there
is
some
cascading
logic
that
we
might
need
to
factor
in.
B
I
don't
think
we
need
to
at
this
point,
but
maybe
there's
a
situation
where
that
could
be
an
issue
I
haven't
managed
to
think
it
up,
but
broadly
they
are
similar
like
they
look
the
same
in
sdl
and
I
think
conceptually
they
are
meant
to
be
the
same.
It's
just
one
is
valid
on
input
and
one
is
valid
on
output
but
like
it
would
be
much
clearer
if
we
were
still
allowing
the
both
input
and
output
type
that
they
are
effectively
the
same.
J
The
argument
against
that
is,
I
mean
if
you,
if
you
look
from
from
a
high
level
perspective
on
stl
and
you
take
input,
objectives
and
output
objects
next
to
each
other,
and
you
take
the
arguments
away,
then
they
look
similar,
but
they
are
completely
different.
Things
like
input
is
just
about
providing
raw
data,
whereas
when
you
have
output
types
there's
processing,
there
is
resolving
data,
it's
a
complete
different
functionality,
which
would
change
that
there
is
overlap
both
have
fields,
but
I
don't
think
that
such
overlap
necessitates
that
we
have
like
one
base
type.
B
I
think
one
of
the
interesting
things
about
the
tact
type
is
that
from
an
implementation
point
of
view,
and
obviously
this
will
differ
depending
on
what
programming
languages
you're
implementing
it
with
but
broadly.
It
follows
the
existing
object,
type
and
input
type
logic,
so
validation
works
in
very
much.
The
same
way
resolution
works
in
very
much
the
same
way.
It's
just
simplified.
B
There
is
a
couple
of
extra
clauses
like
it
may
only
have
one
field,
and
that
is
like
one
one
check
and
done
and
obviously
on
the
output
fields
like
it.
They
don't
accept
arguments,
so
you
wouldn't
factor
in
arguments
during
resolution,
but
that's
just
the
same
as
having
no
arguments
which
fields
already
have
so
from
an
implementation
point
of
view.
I
think
it
should
be
relatively
easy
to
implement.
J
Kind
of
kind
of,
because,
if
you,
if
you,
if
your
provider
at
least
it's
in
internet,
it
would
translate
like
a
resolver,
would
translate
into
into
a
method,
whereas
raw
data
just
is
properties,
so
there
are
distinct,
different
things
that
you
have
to
have
there
and
you
I
don't
know
if
it's
a
with
other
languages
like
in
java,
you
don't
have
properties
in
that
way.
So
you
have
functions,
but
then
they
you,
you
would
have
different
functions
like
you
would
have
a
setter
and
a
get
a
function.
B
Yeah,
okay,
I
hear
what
you're
saying,
but
I
don't
think
that
the
the
tag
type
like
necessarily
even
needs
resolvers
like
the
default
resolver,
would
effectively
be
what
you
would
use.
The
idea
is
the
parent
field
returns
an
object
that
conforms
to
the
tag
type
and
then
you
just
return
the
default
field
on
it.
Now
it's
up
to
the
implementation,
whether
they
want
to
actually
go
ahead
and
implement
the
resolvers
just
like
you
would
on
an
object
type,
but
it's
not
necessary.
B
Your
implementation
might
choose
to
do
it
model
it
in
a
different
way
and
that's
fine
and
I
don't
think
the
spec
really
cares
either
way.
How
you
do
that,
but
you
don't
have
to
it,
doesn't
need
resolvers
from
the
point
of
view
of
like
graphql
js,
for
example.
We
just
use
the
default
resolver
and
just
not
give
people
a
way
of
specifying
custom
ones,
potentially.
F
I
know
that
facebook's
union
type
it
may
have
evolved
since
then,
since
I
last
messed
around
with
it,
but
it
had
a
default
resolver
behavior
that
looked
at
the
instance,
type
of
the
thing
that
was
coming
back
and
made
sure
that
that
thing
had
a
matching
graphql
type
and
everything
could
just
kind
of
flow.
F
But
you
could
override
that,
and
you
could
say:
oh
it's
a
union
type,
here's
how
you
resolve
that
to
an
actual
concrete
object,
type
based
on
the
thing
that
comes
back
from
the
underlying
I
expect
we'd
want
to
do
something
similar
tagged.
I
think,
like
there's,
definitely
value
in
keeping
the
the
concepts
the
same
it.
It
means
that
there's
fewer
things
to
teach
right,
even
though
the
behaviors
are
a
little
bit
different
in
input
and
output.
There's
value
there
for
sure.
F
One
thing
I
think
is,
is
a
really
strong
benefit
from
your
proposal
here,
of
making
input
and
output
explicit
is
that
a
implementation
could
actually
decide
to
treat
these
as
two
completely
different
things.
If
it
wanted
to,
you
could
on
the
when
you're
defining
your
schema
in
terms
of
code,
you
could
have
a
input
tag
and
an
output
tag
as
two
completely
different
building
blocks
within
your
schema.
Whereas
before
that
being
a
dynamic
thing,
you
you
couldn't
actually
do
that
you'd
have
to
define
the
rules
for
how
to
do
both
inputs
and
outputs
anytime.
F
You
used
tag
type,
even
if
you
only
intended
it
to
ever
be
used
in
one
example,
and
that's
probably
a
reason
why
that
was
not
the
right
path
to
go
on,
for
I
think
this
resolves
it,
but
I
I
this
is
a
conversation.
I'm
glad
we're
having.
I
I
want
to
make
sure
that
we're
not
missing
something
or
creating
undue
burden
on
implementers
or
consumers
of
these
types
and
making
them
similar.
F
My
sense
is
that
this
ends
up
being
mostly
just
a
semantic
difference
in
in
the
sdl
as
to
whether
you
use
two
keywords
versus
one
merged
keyword
or
something
like
that,
where
it
should
be
relatively
invisible
on
to
most
clients
of
the
server
how
your
servers
are
actually
implementing
it.
F
Another
thought
that
I
had
that
might
be
that
we
might
want
to
talk
through
is
whether
it
ever
makes
sense
to
limit
a
directive
to
only
ever
apply
to
an
output
tagged
versus
an
input
tag.
So
this
is,
I
think
you
have
a
section
in
your
comment
about,
or
maybe
it
was,
the
feedback
earlier
about,
the
the
different
directive
locations
and
seeing
the
tagged
members
being
one
of
those
and
and
that's
useful,
because
you
can.
F
There
may
be
a
case
where
you
want
to
be
able
to
say
something
specific
about
a
tag
member
that
does
not
make
sense
in
the
context
of
an
object
or
an
input
type,
and
it's
so
it's
important
that
you
can
specifically
target
those
things
or
exclude
those
things
for
for
any
custom
directive.
But
would
we
want
one?
B
I
don't
use
directives
heavily,
so
I
am
not
very
good
at
coming
up
with
examples.
I
have
not
come
up
with
an
example
of
that,
yet
one
thing
just
to
slightly
distract
from
that
topic
for
a
moment.
One
thing
that
I
have
thought
about
is
that
at
the
moment
I
think,
on
every
field,
in
a
graphql
query,
you
can
issue
the
the
skip
or
include
directives,
and
while
we
haven't
explicitly
stated
that
you
can
or
cannot
do
that
for
the
tagged
fields,
I
don't
think
it
makes
sense
to
do
that.
B
Perhaps
maybe
it
does,
but
at
the
moment
it's
not
explicitly
allowed
on
on
that
member
target
type.
That
is
an
example
potentially
of
one
where
it
only
makes
sense
on
output
right.
It
wouldn't
make
sense
to
omit
on
skip
sorry
to
skip
something
on
the
input,
but
that
wouldn't
be
where
you
would
apply.
That
kind
of
that
would
be
more
of
a
schema
definition
one
rather
than
a
document
one
you
wouldn't
have
anywhere
to
put
it
in
the
input
document
anyway.
L
Can
I
offer
before
we
go
to
more
details?
Maybe
can
I
offer
more
like
a
fundamental
criticism?
I'm
not
overly
happy
with
business.
I've
seen
to
be
honest,
I
see
the
awesome
work
put
into
and
I
see
how
it
solves.
L
Actually,
the
original
problem
of
input
union
things
quite
satisfactory,
so
this
is
definitely
valid
in
my
opinion
and
and-
and
I
don't
see
strong
opinion
or
strong
reasons-
and
not
to
go
forward
to
solve
the
original
input
union
problem,
but
I
I
I'm
not
convinced
that
I'm
really
worried
about
adding
this
output
type
into
the
mix.
For
two
reasons.
First,
I
must
say
from
practical
schema
design
point
of
view.
Interfaces
versus
union
is
a
real
problem.
L
I
have
to
disagree
with
you
benny
benji,
on
this,
like
I'm,
I'm
working,
I'm
engaging
with
with
teams
as
part
of
my
job
and
one
of
the
yeah
persistent
topics
that
come
up
over
times
always
should
I
model
this
as
an
interface
or
as
an
union
or
as
bose
or
with
an
interface
hierarchy
and
at
the
end
of
the
union.
So
there
is,
there
is
already,
I
would
say,
a
non-clear
schema
design
questions
around
interfaces
first
unit.
L
I
see
this
over
and
over
over
the
years,
so
adding
another
thing
into
the
mix.
What
would
make
this
this
already
problematic
area?
I
must
say
even
worse
so
and
that's
yeah,
so
I
I
would
even
go
so
far
and
I
actually
even
liked
the
the
proposal
I
think
nick
brought
up.
You
mentioned
it
on
the
rc
that
lee
unic
and
dan
discuss
like
interfaces
versus
union
and
nick
actually
proposed
having
like
an
empty
interface
and
non-unions,
and
I
would
even
go
so
far
from
practical
point
of
view.
L
L
I
think
we
are
jumping
a
little
bit
ahead
here
like
we.
We
applied
a
lot
of
scrutiny
to
the
original
ideas
of
input
union,
like
this
huge
effort
over
years
discussing
the
different
proposals
and
it's
an
awesome
work.
I'm
saying
it's
an
awesome,
it's
it's!
It's
it's
great
that
this
community
can
come
to
a
conclusion
after
such
a
long
time,
but
I
feel
like
we
are
applying
here
this,
the
symmetry
argument
quite
easily
and
saying
look.
We
want
to
add
also
like
an
output
option
to
this.
H
L
I
don't
think
we
have
applied
the
same
criteria
to
the
output
idea
as
we
have
for
the
input
one.
So
it
really
feels
like
this
is
like
this
typical
argument,
where
you
want
to
make
it
nice
from
a
design
point
of
view,
because
you
want
to
make
it
symmetric,
but
not
really.
We,
I
don't
think
we
have
invested
the
same
time
of
mind
to
justify
an
output.
L
B
Agree
with
you
and,
as
you
may
have
noticed
from
my
previous
pull
request
with
regard
to
the
query
type,
my
approach
is
go
all
in
and
then
pull
it
back
and
that's
what
I've
done
here
as
well.
So
as
I
as
I
mentioned
at
the
beginning,
I
think
we
may
want
an
output
version
of
this
in
future.
I
actually
quite
like
it,
and
I
would
I
would
like
it
for
my
own
projects.
B
But
again,
as
you
say,
there
is
confusion
between
whether
to
use
it
for
interfaces
or
unions
or
the
tag
type
in
in
outputs
and
yeah.
There's
definitely
discussion
around
that
and
I
think
the
inclusion
of
the
output
version
of
this
in
the
spec
should
be
subject
to
a
separate
process.
Potentially
that
said,
I
think
it
should
be
evaluated
because
this
type
could
support
both.
So
let's
make
sure
that
there
is
a
good
road
forward
to
support
both.
B
Should
we
decide
that
that
is
necessary
and
that's
why
I'm
putting
in
the
effort
at
the
moment
to
make
sure
that
we're
not
making
decisions
that
are
going
to
cause
us
problems
if
we
later
want
to
introduce
this
type
to
output?
B
So
I
don't
think
that
this
proposal
at
the
moment
is
saying
that
both
types
will
be
added.
It's
more
saying.
This
is
what
it
would
look
like
if
both
were
added
and
probably
towards
the
end,
we'll
trim
out
the
output
type,
because
it
is
controversial
and
we'll
then
potentially
have
a
separate
push
to
then
open
it
up
to
output.
B
I
agree
with
you.
Interfaces
and
unions
are
challenging
and
I
think
in
most
cases
I
would
probably
choose
the
the
tag
type
over
the
union
type.
I
think
interfaces
are
broadly
very
useful,
whereas
the
union
is,
as
you
say,
it's
like
an
interface
with
no
fields,
and
I
think
using
the
tag
type
in
that
place
in
most
cases
would
probably
make
sense.
B
I
do
worry
that
it's
kind
of
pushing
us
down
the
the
the
const
let
versus
var
nobody
uses
var
anymore
kind
of
root,
and
it's
maybe
a
bit
early
in
graphql's
lifetime
to
do
that
and
there
are
still
advantages
to
to
union.
So
it
is
not
clear-cut
but
yeah,
as
you
say,
if
it
had
only
ever
been
interface,
and
now
we
were
introducing
tag
type
to
the
output.
I
don't
think
it
would
be
particularly
controversial.
It
is
because
of
the
existence
of
union
that
is
the.
F
Issue
you
put
that
really
well
benji,
I'm
I'm
happy
that
you
are
exploring
it
in
this
way
and-
and
I
think
it's
probably
wise
to
eventually
cut
this
in
half
and
so
that
there's
two
separate
proposals
moving
forward,
but
it's
it's
very
smart
to
consider
them
as
part
of
a
overall
vision,
because
I
think
it's
it's
it's
problematic
to
really
get
narrow
and
avoid
the
context.
L
G
B
I
hope
it's
it's
better
now,
because
we
we
get
the
youtube
uploads
afterwards.
So
if
there
is
anything,
just
put
some
question
marks
in
there
and
we
can
go
back
through
the
video
afterwards
jump
to
the
relevant
point
and
hopefully
pull
it
back
out.
B
I
haven't
done
that
yet
because,
obviously
I
don't
have
enough
time
to
then
go
and
watch
the
working
group
twice,
but
I
think
what
would
be
really
excellent
is
if
we
started
somehow
adding
timestamps
to
the
notes
as
we
took
them.
That
would
allow
us
to
very
easily
reference
the
relevant
point
in
the
in
the
youtube
video.
I.
J
Actually,
I
actually
never
use
the
notes.
I
straight
now
go
to
the
video,
because
the
the
the
notes
sometimes
are
too
compressed
and
it's
I
think
it's
great,
that
we
have
the
video.
B
B
But
yeah
definitely
the
video
is
the
source
of
truth.
So
now
we
have
those
reference
that
sorry
andy.
L
L
O
G
C
Yes,
have
some
background
on
that,
so
I
wasn't
sure
I
have
access
to
zoom
graphic
foundation
so,
but
I
wasn't
sure
about
like
limits
and
why
can't
we
actually
publicly
share
it.
So
I
shared
like
transcripts
video
with
transcripts
with
benji,
but
now
I
have
information
from
brian
that
we
can
actually
share
zoom
recording
with
automatic
transcript
publicly.
C
But
one
thing
that
brian
warned
us
about
is
that
we
should
not
depend
on
them
in
documents,
because
graphical
foundation
have
like
storage
limit
for
zoom
account.
So
at
some
point
all
videos
will
disappear.
C
J
That's
what
I
that's,
what
I
actually
will
see
hot
chocolate
community
stand
up.
We
do
that
just
put
to
youtube
and
then
share
the
youtube
link.
Then
you
can
even
even
skip
to
the
right
time
and
say:
okay.
J
B
To
the
the
videos
from
the
notes
now
and
from
the
agendas,
what
I
found
with
the
with
the
transcription
is,
it
is
of
mixed
utility.
Sometimes
it's
really
good,
and
sometimes
it
is
just
gibberish
so
yeah.
I
think
I
think
there
is
there's
value
in
taking
the
notes,
I
think,
and
particularly
where
the
notes
manage
to,
as
you
say,
compress
the
content
down
it
can
help
you
get
the
gist
of
a
conversation
without
actually
having
to
read
through
or
watch
through.
B
The
entire
conversation,
often
scanning
with
your
eyes,
is
a
lot
quicker
to
find
the
information
you're
after
than
having
to
skip
through
a
video.
J
But
let's
yeah
sorry
candy
go
ahead.
L
Lee
shared
in
the
krafka's
leg
room
that
his
internet
died,
so
I'm
not
sure
how
quickly
he
will
come
back.
But
let
me
try
to
finish
his
thought,
his
train
of
thought.
I
think
he
was
referring
to
that.
It's
really
helpful
to
have
the
overall
vision
of
the
tech
types
like
outlined
and
and
considered,
and
I
think
this
is.
I
agree
with
him
that
looking
at
looking
at
the
solution
from
a
holoistic
point
of
view
makes
sense
that
we
don't
miss
anything
moving
forward.
I
think
this
was
also
your
idea.
L
Benji
right,
yeah,
absolutely
yeah.
So
I
think
that's
really
important,
but
I
would
actually
ask:
can
we
kind
of
formulate
this
vision
outside
of
the
rfc
like?
Do
we
have
a
concise
vision
about?
L
I
don't
know,
concise
input
versus
output
types
or
like
like
a
bigger
union
type
or
like
what
is
actually
the
vision
we
are
trying
to
have
like?
Is
this
any
were
written
down
or
suggest
in
your
head
when
you're
on
lee's
head
or
maybe
we
we
could
try
to
kind
of
separate
this
vision
from
the
implementation
of
these
types
and-
and
you
have
have
in
this
way
a
better
picture.
B
Well,
you
can
boil
my
vision
down
to
what
I
said
about
a
year
and
a
half
ago,
which
is
why
don't
we
just
take
the
input
and
output
types
and
only
let
them
have
one
field.
That
is
my
vision,
and
this
is
an
implementation
of
that
vision,
and
that
is
you
know.
We've
got
to
the
point
where
we've
evaluated
this
idea
of
having
one
field
against
all
the
other
options
for
input
unions,
and
we
found
that
the
one
field
idea
is
currently
the
leading
idea.
But
that's
all
the
vision
is
now
it
is.
B
How
do
we
turn
this
vision
into
a
reality,
and,
as
part
of
that,
you
know
we're
writing
the
spec
edits
and
we're
seeing
what
the
knock-on
consequences
are
and
we're
thinking
about
what
the
effects
are
going
to
be
on
introspection,
what
the
effects
are
going
to
be
on
code
generation
on
writing
the
implementation,
as
michael
quite
rightly
pointed
out,
there
are
complexities
there
and
we
want
to
make
sure
that
we
address
all
of
those
things
so
yeah.
It's.
L
Maybe
there's
another
vision,
maybe
that's
only
nice
had
that
the
input
types
should
be
quite
symmetrical
to
the
output
types
in
terms
of
capabilities.
Maybe
that's
another
vision
or
goal
or
or
like
some
aspiration.
We
have.
You
know
like
the
symmetry
aspect.
If
you
add
it
to
the
input,
it
should
be
similar
feature
or
capability
should
be
in
the
output
types.
B
Yes,
I
think
that
is,
as
as
you
say,
like
as
many
people
point
out.
This
is
one
of
the
solutions
that
was
thrown
in
with
the
the
input
unions
lot,
which
makes
sense
because
it
solves
input
polymorphism,
but
it
it
was
always
a
bit
of
an
outlier
in
the
input
unions
thing
because
it
is
more
of
a
it's,
not
really
a
union.
It's
a
you
know
it's
a
tagged
type,
which
is
not
really
a
union
anywho
but
yeah.
B
There
is
this
this
separate
idea
of
the
of
the
symmetry,
and
that
is
something
that
we
already
kind
of
have
with
input
and
output
types.
B
So
having
symmetry
keeps
that
you
keep
reduces
the
number
of
like
mental
gymnastics,
you
have
to
do
when
moving
from
from
output
to
input,
or
vice
versa.
So
I
think
symmetry
is
is
desirable.
I
don't
think
it
is
necessarily
100
necessary,
like
it
is
a
nice
to
have
but
yeah.
I
think
I
think
that's
probably
a
goal
yeah
that
answers.
J
Although
I
have
to
say
that's
most
of
the
times
how
users
start
with
it
thinking
symmetry
is
thinking,
then
in
patch
commands,
where
they
send
in
the
user
object
as
is
and
trying
to
patch
changes
into
the
database,
but
as
soon
as
schemas
grow,
they
are
mostly
going
away
from
that
and
applying
more
other
concepts,
more
specific
mutations
and
really,
if
you
send
in
a
user,
you
you
and
you
have
a
friends
list,
then
you
might
send
in
the
friends
ids,
which
is
then
a
completely
different
field
than
on
the
output.
J
So
as
as
soon
as
you
go
into
bigger,
schemas
and
more
mature
projects,
this
is
not
true
anymore.
I
would
say.
F
I
agree
I
like
that
way
of
thinking
about
that,
michael
of
of
starting
with
the
tight
symmetry,
but
allowing
space
for
them
to
diverge
when,
when
you
need
them
to
it's,
actually
in
hindsight,
I'm
really
happy
with
how
input
objects
and
output
types
work,
because
they
they
do
have
a
lot
of
symmetry.
They
both
have
fields,
it's
easy
to
think
in
terms
of
both
of
them
as
as
being
very
similar,
and
only
when
you
get
into
the
details.
F
Do
you
realize
how
how
they
can
be
quite
different,
and
I
think
that
that's
the
thing
that
feels
most
annoying
about
our
existing
union
type
and
all
the
proposals
we've
had
so
far
with
input
unions
is
that
the
trying
to
apply
symmetry
like
a
symmetric
approach
to
input
unions
that
starts
with
our
output
unions
is
just
really
unsatisfying
and
and
that's
not
great,
and
I'm
I'm
really
happy
to
see
the
parallel
exploration
of
inputs
and
outputs.
F
So
we
can
address
input,
unions
or
input
tags
as
a
as
an
independent
thing
and
resolve
those
and
and
kind
of
close
this
multi-here
saga,
as
as
andy
framed
it
up
and
then
provide
some
space
for
for
treating
in
or
output
tag
types
on
its
own
merits,
and
you
know
I
think,
there's
certainly
more
discussion.
We
want
to
have
there
and
I
don't
think
we
want
to
hold
up
and
put
tags
on
on
resolving
all
of
those
and
giving
it
its
own.
F
Space
will
be
a
worthwhile
thing,
but
one
thing
is
pretty
clear,
which
is
we
it's?
It's
really
valuable
to
have
the
space
for
that
to
have
some
symmetry.
So
one
thing,
that's
pretty
clear
is,
is
you
know,
naming
this
tag
type
in
a
way
that
doesn't
explicitly
make
it
only
ever
an
input
type
so
making
it
input,
tags
or
tag
input
or
something
like
that
and
the
syntax
is,
is
pretty
smart
in
my
opinion,
because
it
makes
it
they.
F
It
provides
some
room
for
us
to
explore
that
design
space
on
the
output
side,
and
I
also
think
that
you
know
if,
if
we
were
going
to
rebuild
graphco
from
scratch
from
first
principles,
my
personal
opinion
is
we'd.
Probably
go,
do
something
with
tag
types
instead
of
union
types.
Now
that
we
kind
of
know
how
people
use
them,
because
I
kind
of
agree
with
all
the
kind
of
usability
pain
points
that
you've
pointed
out
so
far.
F
But
I
want
to
make
sure
we
have
some
time
so
we're
going
to
move
forward
on
our
agenda
and
do
an
update
on
the
graphical
js
working
group.
So
uri
and
yvonne
I'll
hand
it
to
you
both.
C
If,
if
food
is
not
available,
I
can
do
it
myself
so
and
already,
if
you
like,
have
microphone
issues
or
something
you
can
interrupt
me
at
any
time.
So
basically,
core
issue
was
finding
a
way
how
to
how
to
communicate
with
people
who
want
to
help
and
become
maintainer
and
have
like
onboarding
experience.
C
So
we
had
graphql
graphql.js
working
group
call
is
recorded
on
youtube
and
couple
people
want
your
to
help.
So
I
didn't
advertise
this
code
too
much
because
I
feel
like
we
need
to
start
with
some
number
of
people
and
one
grow
it.
So
it
was
mostly
a
couple
of
people
and
the
guild
members
and
people
who
want
here
to
help
with
like
treasury
issues
like
trajan
and
categorizing
them
or
like
creating
road
maps.
C
I
think
it's
like
risk.
In
a
sense,
it's
risk-free
because
it's
not
changing
the
rules,
I'm
not
publishing,
not
changing
code
or
not
publishing
new
package.
So
it's
like
everything
can
be
reversed.
So
I
just
went
ahead
and
I
touch
everybody
who
was
interested.
I
give
them
trash
rules
and
we
will
see
how
this
experiment
will
go.
C
C
Actually,
like
one
one
issue
is
kind
of
interesting
and
I
don't
feel
like
I'm
empowered
to
make
this
decision,
but
should
we
have
a
common
policy
for
embodying
new
maintainers
because
we
write
this
question,
so
is
that
like
there
is
free
option,
we
have
like
rules
for
onboarding
new
maintainers
on
on
one
one
set
of
roofs
for
all
foundation
projects
like
every
project
through
working
group
decide
on
its
own
or
we
just
like.
C
Have
it's
like
it's
too
early
and
we
can
be
pretty
flexible
and
do
it
on
case
by
case
basis?
So
it's
a
question
actually
like
hi
ora,
so
yeah.
C
Oh
okay,
yeah!
So
it's
a
question.
I
I
feel
like
I'm,
I'm
not
the
right
person
to
ask
answer
myself:
yeah,
because
it's
like
generic
one.
So
really
what
do
you
think
about
what
or
like
what?
What's
the
mechanism?
C
F
F
If
we
get
to
the
point
where
there's
a
lot
of
new
maintainers
showing
up
across
a
bunch
of
projects,
then
I
don't
want
to
be
in
the
position
to
like
personally
approve
each
of
them
because,
like
I'll
just
become
a
roadblock
and
that
won't
be
valuable
for
anybody
and
even
delegating
that
across
some
committee,
maybe
that's
like
a
part
of
the
technical
steering
committee's
job
or
something
like
that.
It's
like
it
takes
it
off
of
my
head,
but
it
just
moves
it
onto
the
head
of
a
like
organization,
and
so
that'll
still
create
roadblocks.
F
F
So
if
the
folks
who
are
currently
maintainers
of
graphql
gs
feel
like
somebody
would
be
a
valuable
additional
maintainer
to
graphql
js,
then
by
all
means,
that's
that's
your
project
to
manage
and
do
that.
If
there's
questions,
concerns
or
decision
can't
be
made,
then
I
think
it's
reasonable
to
raise
that
to
this
group
or
to
somebody
else
within
the
foundation.
F
C
C
Like
side
note
about
volume
of
new
contributors,
but
I
actually
I
didn't
like
new
contributors,
like
I
added
caroline
as
part
of
season
of
docs
and
for
graphql
http,
as
I
added
like
two
new
contributors
and
one
another
issue
I
wanted
to
discuss.
C
We
just
remove
him.
Is
that.
F
Yeah,
some
of
these
projects
are
on
a
slow
cadence.
Graphql.Js
is
pretty
proactively
developed,
but
some
of
the
other
ones
are
are
less
so
and
if
those
are
the
ones
that
people
can
kind
of
like
have
a
background
process,
maintenance
of
that
can
be
okay.
A
year
sounds
fine
to
me.
I
think
it's
also
reasonable
for
it
to
be
on
judgment,
but
if
you
want
to
have
a
written
role
so
that
you
can
kind
of
point
to
something
and
say
here's
here's
when
we
send
these
out,
I
think
that's
fine.
C
So
let's
address
another
action
item
because
we
have
like
660
contributors
on
graphql
js
and
I
might
kind
of
feel
like
the
more
people
we
had
the
more
unmanageable
it
would
become
some
security
implications,
so
yeah,
okay,
so
I
think
I
had
all
inputs
on
all
action
items
I'm
like
on
me
at
the
moment
by
the
way,
if
woody
or
somebody
else
is
interested
in
helping
with
writing
template
for
sending
to
his
people.
C
I
feel
like
it
probably
should
still
be
me,
because
I
will
remove
them
if
they
say
okay
but
like
it
will
help
me
what,
if
right,
because
it
should
be
like
polite
and
with
good
explanation
so
yeah.
If
somebody
interested
in
helping
to
writers
like
notice,
we
can
use
it
across
other
projects,
so
yeah,
it's
everything
on
my
side.
Maybe
we
have
some
some
other
items.
K
Yeah
thanks
and
sorry
for
that,
my
sound
didn't
work
at
the
beginning,
yeah.
First
of
all,
thanks
even
for
making
this
working
group
happen,
it
was
really
exciting
and
I'm
happy
with
starting
it.
I
think
the
most
important
thing
is
that
we
could
make
it
maybe
a
regular
cadence
so
like
maybe
each
month
or
something
like
that,
so
we
know
already
like
when
the
next
meeting
would
be,
and
then
we
can
check
up
on.
You
know
the
tasks
for
it
accordingly
and
see
that
we
make
progress.
K
I
think
the
for
me.
There
were
like
three
biggest
topics
during
the
working
group.
One
was
like
two
of
them
related
to:
let's
call
it
the
boss
factor
like
one
is
like
meaning
one
is:
how
can
we
make
even
your
work,
better,
meaning
like
a
list
of
all
the
things
that
we
need
to
do
be
in
order
to
minimize?
K
You
know
that
you
will,
when
you
get
something
to
review
or
to
do
something
you
have
as
little
work
as
possible.
So
there
are
some
tasks
on
that
and
the
other
one
is
like.
Can
we
get
more
events
like?
Can
we
increase
actually
like
and
get
more
people
that
also
can
review
and
can
commit
and
everything,
and
I
think
there
is
like
yeah,
so
we
we
have
a
bunch
of
tasks
from
there
as
well.
All
those
tasks
are
now
documented
in
the
working
group
issue.
K
K
You
know
the
work
itself,
which
is
you
know,
and
I
think
currently
what's
the
most
needed
thing
is
actually
kind
of
a
clear
roadmap
of
because,
because
there's
a
lot
of
people
who
want
to
contribute,
I
think
us
as
being
one
of
them
and
we
just
and
we
some
of
them
are
like
in
progress.
There's
a
lot
of
changes
that
we're
making
and
I
think
currently
because
of
the
bus
factor,
we're
not
sure
exactly
we're
up
to
doing
more
work.
K
Just
more
work
for
you
because
now
you're
the
main
person
there
and
you
know
you
know
you-
have
the
perspective
and
you're
the
one
who
needs
to
say.
You
know
this
is
ready
or
not
ready,
hopefully
well
after
this
first
wave
of
tasks,
there
will
be
less
more,
it
will
actually
lead
to
having
less
work
and
less
like
stress
over
you,
and
we
could
like
share
more
of
that
work
together,
but
yeah
other
than
that.
I
I'm
just.
I
was
very
happy
that
it
happened
and
I'm
excited
for
the
next.
C
Meeting
I
want
to
share
some
perspective
and
actually,
I
think,
it's
helpful
for
other
foundation
projects.
It
was
couple
of
iterations
of
trying
to
onboard
more
people
and
the
things
that
I
learned
is
this
free
think
actually
connected,
and
you
need
to
do
them
in
proper
order.
C
So
if
you
just
put
publicly
that
you
need
help
with
something,
but
you
don't
have
contribution
guides
or
you
don't
explain
like
it's
put
a
lot
of
preview
and
effort
on
you
and
since
and
after
that
express
contribute
for
a
long
time
and
this
demotivate
people
who
contribute
it's
the
same
thing
it's
like
with
like
on
boarding.
C
So,
like
first
thing,
I
will
work
on
is
to
to
define
what
expect
from
prs,
because
if
I
just
advertise
my
need
help
something
it
will
just
like
overflow.
My
review
capacity,
but
I
totally
agree
with
you
so
true
solution
of
buzz
factor
is
actually
have
more
people.
It's
not
more
effective
previewing
process
for
a
person
for
me
like
at
that
at
this
moment
of
math,
it's
more
for
having
having
more
contributors
through
solution,
but
in
this
bootstrap
process,
I'm
like
bottleneck
at
the
moment.
C
F
Sounds
like
a
great
update.
It
looks
like
you
guys,
have
good
next
steps
on
meeting
more
regularly
and
and
adding
more
maintainers
to
offload
the
bus
factor
from
yvonne
thanks
for
the
update
cool
that
is
all
of
our
agenda,
any
additional
things
you
want
to
talk
about
in
the
few
minutes.
We
have
remaining.
C
I
want
to
to
have
some
some
like
some
announcement
and
brought
to
new
people
as
maintainers
of
and
morris
actually
here
on.
This
call
so
graphql
http
and
we
plan
to
do
experiment
on
doing
asynchronous
working
group.
So
more
stuff
is
done
asynchronously
instead
of
on
the
calls,
and
we
will
see
how
it
work
and
we
can
share
after
that,
we
can
share
experience
with
other
working
groups,
because
at
the
moment
we
already
have
like
four
different
working
groups,
so
yeah
interesting
experiment
to
try
to
do
it.
Asynchronously.
J
And
with
asynchronously
you
mean
you're
working
on
the
issues
rather
than
meeting
up.
Okay.