►
From YouTube: GraphQL Working Group - September 3, 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
All
right,
we'll
hang
out
for
a
couple
minutes.
While
we
wait
for
everybody
else
to
to
join
in.
C
D
E
A
Just
in
the
last
minute
I
I
merged
the
one
that
added
you
to
the
attendee
list.
I
don't
know
if
you
have
an.
A
A
A
But
we
have
a
lot
of
really
interesting
things
to
talk
about
today,
so
first,
as
we
always
do
kicking
off
with
a
reminder
that
by
joining,
we
all
agree
to
the
membership
agreement,
participation,
guidelines
and
code
of
conduct
links
are
in
the
agenda.
If
you
ever
want
a
refresher
on
what's
in
those
things
and
let's
go
around
and
put
names
to
faces,
introduce
each
other,
we
will
go
in
the
order
that
it's
listed
in
the
agenda
and
take
this
as
an
opportunity.
A
D
C
J
E
Hi,
I'm
benjy.
I
work
on
the
grapho
suite
of
open
source
projects
and
I'm
also
working
on
the
tact
type
in
graphql.
K
Hi
I'm
dutan,
I'm
from
the
guild
and
ori
from
the
guild
is
also
here
with
us
he's
not
listed,
but
he's.
G
Yeah,
I'm
muy
not
a
lot
to
add.
We
maintain
a
couple
of
open
source
staff
and
also
our
members
in
the
foundation.
Great
add
yourself
to
the
agenda
yuri,
oh
yeah,
all
right!
Well,
thanks.
L
N
B
Yeah
but
I
actually
did
a
pull
request,
but
I
somehow
dropped
out,
but
I'm
michael
stype,
I
work
with
teddy
cream
and
we
are
working
on
the
net
implementation
of
chocolate.
A
I
I
probably
had
a
bad
merge
commit
at
some
point,
michael
sorry
about
that
feel,
free
to.
A
All
right
well,
thank
you,
everybody
glad
to
see
a
bunch
of
familiar
faces
and
a
handful
of
new
ones.
Let's
take
a
quick
look
at
our
agenda.
Oh
we
should
make
sure
we
have
good
coverage
on
note.
Taking
benji
is
our
perennial
excellent
note
taker?
Does
anybody
want
to
volunteer
to
help
out
benji,
especially
when
he's
taking
part
in
discussion.
A
Okay,
let's
take
a
quick
look
at
our
agenda
and
make
sure
that
everything
here
are
the
things
we
want
to
talk
about
today,
we're
going
to
talk
about
deprecation
of
inputs
from
evan
the
typescript
migration
process
from
doton
and
yvonne,
perhaps
figure
out
the
details
of
bootstrapping
at
graphql
js
working
group
evan's,
going
to
talk
about
some
github
infrastructure
for
helping
manage
our
working
groups.
A
E
I
just
wanted
a
quick
note
to
say
thanks
everyone
for
your
feedback
on
the
tag
type.
If
anyone
hasn't
given
feedback
and
would
like
to
please
do
so.
I
have
updated
the
the
spec
based
on
some
of
the
feedback,
but
there's
still
more
work
from
me
required.
So
that's
why
it's
not
an
agenda
item.
D
From
apart
from
that,
I
wanted
to
get
some
clarifications
regarding
this
back,
so
I
had
some
specific
questions,
so
I
will
just
discuss
them
at
the
end
of
the
meeting.
Okay,
thank
you.
F
F
So
it's
actually
a
very
helpful
work
and
we
started
crafty,
seasonal,
docs
participation
and
we
have
carolyn,
you
probably
know
so
from
grakier
she's,
very
active
in
graphql
ecosystem,
and
she
will
help
with
frequently
asked
questions
on
graphql.org
and
as
a
community
born
in
period.
She
actually
took
effort
of
trashing
stuff
and
like
merging
so
a
lot
of
progress
on
graphql.org
and
also
if
you
want
to
help
like
subscribe
to
grackel.org
repo,
and
please
review
frequently
asked
questions
vrs
yeah.
She
will
start
in
a
couple
weeks.
F
A
That's
awesome,
that's
our
documentation
website
is
sort
of
always
behind
where
we'd
all
like
it
to
be
so.
I'm
super
excited
that
we're
getting
summer
code
and
season
of
doc's
folks
attention
on
it.
Thanks
yvonne
for
helping
mentor
those
people-
and
I
I
just
kind
of
want
to
highlight
that
that's
an
area,
I'd
love
to
see
continued
investment
in.
So
if
anybody
has
additional
ideas
for
how
we
could
improve
that
or
if
they
know
of
anybody
who's,
you
know
excited
about
docs
and
championing
our
documentation
over
the
long
term.
A
F
A
All
right,
that's
our
agenda.
I
don't
know
if
we
translated
last
meetings,
action
items
to
issues,
I
don't
think
we
did-
I'm
not
going
to
spend
too
much
time
working
through
action
items,
because
there's
only
a
handful
of
major
ones
that
we
need
to
follow
up
on
one
I'd:
I'd
love
a
volunteer
either
benji
or
evan.
I'll.
A
Look
to
you
both
of
incorporating
all
of
the
sort
of
decision
making
that
happened
in
over
the
last
couple
of
months
on
input
unions
in
our
working
groups
or
vince
those
we
we
have
video
recordings
of
those.
I
think
there
was
just
a
bunch
of
open
issues
to
track
those
decisions
on
the
the
input
union
roc.
A
E
N
I'm
happy
to
take
it
on
as
long
as
there's
not
any
expectation
that
it
will
get
done
soon,
because
I'm
also
quite
busy
at
the
moment,
but
I'm
happy
to
get
to
it.
Like
middle
of
september.
A
No
expectation
of
it
being
done
soon.
I
was
just
kind
of
looking
through
their
our
issues
and
saying
that
we
logged
those
in
may.
So
you
know
if
we
can
get
it
done
before
the
end
of
the
year,
I'll
be
happy,
I'm
sure
you'll
be
able
to
to
exceed
my
expectations
in
that
capacity,
but
yeah.
Thank
you
for
for
volunteering
to
take
point
on
that
and
shout
if
you
need
any
particular
help.
We
can
also
kind
of
chop
it
up
and
make
progress
on
it.
A
That
way,
I
just
want
someone
to
own
it.
The
the
other
piece
is
on
me,
which
is
cutting
a
version
of
the
spec.
This
is
on
me
and
and
brian
our
program
manager
we're
still
finalizing
like
there's
a
long
tail
of
people
who
haven't
signed
membership
agreements
who
have
contributed
to
the
repo
over
the
last
two
years
that
brian
is
chasing
down
like
that.
That's
truly
the
thing:
that's
keeping
us
from
cutting
the
spec.
We
want
to
make
sure
that
this
one
is.
A
This
would
be
the
first
cut
within
the
graphql
foundation
and
we
want
to
make
sure
we're
doing
it.
Sort
of
by
the
legal
books
that
we
set
out
for
ourselves,
so
that's
the
reason
for
the
delay
there.
A
But
when
I
talked
to
him
last
week
we
had
made
significant
progress,
so
I'm
really
hoping
that
we
can
resolve
this
relatively
soon.
E
I
A
E
A
It's
coming,
this
one
is
also
on
brian
he
he
promised
that
he
would
put
this
in
place
and
he
knows
exactly
the
technology
he
wants
to
do.
The
thing
that
he
he
wants
to
get
in
place.
First
is
front
load
that
tool
with
a
bunch
of
already
signed
membership
agreements.
That
way
for
the
handful
of
you
who
are
routinely
contributing
to
the
repos
and
routinely
showing
up
to
these
meetings.
A
You
don't
have
like
an
additional
point
of
friction
where
you
have
to
resign
it,
especially
for
people
who
their
their
signatures
is
from
their
like
corporate
body,
instead
of
them
as
an
individual,
like
that's,
really
annoying,
to
have
to
figure
out
how
to
go
re-litigate
with
whoever
your
legal
representative
is
so
he's
making
sure
that
that
tool
gets
front
loaded
with
all
those
first
and
like
links
it
up
with
everyone's
github
usernames.
A
That
way,
ideally
most
of
everybody
on
this
call
who's
pretty
regular
contributors,
just
won't
even
notice
that
the
tools
introduced
and
instead
it'll
just
be
newcomers
it'll,
just
be
a
gut
check
to
make
sure
that
they've
done
that,
but
that
will
dramatically
improve
the
goal
is
basically
to
line
up
the
introduction
of
that
tool
with
the
time
that
we
cut
the
spec
that
way.
Next
time
we
cut
the
spec.
This
is
a
non-issue.
F
I
also
have
a
question
I
measured
stuff
into
spec
from
time
to
time,
especially
like
mostly
like
editorial
stuff
or
internal
stuff.
I
saw
or
rfc
stuff.
So
I
don't
want
to
step
on
your
brand
tools
in
this
process.
So
if,
at
some
point
you
need
to
just
stop
merging
stuff
like
just
being
me
or
create
an
issue.
A
Okay,
good
to
know,
I
I
think
you're,
probably
fine
at
the
moment,
if
you
spot
that
those
changes
are
coming
from
new
contributors,
then
maybe
just
flag
that
to
brian
in
particular-
and
you
can
just
ping
him
on
slack
and
and
let
him
know
that
you
haven't
seen
that
particular
person
contribute
before
and
he
can
double
check
that
they've
signed
their
agreements.
So
you
can,
you
can
be
the
human
version
of
the
the
bot
that
benji
was
talking
about
in
the
short
time
most
of
most.
F
A
Well,
first
of
all,
that's
a
great
thing.
That's
a
great
problem
to
have
that
we
have
a
bunch
of
contributors
to
the
spec,
but
yeah.
I'm
glad
you
brought
that
up
so
make
sure
that
you
flag
new
contributors
to
brian
before
you
merge
their
pull
requests.
That
way,
you
can
double
check
that
they've
signed
a
membership
agreement
or
you
can
also
just
kind
of
proactively
ask
in
the
pull
request
you
can
just
ask
like
hey.
Just
checking.
F
N
Thanks
lee
yeah,
I
don't
have
a
whole
lot
to
add
to
what
I
left
in
in
my
comment
yesterday.
I
don't
know
if
everybody's
had
a
chance
to
read
that,
though
so
I'll
summarize.
N
N
Originally,
one
of
those
was
that
deprecations
are
intended
to
be
actionable,
and
so,
if
the
input
is
required,
then
you
can't
really
migrate
away
from
it,
and
the
other
is
that
introspection
does
not
include
deprecated
objects
or
things
members.
I
don't
know
by
default,
which
could
break
tooling.
That
is
now
no
longer
receiving
required
arguments
as
part
of
their
introspection
response.
I
shopify
has
a
vested
interest
in
being
able
to
deprecate
required
things.
N
We
have
a
use
case
for
that,
so
I
would
volunteer
to
look
into
these
and
look
into
our
use
case
and
see
kind
of
what
took
out
for
the
initial
for
the
first
problem
of
deprecations
being
actionable.
I
don't
really
think
that
ends
up
being
much
of
a
blocker.
N
There
are
just
there
are
cases,
even
apart
from
shopify's
use
case,
where
the
action
that
comes
from
a
deprecation
doesn't
happen
inside
the
schema,
and
so
it
doesn't
make
sense
to
block
it
on
that
front.
However,
the
second
problem
of
introspection
is
a
much
bigger
one.
N
I
do
still
think
that
graphql
should
support
deprecating
required
inputs,
and
so
my
suggestion
was
that
we
slightly
change
the
rules
for
introspection
and
have
introspection
return
required
arguments,
even
if
they
are
deprecated
on
the
theory
that,
like
introspection,
should
always
give
you
back
the
stuff.
That
is
absolutely
unnecessary,
even
if
you
say
you
don't
want
it.
N
If
so
that
was
kind
of
my
first,
I
wanted
to
float
that
to
the
group.
I
know
it's
a
bit
of
a
weird
proposal,
but
I
wanted
to
see
what
people
thought
of
that
idea
of
just
working
around
this
problem
by
changing
the
rules
for
introspection
a
little
bit.
E
So
since
this
is
a,
this
would
be
a
new
argument
being
added
to
the
input
fields
on
the
the
type
type.
So
I
don't
see
any
major
issue
with
omitting
only
the
nullable
deprecated
fields,
but
I
think
maybe
the
name
of
that
field
might
make
sense
to
be
something
other
than
include
deprecated,
because
that
very
explicitly
says
whether
or
not
you
should
include
deprecated.
E
N
E
N
N
The
include
deprecated
argument
to
introspection,
where
is
that
actually
placed
in
the
introspection
query
like
it's
benji
suggested
that
this
we
would
basically
have
to
add
it
to
input
args
again,
a
parallel
version
to
the
one
on
outputs,
and
so
we
could
just
call
it
something
else
which
is
actually
like,
really
nice
and
simple.
If
that's
the
case.
E
I've
linked
in
the
chat
to
the
relevant
part
of
the
spec,
but
yes,
it's
added
to
the
fields
and
enum
values
field
within
the
dunder
type
type
in
introspection,
so
you're,
effectively
proposing
adding
another
argument
to
the
input
fields
field
on
the
dunder
type
type.
E
So
you
need
to
add
an
argument
there
anyway.
So
I'm
just
proposing
whatever
argument
you
add
might
not
need
to
have
the
same
name
as
the
previous
ones.
N
Well,
that's
a
good
point.
Actually,
we
don't
technically
need
to
add
an
argument
there.
I
mean
it
would
be
nice
for
consistency,
but
if
we
can't
come
up
with
a
name,
we
could
also
just
say
you
always
get
all
of
your
inputs
back
and
introspection
doesn't
provide
that
option.
I
didn't
even
realize
that
those
were
separate.
I
thought
it
was
a
single
flag
that
controlled
the
entire
introspection
output.
K
Maybe
I'm
missing
something
but
just
a
question:
why
can't
you
just
introspect
and
then
transform
the
result
into
whatever
you
need?
I
mean
you
have
all
the
data
and
all
the
details.
You
can
just
change
the
introspection,
result,
remove
fields
and
change
the
json
structure.
According
to
your
needs,
I
mean.
Maybe
I'm
missing
something,
but
it
sounds
like.
N
I
N
N
N
That's
certainly
the
simplest,
the
simplest
solution
and
it
addresses
this
problem
as
well-
is
that
those
values
don't
kind
of
recurse.
They
apply
to
the
immediate
return
value
of
that
field
and
not
too
many
of
its
children.
So
if
any
arguments
come
back,
you'd
have
to
explicitly
ask
or
include
deprecated,
actually
benji
the
other
option.
Besides
renaming,
it
would
just
be
to
change
the
default
value
so
include
deprecated
defaults
to
true
for
inputs
instead
of
false,
and
that
provides
kind
of
a
more
more
structural
consistency
with
the
other
version
of
that
argument
seems
reasonable.
E
N
Do
yeah,
I
think,
in
that
case,
if
we
change
the
default,
then
we
can
make
it
do
what
it
says
on
the
tin
and
if
you
have
asked,
if
you
don't
include
deprecated
and
you
are
missing,
some
arguments
then
deal
with
it.
It
was
your
what
you
explicitly
asked.
F
So
I
have
a
general
question
about
breaking
changes
so
currently,
in
our
design
principle,
we
promised
not
to
break
existing
clients
like
if
we
just
update
to
queries
from
existing
coins,
so
my
interpretation
of
that
was,
if
you
just
update
like
graphql,
js
or
any
other
library,
everything
should
work
as
it
work
unless
you
start
explicitly
using
new
feature
so
like,
if
ipad
owner
decide
to
deprecate
to
start
using
new
feature.
In
this
case,
it's
like
duplicating
arguments
or
input
fields,
it's
okay.
F
A
N
I
was
just
saying,
I
think
the
problem
from
our
perspective
is
that
it's
not
something
that
we
expect
clients
to
like
it's,
not
something
that
clients
can
like
change
their
behavior,
and
then
we
know
we
can
use
it.
It's
something
that
basically
means
deprecating.
A
required
argument
would
be
on
have
unknown
breaking
effects
across
our
ecosystem
forever.
A
Like
we
should
account,
this
was
basically
my
suggestion.
Last
time
we
talked
about
this
was
we
can
loosen
the
spec
to
account
for
a
shopify,
specific
runtime
change.
That
way,
you
can
still
claim
what
you
have
is
spec
compliant
graphql,
even
though
you're
like
yeah,
the
spec
says,
should
and
like
most
compliant
implementations
implement.
That
should.
But
we
don't
for
this
specific
reason,
or
is
this
a
general
problem
that
we
expect
people
will
run
into
and
therefore
we
should
significantly
design
around
it.
A
I'm
I'm
worried
that
we're
over
rotating
on
this
particular
problem,
because
I
think
there's
we're
really
giving
up
a
lot
of
value
by
not
treating
deprecation
of
all
elements
of
the
schema
in
the
same
fashion
and
if
deprecation
of
arguments
behaves
meaningfully
different
from
deprecation
of
fields
or
or
anything
else,
then
that's
just
like
yet
another
concept
that
we
have
to
teach
people
and
a
potential
pitfall
and
source
of
confusion,
and
that's
that's
a
real
cost.
So
we
need
to
weigh
that
against
the
value
that
we're
getting
out
of
it.
N
Yeah
for
sure
I
don't
have
any
other
concrete
examples
of
other
schemas
that
would
benefit
from
this
right
now.
I
can
like,
for
example,
hypothetical
example,
though
you've
written
your
schema,
and
then
you
decide
that
you're
going
to
re-implement
it
in
a
different
backend
language
and
you're,
going
to
expose
that
on
for
for
routing
con
simplicity,
you're
going
to
expose
that
in
a
on
a
different
path
or
a
different
url
to
your
to
your
users.
N
So
what
you
really
want
is
all
of
your
users
to
switch
from
like
a
my
schema.com
one
to
myschema.com
like
re-implemented
in
java
or
whatever,
and
most
of
the
schema
is
the
same.
But
there
are
a
few
fields
that
have
been
removed
or
changed
or
different
and,
like
you
want
to
be
able
to
mark
those
as
deprecated
in
your
old
version
of
the
schema,
without
changing
the
semantics
of
them,
which
doesn't
make
sense
under
the
ultimate
implementation.
A
It
would
allow
you
that
escape
patch
to
do
such
a
conversion.
I
suspect
that
most,
who
would
find
themselves
in
that
same
situation
would
want
to
include
a
two-phase
migration
right.
First,
you
would
want
to
make
relevant
like
first.
You
would
want
to
get
rid
of
anything
deprecated
in
your
local
schema.
A
Then
you
could
cleanly
point
from
old
implementation
url
to
new
implementation
url,
knowing
that,
like
just
the
url
pointing
was
the
thing
that
changed
instead
of
like
simultaneously
changing
queries,
and
then
you
could
unlock
adding
new
things
and
then
that
could
be
like
a
relatively
smooth
three-step
process,
as
opposed
to
having
to
do
all
those
simultaneously,
and
my
sense
is
that's
not
the
way
that
you
would
do
it
at
shopify
because
of
the
constraints
that
you've
applied
and
that's
reasonable.
A
But
I
I
don't
know:
if
that's
the
pattern
like
I
don't
know
if
you'd
want
to
encourage
cause.
The
other
thing
that
I'm
a
little
bit
nervous
of
is
whatever
we
encode
in
the
spec
is
what
becomes
sort
of
the
basic
default
way
of
doing
things
which
ends
up
setting
precedent
for
how
people
build
things,
and
you
can
imagine
if
this
rule
was
in
place
a
while
ago.
A
Perhaps
you
would
have
approached
api,
versioning
and
field
deprecation
in
a
different
way,
even
within
shopify,
and
so
we
should
kind
of
think
like
what
elements
of
of
this
are
things
that
we
want
to
evangelize
and
encourage,
and
what
are
or
do
we
want
to
think
of
as,
like
you
know,
retroactively
like
oh
yeah.
N
No
okay,
cool!
Well
then,
that's
my
perception.
I
think
it's
totally
fair
from
the
outside.
I
think
from
the
inside.
This
field,
like
our
versioning
system,
was,
has
a
lot
of
deliberate
design
philosophy
built
into
it,
and
I
think
we
would
have
done
the
same
thing
even
had
this
rule
existed
before
it's
unfortunate
that
yeah,
I
guess.
N
If
I
had
to
make
a
concrete
prediction,
it
would
be
that
in
the
long
term
more
people
are
going
to
version
their
schemas
like
we
do,
but
that's
obviously
very
hand
wavy,
and
I
don't
have
anything
to
back
it
up
besides,
it
seems
to
work
well
for
us
and
I
suspect
it
will
work.
I
suspect
other
people
will
run
into
the
same
problems
we
did
and
have
to
solve
them.
A
Yeah-
and
I
don't
mean
to
say
that
the
entire
approach
that
you're
taking
is,
is
not.
P
A
Should
encourage,
I
think,
overall,
it's
it
seems
to
be
working
for
you,
but
there's
details
of
it
that
I
think
we
can.
We
could
look
at
with
the
critical
eye,
especially
as
they
reflect
back
onto
the
spec
and
and
like
that's
that's
really.
A
The
point
that
I
want
to
make
here
is
that
it,
I
I
think,
like
having
different
urls
for
different
versions
of
your
overall
schema
seems
like
a
reasonable
thing
to
do,
but
the
like
keeping
the
previous
ones
completely
immutable
is,
is
a
maybe
an
over
constraint
when
it
comes
to
like
this
particular
kind
of
problem,
because
if
you
could
say
oh
yeah,
this
field
or
this
argument
used
to
be
required,
but
it's
going
away
in
the
next
one.
N
We
did
consider
that
and
like
we
were
quite
willing
to
make
that
escape
valve
like
that
was
actually
the
first
thing
we
looked
at
internally,
but
it
causes
semantic
problems
because
often
you're
making
this-
and
this
goes
to
other
thing,
to
the
migrations
being
effective
like
outside
of
the
schema
you're
making
this
optional,
because
some
other
behavior
has
changed
or
because
this
or
because
that
and
so
suddenly
you
can't
just
make
an
argument
optional.
N
N
I
think
I
should
add
just
also
what
I
put
at
the
end
of
my
comment
is
like
it
sounds
like
there's
some
pushback
here
and
that's
okay
like
where
shopify
is
okay.
If
we
decide
to
make
this
a
must,
I
think
probably
that's
a
mistake,
but
my
confidence
on
on
that
is
so
low
that
I'm
happy
to
like,
and
I
do
see
the
value
in
having
a
clearer
path
and
a
more
consistent,
forcing
function
for
other
developers
to
migrate
their
schemas
consistently.
So.
A
For
what
it's
worth,
I'm
I'm
supportive
of
having
this
be
a
should,
instead
of
a
must,
if
it
means
that
the
the
majority
of
implementations
in
open
source,
at
least
dude,
like
by
default,
they
do
the
shed
behavior,
which
is
probably
the
right
reading
of,
should
in
the
spec.
But
if
there's
a
switch
that
you
can
just
say
like
all
right,
the
thing
that
checks
that,
if
it's
deprecated
it
can't
be
required,
I
can
just
turn
that
off.
A
Then
you
could
just
do
that
within
shopify
you'd
still
be
expect
compliant,
and
I
it
doesn't
seem
like
there's
a
huge
downside
to
that
to
me.
A
Unless
I'm
I'm
missing,
some
potential
pitfall
there,
but
I
I'd
rather
us
just
loosen
the
language
on
what's
required
within
the
spec,
then
like
explicitly
design
around
it
by
having
the
default
of
include
like
include
all
that
deprecated
arguments
by
default,
which
I
think
really
hurts
the
value
of
the
deprecation
feature
in
graphql
or
add
some
other
piece
to
the
introspection
api,
because
then
I
think
we're
kind
of
over
rotating
of
like
oh,
what
happens
if
someone
depends
on
this
on
a
client
and
it's
like,
if
they're,
just
using
the
shopify
api
like
they're,
it's.
A
I
think
that's
the
source
of
the
the
technical
conflict
here,
and
maybe
maybe
what
we're
doing
is
we're
trying
to
take
two
things
that
are
the
same
by
name
but
different
by
by
detail
and
try
to
smush
them
together
and
and
it's
just
kind
of
not
working
and
so,
and
maybe
this
is
an
indication
that
we
need
to
kind
of
revisit
the
the
like
exposed,
metadata
kind
of
proposals
that
would
allow
us
to
say
this
is
like
shopify
deprecated
or
something
along
those
lines.
F
Yeah
people
actually
asked
previously
for
experimental
for
alphabet
of
works
and
they
have
similar
semantics
in
a
sense.
I
totally
agree
with
you
that
we're
mixing
two
things
with
mixing
correct
stuff
deprecated,
like
inspect
duplicated,
means
duplicated
in
this
version,
and
you
can
migrate
inside
this
version
and
what
like
getting
from
events,
it's
like
different
directive
like
will
be
removed
in
next
version,
or
you
should
migrate
until
next
worship
or
something
like
that,
and
it's
it's
like
much.
N
Yeah,
there's
graphql
has
a
very
explicit
vision
for
how
schemas
evolve
and
that's
kind
of
not
the
vision
that
we
went
with
and
that's
definitely
the
root
of
all
of
these
problems.
If
yeah,
I'm
okay
with
us
working
around
this.
N
Basically
on
our
end,
if
graphql
wants
to
continue
to
to
drive
that
vision-
and
I
think,
like
graphql's
vision
for
schema,
evolution
will
does
and
and
will
continue
to
work
for
the
vast
majority
of
schemas
and
the
vast
majority
of
companies
we're
in
a
bit
of
a
unique
situation,
not
totally
unique
but
an
edge
case
at
the
very
least
yeah.
I.
N
Yeah
so,
for
example
like
in
version
and
x,
there
could
be
some
field
and
then,
in
version
y,
that
field
is
completely
gone
and
a
new
field
has
replaced
it,
and
so
then,
in
version
x,
we
we
mark
that
field
as
deprecated,
even
though
there's
no
replacement
in
the
same
schema
graph.
F
N
We
gaps
yeah,
we
definitely
can
do
a
slower,
smoother
migration
like
market
is
deprecated
and
add
the
new
field
in
a
particular
version,
but
not
remove
it
until
later.
It
really
we
wanted.
We
just
wanted
to
give
ourselves
the
flexibility,
because
we
had
a
couple
of
use
cases
for
this
directly
of
like
doing
hard
and
fast
migrations
when
the
situation
was
called
for
in
a
way
that
still
gave
our
third-party
developers
a
chance
to
do
like
a
controlled
migration
on
their
end.
N
N
Yeah,
if
it
ever
finishes,
if
we
ever
anyway
virtual
crawford
stock
yeah,
so
in
tldr
for
the
specific
graphql
spec
change,
then
I
think
it
sounds
like
everybody
wants
to
go
with
with.
Must
there's
not
a
doesn't
sound
like
a
lot
of
value
in
should
for
us,
if
there's
not
a
lot
of
buy-in
for
the
introspection
change,
and
nobody
else
has
been
asking
for
this.
So
I'm
happy
to
get
out
of
the
way
on
this
one
now.
F
Another
action
point
I
can
suggest
just
it:
it's
useful
not
only
to
with
practical
proposal
but
to
understand
ecosystem
in
general.
Can
we
gather
statistics
on
how
people
use
introspection,
for
example,
if
we
discover
that
nobody
actually
using
introspection
in
production
clients,
if
it's
only
used
like
in
graphical
or
postman
or
other
similar
tools,
it's
not
an
issue,
and
maybe
you
can
gather
such
statistical
shopify.
A
Yeah,
I'm
a
little
bit
worried,
that's
a
reasonable
suggestion,
but
I'm
worried
that
we'll
get
back
stats
that
we
don't
know
how
to
fully
interpret
to
make
a
decision
anyway.
So
I
I
actually,
I
do
think
it's
worthwhile
to
just
think
about
this
kind
of
problem
from
like
what
we
are
enabling
or
disabling
from
a
design
direction,
rather
than
just
like
what
are
we
breaking
or
not
breaking
in
current
usage?
A
Again,
I
I
I
I
think
it's
it
sounds
like
we've
worked
through
the
actual
decision
detail
here,
which
is
really
boiling
down
to
a
must
versus
a
should,
and
if
you're
saying,
if
it's
a
should,
you
still
wouldn't
use
it,
then
that
implies
that
the
value
from
downgrading
from
must
to
should
is
is
low
and
therefore
it
should
probably
stay
at
must
and
sounds
reasonable
to
me.
F
F
A
And
it's
I
I.
A
Merge
that
change
you
should
you
should
make
sure
that
it
is
inclusive
of
what
we
just
decided
here
about
the
required.
A
Great,
do
we
have
the
ability
to
change
this
spec
proposal,
because
this
is
from
kevin
smithson
who's?
Not
here
yeah,
you
can.
F
A
I
I
think
I'd
I'd
like
to
only
in
increase
this
from
stage
one
to
stage
two
once
there's
language
included
in
the
the
spec
proposal.
That
accounts
for
this
schema
validation
rule
that
you're
talking
about.
F
A
F
I
think
like
changes,
I
need
somebody
who
is
native
speaker
to
review
my
change.
I
will
think
benjamin.
He
was
super
helpful
with
reviewing
reviewing
grammar
and
editorial
changes
by
the
way.
It's
like
great
help
for
me,
because
it's
really
hard
for
a
non-native
speaker
to
review
and
match.
I
was
constantly
under
pressure.
F
A
Sounds
great,
okay!
Well,
that's
the
next
actions
for
moving
this
forward
is
getting
the
graphql
just
js
change
in
and
then
advancing
the
spec
text
here
and
I'll
leave
them
both
on
you,
yvonne.
As
next
actions.
A
All
right
moving
on
doton,
you
have
the
next
two
agenda
items.
Do
you
want
to
start
with
update
on
the
typescript
migration.
K
Yeah,
actually
I
added
this
to
the
agenda
because
I
wanted
to
hear
from
ivan
what
are
the
next
steps
if
there
are
any
blockers
and
how
can
we
help
with
it
and
the
next
item?
I
think
it
we
can
combine
it
I
mean,
or
maybe
even
the
entire
thing
could
be
merged
into
a
single
meeting.
K
I
saw
that
even
already
suggested
date
and
time
next
week,
so
yeah,
maybe
just
a
short
update
on
the
typescript
migration
and
if
we
can
help
in
any
way
we're
here.
F
So
basically,
at
some
point
we
need
the
feature
freeze
and
it's
mean
like
feature
freeze
for
everything
like
it
should
be
like
couple
weeks
or
one
week
or
two
weeks.
I
don't
know
like
what
problem
we
will
experience
during
the
creation.
Hopefully
it
will
be
like
just
a
week,
but
maybe
like
two
weeks,
so
basically
it
will
freeze
merging
any
appears
to
reference
implementation,
just
if,
if
everybody
okay,
if
there
is
something
urgent
because
like
working
on
merchant
stuff
and
migrating
at
the
same
time,
it's
problematic.
K
I
think
we
can
go
on
with
your
original
suggestion.
I
mean
combine
those
we
can
create
a
branch
for
all
the
typescript
work,
merge
everything
there
keep
it
updated
like
a
rebase
every
day
and
when
we
want
to
get
it
in
or
if
we
have,
if
we'll
have
like
conflicts
or
things
that
are
hard
to
do,
we
can
do
feature
freeze
and
maybe
even
shorten
it.
I'm
not
like
a
week
or
two
weeks.
F
So
there
is
a
problem
with
it:
food
do
proper,
typescript
conversion
to
a
breaking
change,
to
drop
all
typescript
version,
so
yeah,
it's
classroom
technique.
I
think,
let's,
let's
actually
discuss
it
on
the
call,
because
not
everybody
interested
in
javascript
implementation
or
like
typescript
in
general.
What
I
want
to
tell
about
typescript.
I
think
it's
really
important
to
allow
for
new
contributors
to
contribute.
F
Who
was
a
severe
limiting
factor
for
why
we
don't
get
a
lot
of
contribution.
I
actually
spoke
with,
like
even
people
from
python
community,
and
they
suggested
that
one
of
the
broker
for
contributing
back
to
reference
implementation
was
that
they
don't
know
for
all
and
typescript
is
easier
for
them.
So
I
think
it's
yeah.
It's
like
one
of
the
top
priority,
not
only
for
javascript
ecosystem,
but
for
reference
implementation
in
general.
F
So
I'm
like
I'm
more
for
it.
I
just
need
to
figure
out
how
to
do
it
and
yeah
and
about
distributing
work.
It's
it's
not
my,
I
think,
to
actually
work
on
it
and
figure
out
another
thing.
I
will
probably
contact
matt
about
full
support,
because
at
some
point
we
need
to
figure
out
how
to
better
do
it,
because
if
we
just
migrate
to
tab
script,
we
will
lose
four
types.
F
K
Got
it
so
any
issues?
If
you
need
help,
we
can
put
like
someone
to
work
on
it
with
you.
We
can
help
more
than
one.
I
mean
if
you
need
any
help.
We
are
here.
F
I
actually
want
at
least
try
to
participate
in
oktoberfest.
I
think,
like
community
involvement
is
really
great,
so
yeah
definitely
will
open
an
issue
and
plus
we
will
have
this
call
when
we
can
brainstorm.
F
A
A
I
I
think
one
thing
that
might
help
is
is
starting
a
trusted
group
of
people
who
have
committer
rights,
so
it
seems
like
maybe
fury
or
doton
blessing
them
with
committer
rights,
as
long
as
y'all
are
in
tight
communication
about
making
sure
your
strategies
are
aligned
and
you're
landing
stuff
in
the
ways
that
you
want
to
be
doing
it
as
a
team
that
could
help
accelerate
because
then,
as
as
you
could
kind
of
pass,
the
pass
the
buck
back
and
forth
as
to
who's
needs
to
be
accountable
for
code
review
and
merging
things.
A
That
might
be
helpful,
but
certainly
getting
time
just
to
talk
things
through
is
is
going
to
be
the
most
helpful
thing.
So
do
you
need
any
help
with
scheduling
that,
or
I
think
brian
can
probably
help
if
there's
any
mechanics
of
of
actually
setting
up
a
graphql
gs,
specific
meeting.
F
Yeah,
it
was
my
action
item
about
agenda
item
about
discussing
how
to
set
up
groups,
so
I
create
issue
on
graphql.js
and
peanut
on
top
another
thing
actually
like
previously,
we
had
like
some
issues
with
onboarding
contributors
and
stuff
and
we
discussed
it
with
brian.
An
idea
is
to
have
a
clear
policy
and
transparent
process
on
doing
that,
because
right
now
we
have
a
bunch
of
people
with
commit
rights
and
no
clear
criteria
when
we
can
like
remove
them
or
add
them.
A
A
I
think
the
vast
majority
of
the
current
maintainer
list
are
former
contributors
that
repo
from
facebook,
who
don't
really
show
up
all
that
often
I'm
more
interested
in
creating
a
core
consortium
of
people
who
are
regular
root,
code,
reviewers
and
mergers,
because,
right
now,
that's
primarily
you
and
very
occasionally
matt
and
I
think
getting
diaton
or
yuri
involved
would
be
a
helpful
thing.
But
let's
make
the
next
step
getting
that
meeting.
A
It
sounds
like
you
have
a
proposed
time
for
next
week
and,
let
me
or
brian
know
if
you
need
any
help,
setting
that
up.
P
F
To
have
people
to
put
it
on
a
schedule
and
to
have
time
we
we
actually
we
started
a
newsletter
for
graphql
foundation,
so
it
would
be
great
to
include
it
in
zero.
So
right,
I
think,
for
such
initial
courses
makes
sense
to
advertise
it
as
much
as
possible,
especially
if
we
want
to
be
like
open
to
new
contributors.
K
No,
I
think
that's
it.
Thank
you
even.
A
F
Yeah
so
like
we
have
actual
right
now
we
have
graphical
working
group,
a
graphql,
http
working
group
and
graphql
or
ctp
actually
was
adopted
by
foundation.
So
now
it's
also
on
the
foundation.
So
like
two
working
groups,
we
have
main
working
group
and
we
will
have
graphql
js
working
group.
So
it's
four
and
we
have
like
more
os
four
and
a
half,
because
we
have
input
union
working
group.
F
So
it's
like
five
working
group
at
the
same
time
as
and
the
issue
is
that,
like,
if
you
start
grafting,
just
working
group,
how
like
I
want
to
copy
the
stuff
from
from
from
graffiti
working
group
agenda
and
notes
and
stuff?
Maybe
we
don't
need
like
such
eternals
and
videos
would
be
just
okay
or
not.
Is
it's
up
to
discussion
on
a
call,
but
like
one
thing
like
how?
F
F
So
having
a
branch
option
but
at
the
same
it's
hard
visibility
and
we
still
have
like
a
pollution
of
issues
and
prs,
it's
less
a
problem,
but
still
not
ideal
solution.
So
I
look
like
in
how
it's
managed
in,
for
example,
node.js
foundation
and
it's
separate
triples.
F
But
it's
separate
if
we
create
separate
repos
what
working
group.
So
we
don't
have
anything
inside
spec
repo
and
it's
also
beneficial.
We
can
generate
change,
work
from
it
or
do
other
stuff
and
people
can
use
like
bisect
or
some
other
cool
features,
but
for
if
every
other
working
group
will
create
repo
will
create
real
hard
visibility
of
like
foundation
projects
and
also
if,
for
example,
we
try
to
preserve
and
put
union
stuff.
F
Also,
some
temporary
group
and
put
union
as
an
example
of
like
temporary,
like
it's
temporary
permanent
group,
so
it's
happening
every
month,
but
it's
still
like
with
clear
and
goal
group
is
clear
and
go.
We
want
to
preserve
some
stuff
from
this
group
and,
if
a
separate
repo,
it
will
like
be
like
that
repo
on
foundation
organization.
K
I
think
this
sounds
fine.
I
mean
either
one
ripple
or
multiple
reapers
I
mean
probably
depends
on
like
permissions.
I
would
like
to
suggest
to
consider
use
zenhub,
it's
built
on
top
of
github,
so
it's
like
a
board
where
you
can
track
action.
Items,
progress
on
tasks
and
stuff
like
that
and
everything
is
behind.
The
scenes
is
managed
on
github
as
issues.
K
So
it's
easier
to
track
and
also
you
can
have
like
your
own
internal
status
and
still
have
like
a
public
like
an
option
to
to
share
it
to
the
public.
So
it's
nice.
Maybe
it
can
help
to
track
progress
on
tasks.
A
That's
a
good
point:
I'm
I
support
adding
more
tooling
and
and
help
for
managing
our
meeting
structure,
I'm
a
little
hesitant
about
creating
a
separate
github
org
just
because
of
discoverability
one
suggestion
that
I
will
make
just
to
help
create
some
rules
around
when
it's
appropriate
to
make
a
repo
versus
when
you
should
do.
Something
else
is
I
I
want
us
to
make
a
distinction
between
separate
working
groups
and
subcommittees
so
input
unions
is
not
a
separate
working
group.
A
That's
a
subcommittee
of
this
working
group
and
for
those
you
know,
I
think,
we've
been
a
little
bit
lacks
taking
notes
and
tracking
those
things
and
really
what
it's
looked
like
is
one
single
rfc
file.
I
think
when
we
realized
in
hindsight,
we
should
have
realized
that
in
breaking
it
out
into
a
subcommittee
that
should
have
been
a
moment
where
we
started
tracking
agenda
items,
notes
and
kept
the
same
kind
of
rigor
that
we
keep
for
this
main
meeting.
A
We
could
do
that
with
folder
structure.
I
don't
think
we
need
branches.
I
don't
think
we
need
anything
particularly
complicated
from
the
get
side.
I
think
we
could
just
have
a
subcommittee's
folder
and
then
there's
an
input
union
subcommittee
and
we
could
have
a
subcommittee
for
any
of
the
things
that
we
go
and
break
off,
for
I
think
really
the
only
and
even
I'm
happy
for
all
to
consider
a
lot
of
these
things
subcommittees
like
graphql.js.
A
I
could
go
either
way
as
to
whether
we
want
to
consider
that
a
subcommittee
of
this
overall
working
group
or
if
we
want
to
consider
that
its
own
thing,
whichever
will
make
it
easier
to
manage,
but
hopefully
that
solves
the
problem
that
you're
talking
about
of
like
dead
repos
for
only
temporary
working
groups.
The
subcommittees
only
need
to
exist
as
long
as
they
serve
a
purpose
and
then,
at
that
point
they
leave
behind
a
folder
full
of
notes.
F
F
There
is
like
some
issues,
for
example
with
is
taking
me
a
lot
of
time
to
review
stream
and
defer
stuff,
but
other
than
that.
You
don't
have
like
ongoing
issues
where
graphqs
blocks
or
some
problem
from
with
group
side,
but
like
typescript
conversion
and
other
stuff
coming
from
javascript.
So
in
web
senses,
not
like
sub
groups
because,
like
interests
are
most
of,
I
suspect,
like
most
of
the
stuff
that
we
will
discuss
in
this
group.
A
I
think,
for
anything
that
is
a
independent
working
group.
A
separate
repo
within
the
same
org
makes
sense.
The
primary
reason
why
I
suggest
keeping
one
org
is
just
discoverability.
A
You
can
say
like
oh
there's,
what's
everything
that's
under
the
graphql
foundation
and
you
can
just
go
to
one
place
and
you
can
scroll
down
all
of
the
various
repos.
Otherwise
we
have.
We
have
to
like
help.
People
navigate
through
the
multiple
github
orgs
controlled
by
the
graphql
foundation,
and
I
think
it'll
become
a
point
of
confusion,
the
other
and
I
I
also
think
it's
reasonable
to
rely
on
folder
structure
like
if
you're.
A
If
your
meeting
is
tightly
tied
to
another
meeting
in
the
form
of
a
subcommittee
or
tightly
tied
to
a
project
in
the
form
of
a
regular
like
a
maintainers
meeting
for
that
project,
then
it
makes
sense
to
just
have
a
folder
in
that
same
repo.
So
for
graphql.js
it
might
actually
be
reasonable
just
to
put
a
folder
at
the
top
level
that
says
meetings,
and
then
you
can
just
list
agendas
and
notes
as
files
in
the
meetings
folder.
A
That
way.
Someone
who
like
stumbles
upon
that
repo
and
says
how
can
I
help
instead
of
having
to
know
that,
there's
a
separate
github
org
that
lists
a
repo
that
has
a
meeting
for
graphql
js.
They
find
just
like
right
there
in
the
repo
they
find
the
relevant
notes
that
they
need
to
follow
along
with.
F
Yeah,
so
we
have
like
11
11,
separate
flows
in
ci
at
the
moment,
so
yeah
for
something
it's
overkill
for
for
think.
When
you
try
to
let
agenda
items
was
actually
like
the
same
with
with
available
stocks
generating
change
work.
That's
why
I
look
into
like
bubble.
Have
a
separate
triple
no
js
have
a
separate
trip.
I
think
I.
D
F
At
the
moment,
we
have
more
way
more
commits
for
working
group.
Folder,
then
for
rest
of
the
spec
and
it's
dilute
like
progress,
and
if
person
goes
there,
he
need
to
scroll
through
pages
by
pages
of
people,
adding
them
into
agenda
instead
of
like
getting
what's
actually
happened
on
the
repo,
so
I
actually
want
to
extract
both.
I
want
to
extract
graphql
over
ctv,
it's
less
pressing
and
less
like,
because
it's
you
like
a
spec
ripple,
so
it's
don't
have
ci
cd
or
stuff,
but
for
graphql
js.
It's
like
it's.
A
Critical
okay
sounds
like
a
separate
repo.
Is
the
right
thing
to
do
support
you.
K
A
K
Good
suggestion
from
david
yeah
graphql.js
is
using
github
actions
right.
O
F
K
Okay,
we
can
help
with
that.
I
mean
we're
doing
a
similar
things
in
our
repos.
So
if
you
need
help
with
that,
okay.
F
A
Sounds
like
a
plan:
okay,
let's
keep
things
moving
and
liliana.
I
see
you've
joined
us,
welcome
just
in
time
for
you
and
rob
to
take
us
through.
What's
new
with
deferring
stream.
C
Okay,
so
the
first
thing
that
I
wanted
to
talk
about
is:
I
have
a
link
in
the
agenda,
rfc
faq
and
it's
a
question
that
we've
been
getting
a
lot
recently,
which
is
why
we
don't
support
defer
on
fields.
So
our
proposal
so
far
has
only
been
on
fragments
and
inline
fragments
and
our
our
reasoning
for
that
was
the
original
apollo.
C
Implementation
was
only
on
fields,
and
we
ran
into
a
bunch
of
problems
with
that,
where
it's
kind
of,
if
you
need
more
than
one
field,
it's
hard
to
coordinate
the
loading
state
of
all
the
different
fields
before
you
render
it,
and
so
I'm
our
thoughts
are
that
fragments
are
going
to
be
the
more
the
more
common
use
case,
and
it
is
kind
of
easy
if
you
just
have
a
single
field
to
wrap
it
in
an
inline
fragment,
but
ivan
also
brought
up
that
you
could
make
the
same
argument
with
skip
and
defer.
B
I
think
one
problem
also
with
the
apollo
solution
is
that
it
had
to
be
nullable.
Then
I
don't
know
if
you
remember
using
it,
but
I
remember
it,
and
so
they
had
this
issue
with
non-valuable
fields.
B
That
then
were
omitted
of
the
from
the
original
payload
and
were
delivered
later
and
that's
why
they
mandated
that
you
have
it
nullable,
and
there
were
lots
of
things
around
that
that
made
it
not
really
nice
to
use,
and
I
think
that
going
down
with
the
facebook
solution
that
that
basically
was
in
relay
is
a
much
cleaner
way
to
deal
with
defer
and
stream.
H
Yeah
yeah,
so
from
a
facebook
perspective,
I
believe
I
I'm
kawai
is
the
clear
person
who
would
no
no,
but
I
believe
we
even
tried
to
do
it
on
to
allow
at
the
firm
stream
on
fields
initially
and
ended
up
finding
one.
It
wasn't
needed
into
the
boundary
where
most
developers
wanted
to
defer
and
stream
was
at
the
fragment
level
and
not
doing
fields
at
least
initially
made
it
much
much
easier
to
build
the
infrastructure
required
which
like,
if
so,
for,
adding
something
to
a
spec.
H
If
our
goal
is
to
add
the
minimal
useful
thing
to
start,
that's
a
good
argument
for,
let's
for
now
we're
deferring
building
out
field
deferral
until
it's
proven
that
that
exactly
is
needed.
C
Yeah,
that's
that's
what
we've
been
thinking
too,
just
just
because
it
came
up
a
couple
times.
I
wanted
to
go
over
it
again
with
the
group.
F
F
For
that
reason,
so
you
can
apply,
skip
and
include
on
group
of
fields.
So,
like
one
of
the
thing
in
aspect
is
consistency,
so
if,
if,
for
example
like
experimental
implementation
included-
and
we
discover
it's
hard
for
ike
for
a
client
library,
so
a
po
or
a
way
or
other
to
handle
it,
we
can.
F
Let's
experimentation
phase,
but
if
we
never
add
it,
we
basically
we
will
get
and
see
inconsistent
ipi
with
the
rest,
other
directives
and
like
if
we
decide
to
edit
later
we
will
don't
have
enough
data
points
to
make
this
decision
like.
F
I
actually
think
it's
like
pretty
simple
changing
graphql.
Yes,
like
I
don't
know
about
rawai
or
current
libraries,
but
in
graphql
js.
I
think
it's
like
could
be
super
simple,
because
we
we
need
to
support,
multiply
in
wind,
fragments
anyway.
Nothing
prevents
me
from
creating
like
two
three
five
of
them
so
like
from
graphic
chess
perspective.
I
think
it's
like
20
lines,
maybe
like.
If
we
need
to
add
tests,
might
be
like
50
100
lines
of
code.
C
The
the
other,
the
other
thing
is
I
it
might,
it
might
lead
to
people
using
fields
more
often
than
fragments,
and
then
you
kind
of
get
like
a
ux,
where
a
lot
of
things
are
just
popping
in
all
over
the
place.
When,
because
it's
kind
of
difficult
to
manage
with
a
fragment,
I
don't
know
if
we
want
to
like
cur.
If
having
some
field
support,
there
is
encouraging
that
or
there's
like
a
little
bit
of
a
barrier.
C
I'm
not
really
sure
if
that's
a
great
argument
or
not
for
against,
but
yeah
is
the
consistency
with
other
directives
versus
a
more
minimal
spec.
I
guess
is
the
balance.
A
I
actually
I'm
I'm
less
worried
about
consistency
here,
just
because
there
there
are
very
few
directives
that
are
included
in
the
spec,
so
it
it
would
not
be.
It's
not
my
intention
that
every
new
directive
that
we
also
add
to
the
spec
has
to
match
the
existing
ones.
We
should
treat
each
each
new
directive
with
you
know,
whatever
the
appropriate
design
is
for
that
thing,
and
I
think
your
your
point
of
of
why
it
makes
sense
to
apply
this
only
to
fragments
instead
of
fields
at
first.
A
I
was
also
a
little
bit
confused
by
this.
So
thank
you
for
the
clarification.
I
think
it
makes
sense
and
you
can
actually
even
specifically
point
out
why
this
is
different
from
skip
or
include,
skip
and
include
are
synchronous.
So
if
you
put
a
skip
field
on
two
sibling
fields
or
the
skip
directive
on
two
sibling
fields,
then
either
both
are
skipped
or
neither
are
skipped.
You
know
if
these
the
same
argument
and
so
you're
not
gonna
like
that's,
not
gonna,
have
some
impact
on
your
ux.
A
There's
no
pitfall
from
having
listing
the
skip
multiple
times.
Could
you
lift
that
up
onto
an
inline
fragment
and
write
the
skip
once
you
could,
but
it
would
have
observably
identical
behavior?
The
same
is
not
true
for
defer,
because
each
usage
of
deferrer
is
an
async
boundary
so
having
one
at
the
fragment
level
implies.
A
So
if
your,
if
your
observation
is
that
it
would
be
easy
for
people
to
write
such
a
query
without
the
intent
of
that
ux
behavior,
then
we
should
view
that
as
a
as
a
pitfall
and
therefore
designing
around
the
pitfalls,
wise
and-
and
that
to
me,
is
the
clearest
sign
of
like
hey.
I
have
this
in-line
fragment,
so
I
can
defer
my
one
field.
That
seems
annoying.
Why
is
that
and
you're
like
great
question?
A
Well,
when
people
are
using
this
experiment
production,
what
we
find
is
they
start
with
one
field,
and
then
they
add
a
second
one
and
like
what
you
have
to
think
about.
What's
the
path
from
one
field
to
two
fields
and
like
this
is
the
path
that
makes
the
most
sense
for
the
ux
is
to
make
people
be
thoughtful
about
the
ux,
and
this
is
what
we
found
helps
them
do
that.
F
Who
will
have
this
question,
especially
like
language
implementers?
The
reading
through
maybe
like
even
stuff
about
non-normative,
note
about
best
practice
or
acquire
evolution.
Like
you
add
more
fields,
and
it's
better
to
start
a
group
then
transform
from
field
to
get
to
in
one
fragment,
I
think
yeah.
So
I
agree
with
your
arguments.
This
actually
makes
sense,
but
I
think
it's
need
to
be
addressable
spec,
because
our
spec
is
actually
good
on
giving
intention
not
only
specifying
stuff
but
explaining.
Why.
B
For
this
is
also
the
apollo
implementation,
because
I
tried
it
out
with
the
field
and
if
you
read
through
their
specification,
they
lined
out
all
the
all
the
problems
that
you
face
with
the
solution,
so
they
wrote
down
you.
Can
you
could
take
that
as
a
base?
A
B
C
A
Yeah,
I
definitely
agree
with
the
with
yvonne.
Having
a
non-normative
note:
that's
there
that
kind
of
helps
people
understand
why
it's
built.
The
way
it
is
is
it's
I
mean
the
more
places
that
we
describe
it,
the
better
so
having
the
faq
is
also
helpful,
but
you'll
catch
them
as
they're
reading
that
and
wondering
why
it
is
the
way
it
is.
F
It's
like
some
queries,
you
put
them
into
execute
function
and
some
queries
inside
subscribe
function,
so
I
actually
want
to
look
into.
Can
we
can
unify,
execute,
subscribe
and
stream
and
defer
because
they
and
reduce
number
of
return
values,
types
of
criteria-
values?
Maybe
I
I
don't
know
if
it's
outside
the
scope
of
this
rfc
or
not,
but
maybe
we
can
think
about
if
we
already
adding
adding
asynchronously
returning
stuff
into
execute.
C
Yeah,
we
could
think
about
that.
My
preference
would
be
to
do
that
after
support
is
merging
into.
F
Execute
yeah
it's
like
yeah.
Obviously,
if
this
experiment
can
go
different,
it's
like
experiment
for
a
reason,
because
we're
not
100
sure
in
the
end
result
and
just
like
yeah,
I
just
think
think
like
in
any
end
result
of
this
rfc
will
basically
add
asynchronous
stuff
into
execute.
We
can
change
like
anything.
It
executes
asynchronously
here
to
stay
inside
the
execute,
so
we
just
like.
F
Maybe
it
will
influence
design.
No,
I
I
don't
mean
like
necessary.
Spec
changes
should
be
especially
staged
separate,
but
maybe
we
can
figure
out
how
we,
for
example,
like
I'm,
not
sure,
but
has
next,
also
makes
sense
kind
of
in
subscription
context.
For
example,
you
can,
if
we
already
adding
this
field
impossible
return,
it
makes
sense,
maybe
for
subscription
also
to
the
signaling
that
subscription
has
ended.
So
it's
last
item
of
subscription
and
server
is
dropping
it
or
something.
A
C
So
we're
we're
still
working
on
getting
async
iterable
resolver
support
merged.
If
I
mentioned
there
might
be
a
memory
leak,
so
I
can
look
into
writing
a
test
for
that,
like
we
had
in
it
or
all,
I
think
just
some
eyes
on
the
spec.
Pr
would
be
great.
P
A
Spec,
yes,
there's
there's
like
a
phase
guideline.
A
A
I
think,
especially
since
this
effort
is
a
huge
change
to
the
surface
area
of
graphql,
getting
some
of
these
graphql
js
changes
merged
and
accessible
only
behind
a
flag
that
you
explicitly
have
to
turn
on,
so
that
people
can
start
using
this
and
figuring
out
how
it
affects
tooling
and
looking
for
bugs,
like
my
sense,
is
that
that
is
where
we
will
find
the
most
significant
changes
to
to
the
spec
is
realizing
that
a
bug
is
significant
and
actually
has
a
meaningful
change
on
the
spec
text,
so
that
that
that's
my
sense
of
where
I
would
place
the
priority
is
making
sure
that
the
reference
implementation
backing
is.
A
P
Okay,
I'm
I'm
not
asking
without
intent,
and
my
intent
is
actually
to
to
require
a
second
implementation
outside
of
craftbridges
before
we
merge
it
for
the
spec.
The
experience
with
the
defer
implementation
we
had
before
driven
by
the
apollo
world,
which
was
purely
javascript,
was
like
we.
I
think
we
need
to
have
a
second
implementation
to
verify
that
the
assumptions
we
are
making
are
valid
outside
of
the
javascript
ecosystem,
like.
P
I
think
this
does
not
block
anything
and
it's
not
critical,
maybe
right
now,
but
in
general
I
would
highly
recommend
that
we
consider
this.
Probably
it
will
happen
automatically
after
graphql
js's
merchant.
After
some
time
people
start
around
with.
I
hope
another
implementation
picks
it
up,
but
I
think
it's
worthwhile
thinking
about
it
as
a
formal
requirement
because
of
this
huge
impact.
A
I'm
comfortable
with
that.
I
know
that
there's
they're
basing
a
lot
of
decisions
off
of
conversations
with
folks
on
the
graphql
server
side
team
at
facebook,
who've
been
building
this
in
a
non-javascript
language
as
well,
but
yeah.
I
I
think
getting
this
andy
if
you're
interested
in
tackling
this
on
the
graphical
java
side,
just
to
make
sure
that
there's
no
surprises
it.
That's
all
super
aligned
with
exactly
what
I
described
before
about
having
high
confidence
in
the
implementation
looking
for
bugs.
B
Sorry
yeah,
we
are
also
targeting
october
for
this
with
the
next
one
of
our
server
and
that's
a.net.
It's
similar
very
similar
to
the
challenges
java
will
have.
P
P
So,
while
you
could
implement
it
on
the
back
end,
how
you
would
actually
put
it
onto
the
client
in
terms
of
hdp
and
and
stuff
like
this
was
hugely
underspecified
and
why
we
can
leverage
a
kind
of
a
implicit
premium
in
the
ecosystem
for
normal
craft
requests.
We
need
to
consider,
especially
for
this.
The
transport
layer
is
much
much
more
complex
right
and
we
need
to
tackle
this
explicitly
by
having
something
written
down
outside
of
a
gis
implementation.
C
Yeah
definitely-
and
I
have
not
a
spec
but
in
rfc
for
graphql
over
http,
with
all
the
details
benji
pointed
out
which
I'm
gonna
make,
but
if,
if
there's
anything
more
that
could
be
added
there.
Definitely
let
me
know.
P
That's
already
great
that
we,
we
have
an
extra
document
targeting
this.
This
will
help
a
lot.
C
Yeah
and
we
have
a
a
reference
implementation
of
that
in
express
graphql,
and
I
have
a
client
library
too.
So.
P
Great
yeah,
looking
forward.
P
Especially
also
to
the
implementation
to
get
to
hear
feedback,
I'm
not
sure
when
kraftwerk
java
will
take
a
little
to
be
honest,
we
are
definitely
gonna.
Do
it
like
we
implemented
the
default
for
apollo,
we
removed
it
actually
recently
complete,
so
we
don't
have
defer
anymore
inside
graphical
java,
and
but
of
course,
we
will
pick
it
up
again
at
one
point.
B
F
And
I
I
just
want
to
qualify
one
thing,
so
I'm
not
merging
with
with
they
are
not
because
of
some
like
problem
with
with
spec.
It's
just
that
I
I'm
just
javascript.
I
think
iteratable
have
like
some
problem
with
leak
and
performance
tests
and
stuff,
so
it's
like
purely
technical
from
javascript
side.
So
on
your
side,
it's
like
it's
totally.
F
I
don't
expect
anything
in
rfc
to
be
changed
based
on
pr
to
graphql
js,
so
it's
purely
issues
with
either
javascript
ecosystem
or
a
graphql
js
or
like
a
review
process
and
another
idea
in
this
context
actually
like
since
we're
starting
graphql
working
group,
I'm
like
if
you
want
something
from
graphql.js
or
discuss
something
from
graphql
json
change,
something
your
dress,
you
you
can
join
in
yeah
so
like
I
am.
I
don't
know
if
you
joined
before
or
after
our
discussion
of
kraken,
yes
working
group
so
like
as
other
language
implementers.
F
A
I
I
think,
that's
it
awesome.
It's
super
exciting.
I'm
always
happy
to
see
that
you
all
have
made
progress
and
there's
always
something
interesting
to
talk
about
every
month
on
this.
So
thank
you
all
for
continuing
to
move
this
forward.
It's
a
long
time
coming
andy
I'll
hand
it
to
you
to
give
an
update
on
graphql,
scalars
and
anything
you
want
to
talk
about
there.
P
There's
nothing
really
to
update
and
that's
actually
the
topic,
I'm
I'm
just
want
to
encourage
people
to
participate
or
to
leave
feedback.
We
have
this
craft
scalers
repository
where
we
have
a
bunch
of
open
issues
where
we
want
to
discuss
with
the
question
that
came
up
and
how
to
progress
and
yeah.
I
hope
other
people
find
this
project
also
interesting
and
want
to
contribute,
like
maybe
a
little
bit
more.
P
I
think
it
has
the
potential
of
having
a
huge
impact
in
kind
of
extending
the
fundamental
capabilities
of
craftware
with
more
specified
scalars,
so
I'm
very
excited
about
it,
but
we
lack
a
little
bit
traction
and
and
engagement
so
far,
so
I'm
also
happy
to
think
about
or
like
to
incorporate
feedback
how
we
could
make
this
better.
Of
course,.
P
And
yeah
one
specific
topic
I
want
to
bring
to
your
attention.
Lee
is
there's
an
open
issue
around
how
to
approve
pull
requests.
P
If
somebody
wants
to
contribute
a
custom
scalar
specification,
it
needs
to
be
formally
formally
approved
by
the
kraftwell
like
foundation
agreement
right,
so
you
can't
merge
something
without
a
person
having
signed
this
contract,
and
it
would
be
nice
that
we
have
some
way
of
verifying
this
or
some
way
of
making
sure
this
happened.
It
can
be
a
totally
manual
process,
but
I
think
currently
it's
it's
managed
outside
of
the
repository
completely
manually
right,
yeah.
C
P
That
that's
totally
fine,
I
think,
but
maybe
we
can
make
this
more
accessible
to
one
or
two
people
in
the
future
that
we
kind
of
not
have
a
huge
bottleneck
on
prime
also.
A
Actually,
yeah
brian
knows
that
if
he
can
bre
so
this
is
both
the
process
of
going
through.
All
the
the
paperwork
is
brian's
job
and
then
also
the
job
to
get
this
automation
in
place
is
brian's
job,
so
brian
will
unblock
brian
by
landing
that
so
he's
self-motivated
to
get
that
in.
I
know
he's
working
on
it.
P
Yeah,
so
any
questions
about
this
any
suggestions,
maybe
how
we
could
increase
the
participation
or
something
the
people
here
are
lacking
of.
F
F
F
P
A
Yeah,
that's
interesting
because
it
it's
actually
high
value
and
not
something
that
we
had
talked
about
last
time
we
set
this
up.
We
originally
talked
about
how
this
is
a
great
place
to
just
share
scalar
implementations
with
with
sort
of
low
low
friction.
But
it's
a
great
point
of
like
how.
A
How
does
someone
know
under
what
terms
are
allowed
to
use
these
things,
and
that's
one
of
the
values
that
the
the
graphql
foundation
is
giving
us
is
clear,
legal
rules
which
should
just
make
it
like
you
could
if
you
see
it,
if
it's
under
the
graphical
foundation,
you
can
use
it
and
applying
that
to
everything
that
lands
here
is,
is
going
to
be
a
good
thing
and
tracking.
That
is
important.
P
Yeah
exactly,
I
think
that
gives
us
a
really
nice
legal
background
and
we
don't
need
to
think
about
it
further
once
we
have
the
formless
things
in
place.
So
that's
really
nice
even
for
this
project.
Yes,.
A
Okay,
I'll
follow
up
with
brian
and
make
sure
that
it's
the
make
sure
that
he's
prioritizing
this,
because
it
sounds
like
this
is
starting
to
block
a
handful
of
things.
But
but
yeah
ow
fa
is
is
probably
still
the
thing
we'll
roll
with
for
everything
that
lands.
Here
you
can
make
that
explicit.
F
I
can't
help
with
the
license,
because
I
like
I
had
the
same
issue
for
graphql
http,
because
I
need
to
re-license
it.
So
I
ask
brian
butcher
questions
like
you
share
like
some
book
article
and
answer
them,
so
I'm
not
sure
about
also
about
agreement,
but
about
license.
I
have
a
definitive
answer
on
how
to
do
it
for
graphql
or
cdp
or
other
foundation
projects.
F
So
one
thing
I
I
can
create
pr
because
it's
super
simple.
Basically
he
explained
it's
like
graphql
contributors.
You
should
attribute
it
not
to
graphql
foundation
but
to
graphical
contributors.
Another
issue
I
actually
like
to
to
write
some
example:
a
template
of
license.
So
people
don't
ask
this
question:
where
should
I
put
it?
What's
the
proper
repo
for
putting
example
for
license
or
template
license
or
something.
A
There
is
a
legal
repo
at
the
top.
That
would
be
the
right
place
to
do
that
unless
it's
you're
talking
about
specific
to
scalers
and
in
which
case
that
also
might
be
useful,
is
to
just
have
like
a
template,
which
I
know
andy
was
working
on
something
kind
of
similar
to
that.
And
then,
if
the,
if
the
legal
pieces
are
just
properly
linked
in
that
template,
then
anyone
who
follows
the
template
will
just
automatically
be
good
to
go.
F
Foundation,
okay,
so
like,
if
I
create
a
license
example
or
it
should
be
markdown
document,
oh
how
to
bite
and
describe
it.
Yep.
A
Markdown
document-
and
you
can
also
ask
brian
for
help-
he
you
can
just
offload
that
just
tell
him
that
you
want
that
done
and
he'll
work
with
the
the
his
legal
team
to
make
sure
that
that
gets
done
correctly.
F
Because
I
just
like
two
days
ago,
I
asked
him
about
your
questions
and
I
already
have
answers.
Okay,.
A
Sounds
great
all
right,
that's
the
end
of
our
written
agenda.
I
know
there
are
a
handful
of
things
we
wanted
to
to
cover.
A
At
the
end,
there
were
some
spec
related
questions
is
that
I
can't
remember
who
was
asking
about
that
before.
D
Oh
yeah,
thank
you
so
so
my
my
first
question
is
that,
like
there
are
like
less
than
graphql
and
at
the
time
of
insertion,
if
I
insert
a
list-
and
there
is
an
order-
let's
say
one:
two
three
like
I
insert,
I
have
three
items
in
the
list
and
I'm
inserting
them
in
some
order.
D
So
then,
when
I
query
them
back
they're
in
the
same
order
or
like
the
order
in
which
or
the
order
like
in
which
they
appear
in
the
query
for
the
first
time
should
be
repeated
every
time
when
they're
queried.
A
D
Yes,
so
if
I
query
a
list
multiple
times,
should
I
get
a
stable
order
that
is
like
I.
I
think
that
is
yes,
because
it's
mentioned
this
bag.
I
guess
but,
but
should
that
order
be
same
as
the
order
of
insertion.
F
F
B
B
Detail,
I
think,
like
the
data
order
is
not
dictated
by
the
spec.
It's
implementation.
F
D
And
like
it's
mentioned,
that
basically
graphical
list
is
a
special
collection
type,
which
declares
the
type
of
each
item
in
the
list
and
list
value
is
realized
as
ordered
list.
A
D
A
The
the
description
there
of
saying
that
it's
ordered
implies
that
a
a
consumer
of
the
list
should
use
a
data
structure
that
is
ordered
it's
totally
fine.
If
the
documentation
for
such
a
field
says
the
order
of
these
values,
don't
matter
in
which
case
like
you
could
do
that,
but
it's
not
safe
to
always
assume
that
the
the
initial
assumption
is
that
lists
are
ordered
unless
stated
otherwise
by
by
the
implementation.
A
A
Or
you
wouldn't
want
to
use
an
intermediate
data
structure
before
you
serialize
to
json.
That's
just
like
a
set
you
know
or
or
like
something
that
is
an
unordered
data
structure,
because
if
the
implementation
decided
that
like
hey
by
the
way,
this
list
is
sorted
by
recency
or
something
like
that.
And
then
you
failed
to
return
this
as
an
ordered
list.
And
you
scrambled
this
the
order.
Then
you
would
have
lost
semantics
in
the
implementation,
but
the
particular
sort
is
or
whether
it
is
sorted
or
not
or
or
anything
about.
A
The
order
itself
is
entirely
dependent
on
the
domain
and
not
the
spec.
D
Okay,
okay,
okay
and
like
the
the
other
thing
that
I
had
was
so
like.
Basically,
with
with
input
unions
like
I
I
read
like
there
was
some
rfc
regarding
input,
unions
and
like
there
were
a
couple
of
five
approaches,
and
I
guess
the
last
one,
the
fifth
one,
which
is
like
using
the
one
off
directive.
D
E
At
the
moment
we've
we've
met
the
input
union
stock
is
out
of
date.
It's
on
us
to
update
it,
as
actually
mentioned
earlier
in
the
meeting
that
that
is
still
a
to
do
that
needs
doing.
I've
been
focusing
my
time
on
just
updating
the
tagged
union,
the
tagged
type
rfc
itself,
which
I
still
have
more
work
to
do.
That
is
what
is
replacing
solution.
Five,
so
solution.
Five,
as
you
say,
is
the
one
field
or
the
one-off
directive.
E
We've
decided
that,
probably
a
better
way
of
doing
it
is
actually
to
add
a
new
type
to
the
graphql
type
system
that
actually
models
this
properly,
rather
than
doing
it
as
just
a
directive
that
has
quite
significant
effects
on
the
fields
on
which
you
use
it,
so
it
seemed
clearer
to
to
build
it
with
a
new
type
that
has
meant
that
the
spec
is
significantly
larger
than
the
spec
that
I
first
opened
and
thus
work
is
taking
a
little
longer
than
expected,
but
it
is
progressing.
E
As
you
say,
though,
if
there
are
other
solutions,
we
are
happy
to
hear
them.
We
are
not
100
committed
to
the
tag
type,
yet
it
is
currently
the
leading
one,
but
if
a
better
one
comes
around
like.
D
We
were
kind
of
working
on
unions
at
the
moment
and
we
were
trying
to
implement
them
and,
like
we
also
like
with
this
discussion
in
our
mind,
that
how
would
we
do
accept
inputs
for
unions
too,
like
we
were
just
messing
our
head
around
it
and
like
then,
we
found
that
there
was
already
that
you
know
so
so,
like
I
just
wanted
to
ask,
if,
like
some
on
it,
so
yeah
so
like
so
that
is,
like
you
know,
kind
of
clear
to
me
that
there
are
going
to
be
some
tag
types
and
basically
they
are
better
than
the
normal
one
of
directive.
D
And
when
we
were
thinking
we
were
also
thinking
of
using
the
same
approach
as
the
one
of
directive.
One-
and
I
guess
if,
if
tag
types
are
better
than
we
will
we'll
wait
for
them
and
and
and
then
the
other
thing
that
I
had
was
yeah
so
like
when
we,
when
we
say
unions,
so
does
it,
there
are
basically
two
things
like
a
union
can
contain.
Basically,
a
union
represents
some,
I
mean
some
member
types.
D
So
can
all
the
nodes
belonging
to
those
member
types
be
queried
as
a
union
or
like
just
some
particular
nodes
which
are
actually
part
of
some
field
in
the
graph,
and
that
field
is
returning
union
so,
like
only
those
particular
nodes
should
be
representable
by
the
union
or
all
the
nodes
which
belong
to
the
member
types
of
the
union
should
be
representable
by
the
union
like
is
it
clear?
E
E
Oh,
I
think
I'm
not
sure
if
this
directly
answers
your
question,
but
the
the
union
type,
as
you
say,
says
that
it's
between
two
other
or
more
any
number
of
output
types,
and
it
basically
says
if
you
say
that
a
field
will
return
a
union
type,
then
whatever
it
returns
will
be
one
of
those
types
it
doesn't
say
it
has
to
be.
You
could
always
return
type
a
even
if
you
said
it
would
could
be
a
type,
a
b,
c
or
d.
E
D
Okay,
okay,
I
guess
I
haven't.
I
have
the
answer
for
your
question
and-
and
the
last
thing
that
I
wanted
to
ask
is
like
I
guess
it
may
be
a
silly
question,
but
so
I
have
this
case
that
there
is
an
interface
and
there
are
two
types
which
implement
the
interface.
D
Now,
what
I
guess
the
current
behavior
in
this
spike
is
that
if
there
is
some
field
in
that
in
the
interface,
then
all
the
implementing
types
have
to
kind
of
again
write
that
field
inside
the
declaration.
D
So,
if
like
what
we
have
done
in
our
implementation,
is
that
we
have
not
mandated
people
to
like
write
that
field
again
again
in
the
implementing
types,
but
if
they
just
write
it
once
in
the
interface,
and
they
say
that
this
type
a
implements
interface,
I
then
they
don't
have
to
repeat
the
field
again
in
the
type
a
we
just
like
kind
of
get
it
from
the
interface
and
do
it
for
them.
D
So
like
are
there
any
disadvantages
or
any
things
that
are
already
being
thought
about
this
thing
or,
like
anything,
any
feedback
that
you
may
have.
A
A
You
often
find
yourself
clicking
around
documentation
considerably
in
order
to
determine
the
total
set
of
things
which
are
queryable.
So
we
wanted.
A
That
that's
at
least
from
the
introspection
side.
Why,
when
you
ask
for
the
fields
of
a
particular
object,
you
always
get
the
total
set.
The
other
piece
is
that
it's
it's
important
to
clarify
intent,
so
an
interface
you,
you
may
specify
a
field
which
is
more
specific
than
what
an
interface
suggests
that
you
specify.
A
For
example,
if
an
interface
says
this
field
has
no
arguments,
you
can
supply
a
field
which
includes
additional
arguments
because
you've
at
least
satisfied
the
interface
and
now
you've
gone
beyond
that
or
if
your
interface
says
I
returned
something
of
a
union
type
and
your
usage
of
that
says.
Actually
I
only
ever
return
to
a
that's
still
to
bench's
point
about
unions
before
that's
compliant.
This
a
is
in
fact
within
that
union
that
is
safe
to
do.
A
That
allows
you
to
be
more
to
be
crisp
about
the
expectations
of
each
particular
type,
even
in
the
case
when
the
expectation
is
equivalent
to
the
interface,
but
rather
than
that
being
an
implicit
statement.
It's
an
explicit
statement
and
the
the
philosophic
guideline
here
is
that
it
in
general
graphql
always
wants
to
be
more
valuable
to
readers
than
it
is
to
writers
and
that
that
is
particularly
notable
for
anyone.
Who's.
A
Writing
the
graphql,
the
sdl,
the
type
system
definition
language
in
a
trade-off
between
what
would
be
easier
for
someone
to
read
versus
what
would
be
easier
for
someone
to
write.
We
always
go
in
favor
of
what
would
be
easier
to
read,
even
if
that
requires
more
typing,
which
is
different
from
how
a
lot
of
other
programming
languages
operate.
A
But
you
know
it's
not
really
a
programming
language,
it's
a
data
definition
language
and
that
that's
the
philosophy
that
we've
taken
so
far,
so
the
the
that's
kind
of
the
last
trade-off
was
if
you're
reading
this,
then
you,
you
might
read
that
this
implements
an
interface
and
has
three
fields
and
inadvertently
arrive
at
the
conclusion
that
such
a
type
only
has
three
fields
but
fail
to
see
that
that
interface
in
fact
defines
another
one
that
you
might
have
missed.
So
it's
a
a
way
to
avoid
confusion.
H
There's
there's
also
the
point
that
you're,
like
I
work
on
a
tooling
team,
so
like
we
often
have
non-spec
compliant
specs
lying
around
our
code
base,
but
our
tooling
takes
those
non-compliant,
specs
and
converts
them
into
being
spec
compliant
via,
like
automated
transforms.
So
like
we
abuse
the
sdl,
but
you
have
to
you.
It
there's
value
in
making
sure
that
at
some
specific
point
your
sdl
is
spec
compliant,
but
various
tooling
and
whatnot
that
you
provide
it's
up
to
you.
D
Okay:
okay,
oh
okay!
Thank
you
like,
so
those
are
the
only
questions
that
I
had.
Thank
you.
Thank
you
for
your
feedback
and
solutions.
A
Of
course,
anything
else
that
anyone
would
like
to
cover
while
we're
all
here,
it's
the
end
of
our
written
agenda.
E
Just
a
small
note
to
say
I've
there's
more
stuff,
I've
not
done.
I
have
made
a
little
bit
of
progress
on
the
query.
Query
query.
Query
query
topic
that
you
may
remember
from
a
few
working
groups
ago:
oh.
M
Yeah
but
I
have.
E
Yet,
to
turn
that
into
actual
like
a
post
on
the
relevant
issue
thread
because
I've
been
focusing
on
tagged,
I
haven't
forgotten
about
it.
It
is
on
my
to-do
list,
but
it's
it's
below
tagged
right
now,.
F
I
wanted
to
ask
a
short
question
actually
interested
in
input
unions,
but
I
didn't
have
the
time
to
to
join
a
call.
So
is
there
a
any
reason
why
you're
not
recording
input
union
working
group
and
can
be
recorded
in
future,
especially
since
we.
Q
I
think
there
might
have
been
three
total,
so
you
you
have
recordings
they're,
just
not
on
youtube.
At
least
one
of
them's.
F
One
of
them
on
youtube;
okay,
I
missed
it.
Okay,.
A
Yeah,
I
would
consider
we're
now
on
the
the
tailing
edge
of
getting
good
hygiene
of
recording
meetings,
and
I
think
the
first
of
those
meetings
was
maybe
in
april.
If
that's
right
and
I
think
it's
possible
that
one
or
two
of
them
was
not
recorded
the
I
I
think
the
one
in
may
was
one
where
we
made
significant
traction
so
that
one
was
recorded.
We
also,
I
benji.
I
think
you
took
notes
on
those
as
well.
If
I
remember
correctly,.
E
Yeah,
I've
posted
both
the
video
link
to
youtube
and
the
notes
that
we
took
to
the
relevant
issue.
That's
in
the
action
items
that's
linked
in
the
top
of
the
notes.
Currently,
I
think
so
yeah
it
does.
It
does
exist,
but.
F
I
felt
like
you
met
this
month
because
benjamin
just
posted
it's
like
major
post-it
notes
for
three
months
ago:
oh
yeah,
okay,
because
that
was
confusion.
I
thought
you
had
the
meeting
quick
this
month
and
I
thought
I
missed
it
and
I
wanted
to
see
a
video
of
it.
Okay,.
E
A
Yep,
that's
the
that's
the
ethos
of
our
group,
sorry
to
be
self-deprecating
one
one
other
thing
I
wanted
to
ask
y'all:
is
we
right
now
we
manage
rfcs
in
the
graphql
spec
repo,
but
then
the
actual
discussion
and
notes
happens
in
the
graphql
working
group
repo.
A
I
wanted
to
pose
the
a
potential
suggestion
to
move
basically
just
move
the
rfc
folder
from
the
graphql
spec
repo
to
the
graphical
wwg
repo,
just
so
that
all
of
the
place,
all
the
stuff
that's
like
about
ongoing
rfcs
is
in
one
place,
and
that
way
the
graphql
spec
from
from
here
on
forward
would
be
like
purely
about
the
things
that
actually
land.
A
Obviously
the
the
exception.
There
would
be
a
actual
pull
request
to
the
spec
text,
but
that
way
like
stuff,
that's
work
in
flight.
That's
not
quite
at
the
phase
where
it's
a
spec
pr
can
have
a
place
that
has
a
like
a
lower
barrier
to
entry
for
merging
emerging
changes.
F
Try
not
to
screw
it
up
so
just
to
clarify
if
we
much
rfc
into
graphical
working
group
and
we
not
in
a
stage
that
we
have
appear
against
a
spec,
how
person
can
track
stages
so
like
right
now
he
can
go
to
pr's
and
see
like
where
every
what
is
the
stage
of
every
proposal
is
in
issues
or
impairs
how
it's
done,
if
you
don't
have,
if
you
don't
have,
if
we
match
rfc
into
working
group
is
smoother
and
if
we
keep
all
the
issues
in
working
group,
so
we
basically
have
a
split
between
like
small
issues
on
graphql,
spec
and
big
issues
on
working
groups,
so
without
any
table
or
anything,
it
would
be
confusing
for,
like
people
prepare
talks,
rob
give
a
good
talk
about
so
like
for
people
who
want
to
monitor
what's
happening,
it
will
be
harder
for
them.
A
That's
a
good
point.
I
will
probably
add
something
to
the
readme.
That
makes
it
clear
that
proactive
discussion
around
proposals
for
change
happen
in
the
working
group
and
to
point
there
just
so
that
if
people
find
themselves
here-
and
they
want
to
find
that
stuff,
they
can,
they
can
go
there.
A
And
I
the
reason
why
I
propose
this
is
that
it
brings
us
one
step
closer
to
a
place
where
I'd
like
to
get
to
where
we
can
have
sort
of
a
master
list
of
all
of
the
topics
under
discussion
who
their
champions
are
and
then,
where
the
relevant
content
is
right.
Now,
that's
just
kind
of
like
in
agendas
month
to
month
and
that's
okay,
but
as
we
take
on
more
things
and
as
the
set
of
people
who
join
these
meetings
continues
to
grow
and
rotate.
A
P
Things
I
also
would
say
that
this
this
gives
more
value
to
all
events
from
the
graphql
spec
repo,
like
I'm
following.
I
I'm
getting
notifications
for
everything
the
thing
in
the
craft
perspective
and
kind
of
separating
this
would
make
it
like
the
signals
more
valuable,
because
then
every
pull
request
inside
there,
which
is
not
garbage,
is
really
like
high
value
and
really
discussed,
and
it's
separated
from
the
initial
more
chatty
upfront
discussion
right.
So
this
is
my
personal
benefit
from
it.
A
O
A
I
feel
like
we
get
decently
high
value
things
that
come
through
issues
and
there
it
is,
I
think,
worthwhile
to
have
a
distinction
between
issues
against
the
spec
versus
like
we
right
now.
We
use
issues
for
the
working
group
for
internal
action
items
things
that
we
that
we
need
to
take
action
on
as
a
working
group
and
it
might
be
worthwhile
like.
I
think
it
might
be
worthwhile
to
keep
that
separate.
P
You
want
to
not
discourage
people
to
ask
questions
and
engage
right.
Like
I
don't
know,
maybe
a
graphic
respect
without
any
issues
is
kind
of
a
high
entry
burden
for
people
who
who
are
not
sure
what
to
do
and-
and
I
I
I
don't
feel
like
we're
getting
spammed
inside
the
craft-
goes
back
with
issues.
So
I
like
the
idea,
but
maybe
it's
kind
of
it's
a
little
bit
too
far,
just
a
gut
feeling.
A
A
Has
this
work
in
progress
documents
that
that
kind
of
litter
the
commit
history
of
the
spec
repo
and
just
like,
there's
a
maintenance
burden
of
teasing
apart
what
our
pull,
requests
and
issues
that
are
relative
to
internal
discussion
amongst
the
working
group
and
what
are
relevant
to
just
this
final
spec
changes
themselves.
F
Actually,
I
think
we
can,
if
we
write
a
document
with
policies
we
can,
if
somebody
become
a
champion,
we
can
just
give
them
commit
rights
if
they
have
a
policy
of
like
how
much
time
there
should
be
open
to
get
review
comments
and
what
can
be
much
immediately
so
like
it's
would
be
self-service.
F
I
think
it's
because
like,
for
example,
yeah
unless
some
stuff
from
more
streaming
differ,
but
some
stuff
need
to
be
rebased,
so
I
ping
robbed
her
by
them
and
robert
base.
That's
another
like
couple
of
weeks
before
I
have
a
chance
to
look
into
this
repo,
so
it's
like
slow
down
things
so
yeah.
Actually,
in
that
case,
I
see
a
value
of
more
empowering
champions
to
actually
do
their
own
maintenance,
and
we
have
like
fast
progress.
F
A
We
can
we
could
be
much
more
liberal
with
giving
commit
access
to
the
wg
repo,
for
we
don't
really
have
a
good
definition
of
what
a
a
core
contributor
is
versus
a
like
a
visiting
contributor.
That's
okay,
like
anyone
who's
like
a
a
frequent
guest
of
these
meetings,
will
just
start
to
give
you
commit
access
to
and
and
that's
probably
reasonable,
and
if
we
need
to
define
it
further
than
that,
we
will.
F
Think,
like
we
have
a
clear
difference
right
now,
so
if
you
champion
something
and
you
have
rfc
you
have
it
just-
you
promise
not
to
not
too
much
anything
in
other
person
rfc.
So
only
in
your
own
rfc,
and
I
think
github
has
some
mechanics
for
that
when
you
can
assign
folders
to
to
reviewers
or
something.
A
Good
point:
okay:
I
will
take
an
action
item
to
make
that
happen.
Okay,
everybody!
That's
our
full
agenda
for
the
day!
Thank
you
all
for
joining.
I
hope
you're
all
safe
and
happy
and
your
families
are
all
healthy,
look
forward
to
seeing
everybody
next
month
and
continuing
to
make
progress
on
all
the
things
we're
doing
in
our
own
little
bubble
in
a
crazy
world
thanks.
Everyone
thanks.