►
From YouTube: GraphQL Working Group - September 2, 2021
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).
B
Good
good
long
time
no
sees
since
we
skipped
the.
B
I
definitely
agree
I
am
when,
when
I
read
the
example
yvonne
gave
and
that
spec
pr
it's
like
man,
that's
clearly
wrong.
You
gotta
fix
that.
I
think
the
tricky
part
is
knowing.
If
the
fix
is
the
right
fix,
but
yeah
yeah
interesting,
I
did.
I
got
a
message
from
matt
mahoney
saying
that
he
may
be
a
little
bit
late,
and
so
I
think
that's
the
other
major
thing
for
us
to
dig
into
which
is
a
little
bit
sad,
because
that's
the
one
that
we
punted
from
last
month
to
this
month.
B
I
think
all
the
the
crazy
hurricane
rainstorm
that
the
east
coast
has
gotten
provided
some
flood
damage
to
his
house
so
which
sucks
dealing
with
the
contractor
right
now
to
figure
out
what
a
clean-up
process
is
going
to
be.
Oh,
my
god.
D
Yeah
but
the
the
bay.
C
B
B
Air
quality
is
not
so
great
today,
I
think
it's
the
there's
a
big
fire
near
lake
tahoe,
which
is
about
a
four
hour
drive
from
where
we
are,
and
I
think
the
wind
is
blowing
down
in
the
direction
of
the
bay
area,
but
that's
that's
the
worst.
We
have
to
complain
about
that
and
it
never
rains
here
so
we're
just
like.
We
complain
about
drought.
Meanwhile,
the
east
coast
of
the
us
is
like
under
a
foot
of
water,
so.
B
Totally
cool:
hey,
camille,
how's
it
going
hey
hi,
everyone.
B
So
looks
like
based
on
the
pull
requests,
we'll
have
a
light
attendance
which
is
totally
fine
and,
like
I
said,
that's
going
to
be
late.
If
he's
able
to
join
so,
maybe
we'll
stick
it
out
for
a
couple
minutes
just
to
at
least
get
I
assume
ivan
will
join
since
he
added
his
agenda.
A
Could
you
pop
up
a
google
doc,
please
lee.
B
B
A
A
B
I'm
in
the
middle
of
writing
a
blog
post
about
not
over
optimizing,
but
over
generalizing.
B
All
right
we're
about
five
minutes
in
so
maybe
we'll
get
started,
and
since
we
have
a
fairly
light
agenda
today,
I'm
hoping
that
we
can
do
a
little
bit
more
of
a
deep
dive
in
action
items,
since
usually
we
whizzed
through
those
and
there's
like
a
little
over
a
dozen
that
have
been
there
for
a
long
time.
B
Oh
hey
check
that
out.
We
just
got
a
bunch
of
people
at
once:
sweet.
B
B
All
right
light
crew
today,
but
that
hopefully,
will
just
streamline
things
all
right
as
a
quick
reminder
at
the
top
by
participating
here.
Of
course,
we
all
agree
to
membership
agreement,
participation,
guidelines
and
code
of
conduct.
Links
in
the
agenda
file
as
per
usual
go
check
those
out.
If
you
want
to
get
a
closer
read.
B
Let's
do
a
quick
run
through
of
attendees.
Hopefully,
that'll
be
quick
and
easy.
Since
there's
only
a
handful
of
us,
everybody,
I'm
lee,
I'm
good,
I
think
ivan
you're
next
in
the
fun.
G
G
On
positive
note,
it's
like
split
between
foundation,
work
and
power.
So
I'm
on
a
currently
on
a
power
server
team,
open
source,
apollo
server
team,
and
I
will
continue
to
do
foundation
work
as
part
of
football.
B
That's
awesome,
congrats
on
the
role
change.
I
don't
recognize
your
location
today.
Where
are
you
right
now.
B
B
Great,
we
actually
are
talking
about
doing
a
in-person
graphical
conference
in
the
middle
of
next
year.
I'm
sure
there
will
be
others
too.
I
don't
know
when
the
others
will
move
back
to
in
person,
but
I
can
tell
you
all
about
that
more
in
a
little
bit
all
right.
Next
up,
benji.
A
B
H
Camille
yep
yeah,
so
I'm
camille
currently
in
warsaw
in
poland,
and
I
work
with
foreign.
I
think
you
know
I'm
part
of
the
guild
so
yeah.
We
basically
do
consulting
and
a
lot
of
libraries
and
tools
around
graphql
pretty
much
and
it's
my
first
time
in
this
working
group,
so
yeah
welcome.
B
Glad
to
have
you,
I
see
matt's
next
in
the
list,
but
he's.
I
All
right,
I'm
morris,
I'm
from
ibm,
there's
several
different
graphql
things,
I'm
interested
in.
We
work
on
a
graphql
proxy,
so
we
sit
between
the
client
and
server
and
therefore
have
to
know
all
kinds
of
things
about
that
different
people
intended
from
graphql.
So
we're
interested
in
various
back
issues
and
everybody
talk
to
me.
Talk
more.
D
Hi,
I'm
michael
and
I
work
for
chili
cream
and
we
are
basically
working
on
the
net
implementation
of
graphql.
B
All
right
thanks,
everybody
and
I
see
benji-
is
already
hard
at
work.
Translating
the
agenda
into
a
notes
file
anybody
willing
to
jump
in
and
help
with
note-taking,
especially
if
benji's
going
to
engage
in
some
discussion.
B
Awesome,
thank
you
find
the
google
docs
link
at
the
top
of
the
file.
If
anybody
else
wants
to
jump
in
and
help
out
at
any
point,
and
thank
you,
benji
for
being
our
note-taking
lead
as
per
usual.
Much
appreciated.
B
Okay,
let's
take
a
quick
look
at
our
agenda,
which
is
fairly
lightweight
and
just
make
sure
this
is
covering
everything
we
want
to
talk
about
today.
Three
major
things:
one
we're
going
to
go
through
the
action
items
since
we
do
have
a
light
agenda.
I
want
to
go
through
our
backlog
of
action
items
a
little
bit
with
a
little
bit
more
time
than
we
would
usually
spend
just
to
see.
If
there's
anything,
we
can't
divvy
up
and
just
kind
of
get
done.
B
B
That
way,
he's
here
to
lead
that
discussion,
if
he's
not
able
to
make
it
in
time,
we'll
just
punt
it
to
next
months
again
and
then
super
interesting
pull
requests
that
yvonne
put
up
on
field
selection,
merging
there's
one
thing
that
I
do
want
to
add
that
I'm
gonna
add
to
the
agenda
now:
there's
a
discussion
that
andrew
ingram
posted
in
the
working
group
channel
and
discord
early
this
morning,
and
he
and
I
had
a
little
bit
of
back
and
forth
right
before
the
meeting
started,
and
so
I'll
drop
a
link
to
that.
B
It's
about
what
we
should
and
shouldn't
allow
directives
to
do,
which
I
think
is
quite
interesting.
So
if
we
have
time,
I
think
it'd
be
interesting
to
talk
about
that
anything
else
that
we
want
to
talk
about
here.
J
B
We
just
got
to
intros,
so
you're
you've
missed
basically
nothing.
Oh.
E
B
Yeah,
let's
do
that
just
adding
that
link
to
the
discord
discussion
here,
real
quick-
and
we
can
do
that
so
yeah
matt
since
you're
here
for
now,
let's
jump
into
the
fulfilled
discussion.
J
Yeah,
so
the
background
behind
the
fulfilled
discussion
was
basically
at
facebook.
We've
been
moving
more
and
more
to
having
fragments
be
the
unit
of
like
how
people
interact,
how
client
developers
at
least
interact
with
graphql.
So
we've
moved
almost
to
the
point
where,
like
when
you
in
your
client
code,
are
accessing
some
child
fragment.
You
have
to
explicitly
do
like
a
dot
as
this
child
fragment.
J
In
order
to
be
allowed
to
start
accessing
those
child
friends
fields,
the
fulfilled
label
was
meant
as
one
potential
way
that
we
can
basically
allow
us
to
say:
hey
this
fragment
is
deferred
right
now,
or
this
fragment
was
not
deferred.
We
can
actually
access
it.
We're
allowed
to
convert
into
it
with
the
so
we
discussed
on
discord
last
month
and,
like
it
I'll
put.
J
The
the
alternatively
proposed
was
basically
using
keyed,
fragments
or
keyed
fragment
spreads
of
some
form,
and
I
think
that
is
a
that,
like
basically
ends
up
making
matching
exactly
with
how
we
do
fragment
like
spreads
at
facebook,
so
that
that
was
an
interesting
discussion.
J
Yeah,
you
can
use
it
for
things
like
that.
Basically,
the
fulfilled
meta
field-
all
it
says,
is
that
this
selection
set
that
I'm
on
was
in
fact
fulfilled
okay,
so
so
long
as
we
as
long
as
the
executor
enters
that
selection
set,
then
fulfilled
will
be
true.
J
And
so
the
like
are
like
in
a
long-term
vision
of
why
we
might
want
something
along
these
lines.
Is
that
we're
trying
to
make
it
so
that
the
like?
You
have
to
the
rules
that
require
you
to
basically
introspect
on
an
entire
document
or
have
knowledge
of
an
entire
graphql
document?
J
In
order
to
say
whether
your
fragment
is
valid
in
that
document,
we
would
like
to
basically
eliminate
all
of
those
so
that
you
could
know
directly
at
the
fragment
spread
level,
whether
like
you
should
only
ever
have
to
go
one
level
deep
in
order
to
validate.
So,
if
I
have
a
fragment
a
and
I'm
spreading
a
fragment
b,
I
should
be
able
to
know
hey
this
fretting
spreading
fragment
b
is
valid
here
for
any
query
that
spreads
a
in
a
valid
way,
but
but,
as.
D
J
So
that
was
the
reason
to
add
to
be
fair,
this
this
rfc
may
be
ahead
of
itself
where
there
might
be
a
required
rfc
for
allowing,
for
instance,
canonical
named
responses
in
order
to
allow
overlapping
fields
with
the
same
arguments,
and
this
rfc
like
once,
you
have
that
requiring
a
label
basically
for
the
fulfilled
field
and
saying
hey:
this
is
the
fulfilled
field
with
label.
Foo
would
tell
you
okay.
A
E
B
G
Yeah,
I
have
a
question
because
I
think,
like
it's
a
little
bit
too
generic,
I
think
like
it's,
maybe
too
generic
for
a
task
at
hand.
G
G
If
you
give
a
nickname
to
aliases,
you
can
give
your
nickname
to
fragments,
and
we
can
because
I
recognize
as
a
real
issue.
I
just
think
waiting
like
some
some
generic
and
broad
thing
to
solve
this
problem,
and
I
don't
see
it
being
useful
in
for
something
else.
A
Yeah
I'd
like
to
understand
why
you
can't
already
do
this
with
type
name
and
aliases.
J
Yeah,
so
you
can,
it
is
possible
to
do
with
type
name
and
aliases,
it's
the
issue
being
if
we
start
doing
this
in
many
many
places,
the
cost
of
that
additional
type
name
in
the
response
is
actually
relatively
high,
like
one
argument
for
doing
using
an
underscore
score,
fulfills
field,
as
opposed
to
a
as
opposed
to
keyed
fragments,
is
that
the
fulfilled
field
is
almost
necessarily
less
expensive
in
terms
of
like
the
overall
response
size.
J
J
Indicates
you
the
response.
Probably
shouldn't
have
a
string
as
the
response.
It's
like
it's
it's
kind
of
an
idiomatic
mismatch,
but
for
like
being
able
to
have
this
behavior,
that's
exactly
what
we
do
today
like
that's.
What
relay
does
in
some
instances?
That's
what
various
clients
do.
B
That's
a
cool
idea,
though.
The
idea
that
the,
if
the
the
main
semantic
fulfilled,
is
that
it's
a
field
that
always
returns
true,
then
like
really
the
value
that
you
derive
from
it
aside
from
the
cement
like
what
it
means.
Semantically,
is
that
you
have
a
field
which
is
inexpensive
to
query
and
gives
you
another
value,
which
type
name
also
satisfies,
and
so,
if
the
main
thing
that
you
get
from
it
is
to
have
different
aliases
at
different
levels.
In
the
query,
you
can
essentially
polyfill
for
lack
of
a
better
term.
D
J
Yeah
one
interesting
thing
here
is
recognizing
that
graphql
says
nothing
about,
or
does
not
say
that,
like
the
response
needs
to
come
in
json
format,
it
uses
json
as
the
examples
of
how
the
response
would
come
back
but
like
it
is
valid
to
have
a
graphql
implementation
that
doesn't
that
works,
for
instance,
with
flat
buffer
formats,
or
you
know,
basically,
whatever
arbitrary
formatting
you
want
and
in
a
sense
the
underscore
underscore
fulfills
meta
field
is
a
way
like
this
problem
that
it's
trying
to
solve
is
keeping
is
basically
in
a
json
response,
keeping
that
json
response
small
while
simulating
keyed,
fragment
responses,
and
given
that
I
probably
like,
I
don't
think
that
this
rfc
is
like.
J
D
Are
you,
are
you
guys
already
using
it
in
experimental
for
relay.
J
So
we
are
experimenting
with
a
canonical
response
format,
but
our
actual
client
interactions
behave
via
alias
format,
so
we're
basically
experimenting
with
this
and
for
the
canonical
format.
We
are
using
a
field
very
similar.
We
haven't
named,
it
underscore
underscore
fulfilled,
but
the
yeah.
Basically,
we've
broken
the
response
format
in
this
experiment.
B
Do
we
expect
this
kind
of
like
I
wonder
how
tightly
is
so?
I
understand
the
general
problem,
which
is
you
want
to
have
an
understanding
of
which
fragments
were
or
not
included
during
the
execution
of
a
query
which
becomes
especially
more
useful
when
you
introduce
stream
and
defer?
B
Cool
that's
helpful,
because
if
the
intent
here
was
to
give
human
authors
more
understanding
what's
going
on,
then
we
would
want
to
optimize
for
semantics
and
understandability.
And
if
that's
that's,
not
the
intent,
then
we
should
optimize
for
just
satisfying
the
use
case
in
a
simple
form
as
possible.
I
J
Spec,
it
can
be
used
as
a
wire
format
spec,
but
it
is
not
like
inherently
one
leads
me
to
believe.
It
might
be
useful
to
have
a
few
like
to
have
an
optimized
wire
format
spec
for
graphql
somewhere,
and
if
we
had
that
it
would
be
interesting
to
like
if
we
had
that
and
all
graphql
servers
and
by
default,
clients
supported
that
optimized
spec.
J
That
might
give
us
more
leeway
to
do
things
like
keyed
fragment,
spreads
that
where
the
like
access
pattern
is
inherently
not
optimized.
If
that
was
the
json
response
format,
but
like
the
actual
cost
for
the
optimized
response
would
be
pretty
low
or
there's
like
a
way
to
translate
to
and
from
the
optimized
response.
J
Yeah
and
there's
there's
probably
a
really
large
space
of
potential
like
solutions
optimizations.
Do
we
like
potentially
like
giving
the
client
it
in
like
a
response
where
the
it's
key,
like
it's
more
like
a
graph
in
format
rather
than
a
tree,
or
something
like
that
like
there's,
there's
a
lot
of
potential
options
to
explore
and
that
would
be
interesting
to
explore.
But
that
would
be
a
much
much
larger.
B
Yeah
there
is,
there
are
some
some,
not
necessarily
wire
protocols,
but
just
like
derivations
of
json
that
allow
you
to
do
this
kind
of
thing,
like
the.
I
think
what
you're
talking
about
here
is
the
key
limitation
of
json
is
that
it
can
only
represent
a
tree
and
it
cannot
represent
a
dag,
and
if
you
want
to
say
this
value,
which
appears
in
two
separate
locations
of
the
tree
is
like
identically
the
same
value
and
therefore
I
don't
want
to
repeat
it
like.
B
You
can't
do
that
if
you
are
forced
to
represent
your
dag
as
a
tree,
you
have
to
duplicate
it.
I
don't
know
that
we
have
enough,
like.
Does
the
spec
give
us
enough
metadata
to
even
produce
like
if
you
wanted
to
go,
experiment
and
say
hey,
I'm
gonna
go
like
make
a
not
like
a
graphql
specific
wire
format,
but
I'm
gonna
go
use.
One
of
these
wire
formats
that
lets
you
reuse.
B
J
J
Way
of
jump
starting
the
discussion,
but.
K
Yeah,
when
you're
talking
about
the
you
know
kind
of
a
normalized,
you
know
transport
of
a
foul
coordination
graph
format,
which
is,
you
know,
basically
kind
of
doing
that
for
the
wire,
but
then
on
the
other
side
of
it.
Just
as
far
as
like
you
know,
binary
like
flat
buffer
or
you
know,
thrift
or
or
sebor
do
we
know,
is
there
prior
art
that
is
kind
of
like
in
production,
widely
known
that
anybody's
doing
that,
because
I've
always
wondered
because
I
mean
it
seems
like
a
natural
thing.
K
I
think
that's
may
do
at
some
point,
but
I
just
haven't
seen
anyone
here.
There's
the
same
thing.
J
There
was
one
effort
at
facebook
to
use
flat
buffers
as
the
response
format.
Basically,
at
the
time
that
graphql
was
being
open
sourced,
but
so
I
imagine
most
people
don't
because
it
one
adds
a
lot
of
complexity
and
two.
You
only
start
seeing
results
when
you
have
incredibly
deeply
nested
complex
responses
like
I
think
at
the
time
that
it
was
open.
J
Source
facebook's,
like
gnarliest
query,
was
like
30
levels
deep
in
the
tree
or
something
like
that,
and
it's
it's
grown
significantly
worse
than
that
now,
but
like
unless
you're
hitting
that
scale,
even
json,
that
has
lots
of
duplication,
probably
mostly
doesn't
matter
for
you.
B
Don't
quote
me
on
that?
I
might
be
wrong,
but
that's
my
understanding.
J
A
Just
just
spitballing
a
little
bit
trying
to
think
of
other
uses
for
this
kind
of
field
there.
There
have
certainly
been
times
when
people
want
to
see
like
constant
strings
in
a
graphql
schema,
and
obviously
you
can
return
that
with
a
field
but
having
something
that
was,
for
example,
like
effectively
the
identity
function,
like
you
feed
in
an
argument,
and
you
get
that
argument
straight
back
could
actually
enable
quite
a
lot
of
possibilities,
whilst
also
solving
your
problem.
It
wouldn't.
However,
you
know
do
it
as
a
boolean.
A
B
B
I
haven't
thought
through
all
the
implications
of
it,
but
I
think
it's
an
interesting
idea
and
it
it's
feels
like
one
half
of
a
whole
conversation
of
like
what
are
the
things
that
we
should
be
able
to
alias
right
now.
The
answer
that
is,
we
alias
fields
that
we
can
query
but
like
what,
if
you
could
alias,
I
like
the
idea
of
thinking
about
it
as
an
identity
function.
B
That's
that's
a
cool
idea
and
maybe
an
interesting
way
to
kind
of
do
it
without
any
adding
any
new
syntax
which
is
cool,
the
other
would
be
matt.
I
think
you
already
thought
about
this.
The
like
aliasing,
the
fragment
itself
such
that
you
like
chunk
out
a
subset.
You
know
it's
like
pretty
obvious
if
that
fragment
is
included,
because
the
field
and
the
response
body
would
be
there
or
not
either
right.
J
The
responses
instead
like
even
if
you
have
an
alias
the
response,
is
my
field
with
arguments,
and
the
label
is
a
way
for
you
to
basically
as
an
alternative,
to
aliasing
a
way
to
differentiate
those
fields
in
an
alias
based
world.
It
probably
doesn't
have
very
much
value.
B
So
that's
a
specific
feature
to
handle
a
constraint
that
the
relay
store
provides,
which
is
the
aliases,
is
a
is
a
runtime
concept
and
not
a
store
concept,
and
so
you
want
to
make
sure
you're
not
losing
information
but
like
maybe
a
server,
would
the
server
need
to
then
like?
Would
you
maybe
model
this
in
a
way
where
the,
if
you
were
going
to
support
this
on
a
server,
the
server
doesn't
need
this
label
information,
since
it
is
an
alias-based
world.
So
you,
like
format
the
query
in
that
way.
B
J
B
That's
a
good
question
because
I
feel
like
the
the
main
reason
that
I'm
gonna
push
on
this
one
for
us
to
find
alternatives
is,
is
actually
it
is
hard
to
come
up
with
the
name
that
clearly
describes
what's
going
on
here.
Fulfilled
implies,
even
if
it's
a
boolean
that
it
could,
or
it
may
or
may
not
be
fulfilled,
and
therefore
false
might
be
a
reasonable
value.
But
actually
you
can't
ever
get
false.
B
It's
like
definitionally
like
if
a
field
is
queried,
then
it's
fulfilled,
and
so
that
I
think,
is
just
kind
of
inherently
confusing
just
from
a
semantics
point
of
view
and
like
if
this
is
the
path
we
want
to
take
like,
I
actually
kind
of
prefer
something
that
just
makes
it
more
clear
that
this
is
just
like
a
value
that
is
always
true
but
which
makes
me
think
like.
I
don't
know
that
this
is
necessarily
the
right
way
to
go
about
this
in
terms
of
like
the
intent
fulfilled.
B
B
I
A
B
Okay,
my
sense
is
that
the
next
step
is
to
go
broad
like
we
know.
We
now
know
one
pretty
clear
path
that
would
solve
the
inherent
problem.
I
think
the
inherent
problem
is
very
interesting
like
how
do
you?
How
do
you
know
what
fragments
were
included
in
a
particular
query
execution,
whether
that's
like
a
static
query,
execution
or
one
that
in
the
future
could
include
deferred
stream,
but
I
think
we
need
to
more
reasonably
explore
the
other
alternatives
just
to
yeah.
I
agree
be
able
to
weigh
against
me.
B
Sweet
nice
discussion.
Thank
you.
Let's
bounce
backwards,
one
step
in
the
agenda
and
do
some
action
items.
B
I
took
a
quick
look
and
I'm
pretty
sure
we
don't
have
anything
ready
for
review
right
now,
but
in
the
all
open
action
items
there
are
currently
14
open
action
items,
so
I
thought,
maybe
be
worth
just
going
through
these
a
little
bit
and
seeing
if
any
of
these
are
stuck
if
any
of
these
are
just
kind
of
floating
and
waiting
or
if
we
can
like
do
something
about
some
of
these.
B
There's
one
in
here
from
september,
4th
2020,
which
is
now
officially
an
entire
year
old,
create
a
pr
merging
policy
and
grant
more
contributors,
maintenance
access
to
the
working
group
repo.
B
B
G
Yeah,
I
think,
if
I'm
confusing,
with
with
other
action
item
idea,
was
that
it
was
based
on
put
union
situation
and
other
active
rfc
over
time
and
problems
that
we
need
to
give
every
time
we
need
to
give
commit
access
and
it's
not
like,
usually
people
creating
big
characters.
G
G
This
was
idea
so
moving
rfcs
out
of
spec
repo
into
working
group,
repo
and
figure
out,
like
some
short
description
of
how
this
process
look
like.
Should
we
like
at
a
walk,
commit
rights
or
should
like
people
have
it,
and
definitely
things
like
that?.
D
I
think
I
remember
this
discussion,
but
we
could
also
have
it
more
clean,
have
a
separate
repo
for
that,
but
we
really
have
a
more
open
rip
or
graphical
rfc,
or
something
like
this.
G
I
I
would
suggest
not
to
create
more
ripples,
because
it
will
confuse
people
even
more.
I
think
rfc
process
is
inherently
connected
to
working
group
agendas
and
stuff
because
white
clippers
we
like
protester,
plus
on
the
plus
side,
if
a
person
opened
working
group
repo
and
see
like
a
folder
with
like
finished
rfc,
so
merger.
If
she
he
can
see
forward
and
he
can
see
good
examples
of
of
stuff
as
much.
G
B
Okay,
this
is
great
thank
you
for
folks,
with
better
memories
of
myself,
I'm
taking
a
couple,
quick
notes,
just
in
that
issue
itself,
which
I
just
added,
so
I
will.
I
will
do
both
of
those
two
things
I'm
going
to
move
the
rfc
directory
into
the
working
group
repo,
I
think
actually.
Basically,
that
makes
sense.
I'm
trying
to
remember
why
we
had
it
set
up
that
way.
B
I
think
we
initially
ran
the
working
group
out
of
the
spec
repo
and
maybe
that's
the
case,
but
it
kind
of
makes
sense
that
we
would
have
the
the
shared
like
notes,
files
and
rfc
files
that
we're
working
on
together
here
in
the
working
group
repo.
B
So
that
makes
sense
to
me
and
that
should
allow
us
to
add
plenty
more
people
with
commit
rights
to
this
repo,
and
the
other
thing
that
I
put
in
here
is
I'm
gonna
write
a
little
bit
to
the
the
readme
file,
the
readme
file
in
the
graphql
spec
repo.
B
We
probably
need
to
completely
rewrite
that
at
some
point
anyway,
it's
like
a
big
explainer
on
graphql
and
that's
probably
the
wrong
place
for
that.
Now
that
we
have
a
website
and
a
spec
and
like
a
bunch
of
other
places
where
we
would
want
that
information.
But
in
the
meantime
we
have
a
much
healthier
readme
in
the
working
group,
repo.
So
I'll
update
that
oh
and
last
one
that
I'll
add
to
this
to-do
list
is
to
add
a
bunch
of
contributors
via
a
team.
B
Next
oldest
is
update
agendas
to
recommend
adding
the
github
username,
because
we-
because
that
makes
it
hard
to
tag
action
items
and
then
we
said
we
loved
that
idea,
and
then
we
never
updated
the
agenda
template.
Did
we?
B
Let's
just
let's
just
okay,
I'm
not
gonna
waste
your
all
time
and
do
this
live,
but
this
one
seems
pretty
straightforward.
I
will
do
this
for
the
I
think,
october
and
november
templates
are
open.
Still,
here's
the
like
real
stupid
thing
that
I
think
I
should
do.
Let
me
know
if
this
is
dumb
enough
to
work.
B
A
Rather
than
making
it
a
link,
can
you
just
add
you
know
at
lea?
After
would,
because
it
makes
it
easier
to
to
reference
it
and
copy
rather
than
having
to
like
you
know,
hover
it
and
see
what
the
link
is
and
such
yes.
E
I
B
I
have
this
in
whatever
the
oh
I
had
this
sorted
by
when
they
were
last
updated,
not
when
they
were
created
so
yeah
you're
totally
right.
Let
me
sort
by
I
mean
I
don't
mind,
whichever
oldest
no
totally
but
you're,
probably
falling
wrong
being
like
why
the
hell
is
he
jumping
all
over
the
place?
Okay,
yeah,
I
actually
sorted
by
created
ascending
so
september,
so
there's
a
couple
of
these
that
are
all
a
year
old.
B
Let's
see
if
we
can't
just
like
not
end
up
with
multi-year
old
issues
or
action
items
license
is
missing
in
the
scalar
subproject.
B
Who
do
we
have
that's
that
are
helping,
maintains
the
scalar
sub
project,
I'm
noticing
a
trend
where
a
lot
of
these
are
stuck
on
me.
So
yeah.
D
It's
a
bit.
The
problem,
I
think
was
the
the
so
any
any
is
solely
doing
it,
but
the
problem
with
the
scada
is
that
it's
not
prominent
enough.
We
are
not
pushing
people
towards
it.
D
A
possible
thing
to
prevent
others,
but
also
there's,
for
instance,
the
the
geojson
scadas
that
I
think
every
server
implements
them
a
bit
differently
would
be
a
potential
thing
to
move
them
right.
I
D
It
doesn't
inherit
it
anymore,
graphql
is
scaled
as
def
or
I
think
com
is
the
right
one.
Graphql
scalers
com,
the
other
one,
is
the
skater
said
the
guild
is
building.
D
G
D
G
Ui
or
stuff
like
this,
we
need
some
document
on
this
repo
and
we
need
to
reference
that
somehow
so
like
the
idea
was
a
folder.
So
but
the
question
is
not
about
that
question
was
what
what
I
tried
to
say.
It's
like
nga
and,
like
others,
had
the
initial
push,
but
when
we
when
we
lost
it
in
like
with
small
details,
so
maybe
it's
worth
to
have
concrete
goals
like
like
getting
daytime
somehow,
since
it's
unique
our
urls,
we
can
change
like
format
measure
and
keep
like
daytime.
G
I
Yvonne
was
talking
about
us.
We
we
met
like
a
year
ago
and
discussed
that
and
that's
when
we
made
this
new
repos,
the
one
I
put
in
the
chat.
It's
gra,
it's
graphql,
github,
slash,
graphql,
scalers
and
andy
also
agreed
andy
wanted
to
agree
that
she'd
be
at
somewhere
where
no
individual
company
or
individual
person
you
know,
is
the
source
of
failure
for
that
existing,
and
so
you
know
better
and
if
people
search
it
to
be
there
and
that's
what
ivan
was
talking
about
that.
I
There
was
an
idea
that
maybe,
under
there
we'd
put
just
like
any
individual
or
company,
could
have
their
own
sub
directory
under
there
and
put
their
own
specs,
which
have
no
commitment
from
the
graphql
foundation.
But
it's
just
out
there
as
a
central
repository
to
look
for
it.
But
that's
where
I
was
saying
that
one
still
has
not
gone
in
the
daytime.
It's
still
got
absolutely
zero
specs
in
it,
but
but.
D
But
I
think
one
of
the
advantages
is
that
that
anyone
can
just
create
a
spec
in
any
quality
and
if
it's,
if
it's
picked
up
by
the
community,
it's
easy
to
build
into
tools
or
if
we,
if
we
hinder
the
the
evolution
on
those
specs.
I
think
we
also
don't
get
a
lot
of
traction
on
it.
So
I
I
agree
with
I
agree
with.
D
D
So
if
a
graphql
is
a
server
s,
it
has
a
scalar
that
is
specified
by
this
spec
tool
could
support
it
if
it
decides
to,
but
at
the
moment
this
is
hindered
because
nobody
knows
about
this
page,
I'm
in
issues
referring
to
this
this
website
at
the
moment
from
andy-
and
we
are
also
refer
referencing
our
day
time
to
that,
but
there's
just
this
date
time
and
it
doesn't
get
any
traction
because
it's
not
owned
by
the
graphical
foundation.
B
Okay,
to
bring
this
back
to
the
action
item,
this
is
a
little
bit
of
a
cart
for
the
horse
right.
The
real
problem
is
that
we
have
a
project
which
we
would
like
to
have
some
life
breathed
into
it,
and
instead
what
we
have
is
a
repo
with
the
readme
file
in
it.
So
the
license
is
not
really
the
thing
that
is
blocking
here
and
there
is
actually
an
issue
open
in
that
repo
to
make
sure
we
add
some
like
contribution
guidelines
and
a
license.
B
So
I'm
I'm
gonna
call
this
done,
and
really
the
the
like
next
step
for
that
project
is
to
make
sure
that
it
gets
some
maintenance
attention
and
that
we
build
it
up
to
be
the
thing
that
we
want
it
to
be,
and
as
we
do
that,
I
suspect
that
we'll
get
the
licensing
figured
out
and,
like
super
clear
point,
I
think
it's
right
that,
like
the
license
that
applies
to
the
project,
graphical
scalars
project
itself
may
or
may
not
apply
to
all
the
scalars
submitted
in
there.
B
People
are
just
saying
like
this
is
a
link
right
like.
If
we
want
to
treat
this
like
the
npm
of
graphql
scalars,
then
obviously
people
can
submit
their
scalar
specs
with
whatever
license
they
want.
So
I'm
going
to
close
this
issue
on
the
working
group,
and
this
is
now
officially
on
the
plate
of
whoever
picks
up
the
mantle
for
that
project.
B
G
B
G
G
So
I
think
it's
like
party
done.
It
was
back
in
the
time
we
discussed
the
rocky
jazz
working
group
because
we
had
like
bunch
of
grucky
js,
related
questions
on
main
working
group,
so
we
decided
to
spin
off
and
it
succeeds
it's
not
as
big
as
this
one.
Usually
we
have
like
two
three
four
people,
sometimes
five,
but
the
service
purpose
and
happening
every
month.
We
recreate
the
launcher
created
repo,
so
idea
was
to
hold
first
create
like
this
javascript
working
group,
but
an
approaches
make
it
easier
to
create
more
working
groups.
G
B
Okay,
I
think
we
can
close
it
like
it'd,
be
one
thing
if
we
were
opening
like
new
working
groups
every
month
or
two-
and
this
was
like
a
problem
for
us,
but
there
are
a
handful
but
they're.
The
creation
of
anyone
is
fairly
far
few
and
far
between.
My
thought
is
that
template
repo
might
be
a
little
bit
overkill
and
it's
probably
okay
for
us
to
manually
assemble
one
for
the
needs
of
each
of
our
sub
working
groups
as
necessary.
So
this
was
ready
for
review
almost
a
year
ago.
B
B
Okay,
once
I
finished
that
other
the
other
one
we
already
talked
about,
then
we
should
be
closing
out
last
september's
set
of
action
items
really.
Okay,
talk
about
that.
I
want
to
talk
about
that
one.
We
still
have
open
an
issue
for
alternative
meeting
times.
B
What
are
we
going
to
do
with
this?
The
last
time
we
talked
about
this
was
last
march.
I
feel
like
every
time
we
talk
about
this.
We
come
to
the
unsatisfactory
conclusion
that
there's
just
never
a
time
that
can
collect
everyone.
I
remember
last
time
we
talked
about
this.
We
talked
about
doing
a
time
that
would
basically
rule
out
u.s
attendees,
but
would
be
a
good
time
for
europe
and
asia.
B
G
Yeah,
I
think
it's
made
it
more
manageable
for
any
original
issue
like
to
our
broader
contribution,
but
factual
issue
was
it
was
too
early
for
for
india
and
remove
it.
It's
like,
I
think,
it's
lightest
for
me
at
the
moment,
so
changing
at
1pm,
usually
for
me,
but
it's
still
like
okay.
So
I'm
happy
with
that
time
and
it's
a
wall
and
to
join
under,
remember
like
6,
00
am
or
7
a.m,
which
is
order,
but
also
kind
of
manageable.
G
G
So
I
think
we
tried
and
we
made
some
adjustments
and
different
traced
and
future.
We
can
think
about
some
more
complicated
stuff
like
splitting
it
up,
but
I
think
for
now
with
this
is
especially
since,
like
we
have
on
this
school,
we
have
six
people,
so
we
split
it
up.
We
were
like
two
or
two
calls
with
three
people
or
something
yeah.
B
B
B
B
Next,
one
links
to
stories
blogs
relevant
to
spec
release.
I
am
going
to
cut
the
spec
release
this
month.
That's
coming!
B
This
didn't
get
a
ton
of
traction,
so
I
think
my
new
game
plan
for
this
is
we
will
fastball
so
the
original
intent
with
this,
and
we
assembled
it
up
in
march,
because
this
was
like
bef
right
before
we
started
the
process
did
the
spec
cut
was
if
we
had
blog
posts
that
we
wanted
to
kind
of
release
those
all
around
the
same
time.
That
way
those
people
are
going
like.
Oh
wow,
a
new
scarfield
spec
release
like
they
just
see
a
bunch
of
relative
blog
content.
B
My
thought
now
is
that
a
waterfall
model
is
more
likely
to
have
impact
where
what
I'll
do
is.
I
will
have
my
blog
post
that
goes
along
with
the
spec
cut
this
month,
and
then
anyone
that
wants
to
write
a
more
detailed
blog
post
is
absolutely
welcome
and
I'll
use.
The
the
graphical
twitter
account
to
signal
boost
anything
you
all
wanna
draw
attention
to,
but
I
think
I'll
just
close
this,
since
it
didn't
get
a
lot
of
traction.
So
that's
not.
Okay
with
everybody.
B
Cool
done:
where
does
that
land
us
there's
one
from
march?
There
are
a
handful
of
these
for
march.
That
says,
add
a
non-normative
note
that
a
graphical
request
is
not
the
same
as
an
http
request.
B
Yes,
indeed,
I
don't
recall
that's
doing
that.
Okay,
I'm
gonna,
leave
it
open.
I
suspect,
there's
like
a
swath
of
editorial
things
that
we
might
want
to
get
to
again
after
the
spec
cut,
so
get
that
one
open.
B
A
A
D
A
Issue
again,
I
didn't
catch
the
beginning,
so
basically
because
of
the
the
default,
the
change
to
the
default
value,
coercion
that
we
were
talking
about,
where
you
treat
a
value
not
as
if
it's
already
coerced,
because
there
are
kind
of
things
that
that
assumption
breaks
like,
for
example,
things
can
be
null
when
they
are
expected
to
not
be
null
because
they
have
defaults
or
something
like
that.
We
were
basically
proposing
changing
a
small
part
of
the
graphql
spec
text.
A
To
make
that
more
clear
lee
has
made
an
initial
pull
request
to
well,
I
say
pull
request.
It
was
a
series
of
pull
requests
if
I
recall
to
graphql
js
to
to
implement
that
which
ended
up
going
a
lot
deeper
than
I
was
expecting
it
to
go.
So
thank
you
lee
for
doing
that.
Work.
A
So
I'm
really
hoping
that
some
graphical
implementations
like
have
a
go
at
implementing
this
and
then
say
either.
Yes,
we
can
implement
it
or
no,
we
can't
implement
it,
and
here
is
a
compelling
reason.
Why?
Because
it,
I
think
this
is
the
right
direction
for
the
graphql
spec
itself
like.
I
think
it
is
a
a
weird
behavior
that
we
currently
have
that
eradicating
would
be
good
for
graphql
in
general.
A
B
For
what
it's
worth,
we
have
had
a
handful
of
folks
respond
to
that
ping
on
the
implementers
list
and
give
some
some
feedback.
B
Benedict
spania
is
this
user
name
who
helps
maintain
the
php
library
said
he
voiced
his
support
for
this,
so
that
it
was
going
to
be
challenging
to
implement
there,
but
it
was
the
right
thing
because
he's
seen
people
get
bit
by
this.
Also
in
that
thread
was
evan.
B
B
So
actually,
I'm
gonna
suggest
closing
this
particular
issue.
That
is
now
six
months
old,
because
I
think
we
actually
we
did
this.
We
pinged
the
implementers
and
I
will
do
one
last
ping
to
implementers.
B
Cool
saw
that
reference
from
you,
michael
okay.
B
Well
then,
I
am
going
to
close
this
one
all
right
if
we're
only
looking
at
stuff
as
far
back
as
march,
that
makes
me
feel
a
little
bit
better
now
than
the
action
items
I
think
there's
another
one
here,
that
is
a
spec
clarifying
editorial,
add
pros
to
explain
why
scalar
fields
must
have
the
same
type
when
composing
fragments
I'm
gonna
leave
this
one
open,
because
I
think
that
one's
gonna
require
a
little
bit
of
a
deep
dive
and
implement
one
of
input.
Objects
in
graphql,
js.
F
B
C
B
B
Then
we're
into
april
about
doing
a
deep
dive
in
the
google
summer
of
code
and
whether
or
not
we
should
be
implant
applying
for
google
summer
of
docs,
I'm
assuming
the
timeline
for
summer
of
docs
is
long
gone.
I
assume
brian
dug
into
this.
I
will
close
the
action
item,
but
I
do
I
have
a
bit
of
time
with
brian
later
today.
I'll
make
a
note
to
bring
this
up
with
him
just
to
dig
in
before
next
year.
B
G
Yeah,
I
think
I
brought
it
up.
I
don't
remember
why,
but
the
idea
was
that
yeah
situation
was
strange
and
just
to
know
what
to
do
so.
It
action
items
was
like
an
answer
for
me.
Should
I
apply
for
a
season
of
dogs
or
not
but
yeah
since
I'm
right
now
doing
you
know
starting
a
new
job,
I'm
like
overboarding,
this
bunch
of
stuff
in
a
pool
and
day-to-day
stuff
is
rough
here.
So
I
cannot
apply
anyway
yeah.
So
it's
answer.
G
B
Sounds
good
I'll
bring
that
up
with
brian,
and
I
I
think
in
general
it's
a
good
idea,
I
think
usually
we're
just
kind
of
late
to
it.
By
the
time
we
realize
that
that's
calming,
then
we
end
up
scrambling
and
then
not
writing
a
very
good
as
good
a
proposal
as
we
could
so
my
suspicion
is
that
that's
what's
happening
but
yeah
I'll,
ask
brian
about
it.
B
The
next
one
is
to
scan
our
repos
for
outdated
facebook,
copyright
notices
we
opened
this
in
april.
I
think
I
did
this.
G
One
issue
I
discussed
with
brian
branson,
like
ideally
as
a
person
who
wrote
license
why
we
will
change
it
or
represent
that
organization
will
change
it
to
to
have
like
a
legal
cleanroom.
On
that
I
don't
know
I
think
like.
If
what
makes
sense
they
use
the
bus
person
to
pick
somebody
from
facebook
to
change
license
or
maybe
just
change
it,
I'm
not
sure
what
to
do
with
like
licensing
things.
B
Okay,
hopefully
this
is
another
one
I
can
follow
up
on
after
meeting
at
the
minimum.
I
will
do
the
graphql.org
ones,
because
I'm
pretty
sure
I'm
the
one
who
wrote
that
code
so
that
fulfills
the
issue
you're
talking
about
are
we
up
to
june
whoa,
query
level
nullability.
B
This
is
assigned
to
alex
really.
So
I
think
I'm
going
to
leave
this.
K
Yeah
he's
working
on
the
the
js
implementation
and
that's
like
the
next.
The
next
thing.
B
Cool
and
then
this
last
one
is
on
you
benji
a
graphql.js,
pull
request,
preventing
skip
and
include
on
subscriptions,
which
was
related
to
a
proposal
rfc,
as
I
think
another
next
step
for
that
particular
rsc.
I
assume
that's
just
a
little
did.
G
G
A
Yeah
we've
got
an
rfc,
a
spec
pr
for
it.
I
put
it
in
the
chat.
B
G
Yeah,
so
it's
real
issue
from
apollo:
they
do.
G
If,
if
you
open,
I
can
send
the
link
or
if
somebody
have
it
open
right
now,
can
you
send
the
link
into
chat?
So
we
are
on
the
same
page,
because
I
actually
posted
a
real
life
and,
for
example,
in
in
issue.
G
So
if
you
open
it,
you
see
sdl
described
in
schema
and
basically
you
have
interface
with
a
noble
field
and
type
that
implemented
port.
It's
a
donald
on
string,
but
the
other
type
keypad
has
no
and
it's
allowed
by
a
type
system
because
we
use
covariance
yeah
covariance.
G
So
you
can,
you
can
add
no
no
to
when
you
implement
interfaces
field
on
interfaces
and
everything
works
good.
If
you
write
a
query-
and
there
is
example
of
query-
just
query
interface,
but
if
you
do
inside
the
square,
if
you
do
in
line
fragments
with
concrete
types,
you
break
you
break
validation
because
currently
validation
says
type
should
match.
If
you
use
non-module
like
entire
thing
with
overlapping
fields,
it's
it's
problematic,
as
we
discussed
and
like
math
agenda
items.
But
here
it's
like
it's
corner
case
of
current
supplementation.
G
I
think
it's
fixable
problem
is
that
it
doesn't
allow
you
to
do
covariance,
which
is
strange,
because
this
transformation
should
be
safe
and
it's
safe
in
like
99
percent
time
except
this
one.
So
it's
work
with
union
interfaces
like
it
work
with
interfaces
and
commanding
interfaces.
Everything
work
except
one
with
with
one
particular
case
when
you
add
no
no
somewhere,
and
can
it
can
bend
on
no
inside
like
this.
That
can
bend
no
no
way
on
top.
But
if
you
add
like
no,
no,
you
break
with
machine
rule
and
what's
more.
G
G
I
can
bring
with
question
issue
to
to
working
group
and
maybe-
and
we
can
fix
it,
because
I
think
it
should
be
possible,
like
this
transformation
would
be
possible,
and
it's
like
this
current
behavior
is
surprising
and
it's
easy
fixable,
I'm
on
vacation.
So
I
had
time
only
to
between
like
swimming
and
see
and
have
a
dinner
in
the
restaurant.
I
managed
to
put
pierce
back,
which
is
super
simple.
G
I
think
it's
changed
like
four
lines
of
text,
but
as
a
matching
pr
for
graphql
js
would
be
like,
like
actual
changes,
would
be
like
three
four
five
lines,
but
we
need
to
add
like
a
couple
of
tests,
so
change
itself
is
pretty
simple.
Yeah.
G
Was
like
surprised,
it's
not
fixed,
so
they
assume
it's
something
complicated,
something
like
beyond
the
understanding
white
glass
homework,
but
explain
them
with
just
like
the
most
complicated
piece
of
code
in
graphql
js
and
the
most
complicated,
probably
the
most
complicated
algorithm
respect.
So
nobody
wants
to
touch
it.
So
I
I
expect
people
having
this
issue,
but
just
trying
to
work
around
it
or
doing
something
else.
I
don't
think
the
power
is
the
only
company
doing
like
transformation
like
that.
D
Is
if
we
anyway
want
to
change
it
a
bit
I
mean
there
was
this
a
while
back
this
request
from
how
she
called
from
twitter.
I
forgot
her
name
salomon.
D
It
would
fix
this
problem,
but
it
would
also
implement
a
the
complexity
of
this
whole
algorithm
greatly.
I
mean
I
I
remember
lee
explained
why
they
made
it
so
strict,
but
nowadays
the
clients
kind
of
all.
Do
then
the
type
name
underneath
and
figure
out
that
this
actually
are
different
types
and
can
put
that
on
differently
generated
types.
I
think
that
was
with
the
result
format
you.
You
explained
that
you
used
in
the
java
clients
back
then
and
why
it's
so
strict.
B
There's
a
whole
class
of
of
languages,
including
java
and
objective-c,
which
happen
to
be
the
two
original
consumers
of
the
graphql
servers
at
facebook,
which
don't
have
the
capability
of
describing
union
types.
So
they
can
say
this
field
is
a
string.
They
can
say
this
field
is
an
int,
but
they
cannot
say
that
this
field
is
a
string
or
int.
B
It's
just
not
an
easy
thing
to
do
so
you
can
do
the
thing
where
you
have
like
a
really
complicated
set
of
nested
interfaces
where
you
try
to
split
them
apart
that
way,
but
you
end
up
with
extremely
complicated
client
code
to
just
to
try
to
model
this
idea
of
a
union.
Modern
languages.
Do
this,
but
older
languages,
don't.
D
The
question,
if
you
can
push
that
on
the
on
the
client
that
generates
a
code
I
mean
relay,
doesn't
allow
all
kinds
of
query
syntax
elements,
so
you
are
also
limited
to
the
stuff
that
relay
allows
you
and
so
could
other
clients.
So
with
that,
we
could
really
simplify
the
whole
algorithm
and
would
also
get
rid
of
this.
B
Just
I
definitely
think
that's
interesting
and
you're
right.
It
would
certainly
simplify
this.
There's
a
there's
another
argument
to
be
made
for
keeping
it
beyond
just
the
support
for
those
languages,
which
is
a
simplified
understanding
of
the
response
right.
You
write
something
that
you
at
first
read
think
is
straightforward,
but
then
you
get
payload
results
that
are
confusing.
B
So
the
there's,
like
this
other
scenario,
where
you're
providing
you're
consuming
the
results
in
a
untyped
language
and
therefore
relying
on
a
human
to
make
sane
judgments
about
what
what
field
types
can
be
reasonable.
So
a
good
example.
This
is
python
like
python
and
ruby.
Even
python
and
ruby
is
consumers
of
graphql.
B
They
don't
have
first
class
type
systems
at
all,
and
so
they
rely
on
a
human
to
say.
Given
this
graphql
query,
what's
the
shape
of
the
thing
that's
going
to
come
back
and
then
can
I
operate
on
it?
You
can
imagine
a
mode
where
someone
subtly
screws
that
up
and
they
end
up
with
overlapping
field
names
or
aliases,
that
return
string
or
number
and
then
try
to
do
some
like
number
math
and
end
up
doing
implicit
number
coercion
and,
like
introduce
scary
bugs
in
their
code
base.
B
This
particular
change
that
ivan
is
proposing,
I
think,
is
very
interesting
because
it's
limiting
the
the
it
makes
this
rule
less
strict,
but
only
limited
to
the
union
of
a
null
type
than
the
irregular
type.
So,
and
that's
like
a
special
class
of
unions,.
B
Ever
like
you
know,
java
doesn't
give
a
about
nullability
in
the
first
place,
nor
there's
objective
c
so
like
their
sol
anyway.
Languages
that
do
have
union
types
treat
null
ability
in
a
special
manner
so
like
that
and
like
even
humans.
Thinking
like
this
is
a
field
that
can
or
can't
be
null
like
that.
They
don't
think
about
that.
The
same
way
they
think
about
their
union.
D
B
D
D
D
Work
around
there
and
I
think
it
would
put
more
to
the
client
to
decide
if
the
client
can
consume
that,
and
then
I
mean
most
graphical
clients
that
I
know
I
could
be
wrong
are
generated.
So
it
would
put
the
power
into
the
generator
of
this
validation.
B
The
part
of
the
intent
and
this
for
the
human
legibility
is,
you
should
be
able
to
look
at
any
particular
field.
That'll
result
in
the
payload
figure
out
what
the
type
of
that
field
is
and
then
know
that
that's
the
type
that's
going
to
be
in
your
response
right
and
that's.
B
Algorithm
guarantees
and
this
this
would
loosen
it
right,
like
you
could
imagine
encountering
the
field
in
in
yvonne's
example
of
the
what's
in
the
example,
the
country
code
being
noble
in
one
case,
not
in
the
other,
so
you'll
look
and
be
like
a
port's
country
code
is
is
required.
So
I
know
that
country
code
is
definitely
going
to
come
back
and,
like
obviously
in
this
contrived
example,
they're
right
next
to
each
other.
B
But
you
can
imagine
one
where
one
is
a
named
fragment
and
therefore
it's
a
completely
different
file
and
you
look
at
it
in
that
file
and
you
see
it's
nullable
and
you
like
make
a
false
assumption.
So
I
can
definitely
see
how
it
could
create
confusion,
but
hey
steven,
your
hands.
K
Up
I'll,
let
you
talk
yeah
this,
so
this
is
similar
to
the
question
that
you
asked
lee
in
github
and
basically
is:
is
this
allowing
this
type
of
covariance
with
with
non-null?
Is
this
enough
on
its
own
to
to
like
unlock?
You
know
additional,
you
know
additional
use
cases
and,
and
if
not
then
is
just
the
bit
of
extra
complexity
and
kind
of
edge
caseiness
that
it
adds
you
know,
is
it
worth
it
to
add
it
so.
J
One
thing
to
note
is
how
fragments
work
today,
anytime,
you
have
a
fragment
spread
where
you
switch
up
the
type
you
already
have
this
potential
issue
like
any
time
you
have
a
fragment
spread
where
that
type
might
not
be
fulfilled
on
the
client.
You
need
to
treat
that
field
as
nullable
right,
so
is
that
that
that's
right,
yeah,
oh
yeah,
which
gets
back
to
if
you
want
to
be
able
to
access
the
field
in
a
non-nullable
way.
You
almost
need
something
like
fragment,
keyed,
fragments
or
some
way
of
saying,
yeah
yeah.
D
It's
the
where
you
essentially
can
state
that
you
want
this
feel
you
want
to
change
the
nullability
of
the
field,
and
this
would
essentially
make
this
explicit
that
you
want
to
see
the
country
code
as
nullable
in
that
case,
which
which
is
great
pr
I
can
post
later,
when
I
find
it
again,
that's
the
required
pr
right
yeah,
where
you
can
change
the
nullability
of
our
fields,
and
that
is
actually
very
good
for
things
like
schema
stitching
where
you
might
want
to
batch
things
and
then
mark
different
sections
and
as
nullable,
so
that
it
doesn't
erase
your
result
when
you
do
something
like
federation
or
stuff
which
would,
if
we
don't
want
to
change
that.
G
My
argument
to
it
is,
I
think,
is
different
type
of
house,
so
other
proposals,
like
named
ki
kit,
fragments
it's
more
like
feature
requests.
G
Relaxing
rules
at
all
is
also
kind
of
feature
request
and
mine
is
more
like
a
bug
fix.
So
a
question
here
is
not
like
it's
like.
If
we
decide
to
replace
this
mechanism
like
at
all,
there
is
not
a
problem
to
temporary
budget,
so
my
my
question
here
like
to
move
discussion
forward,
is
actual
items
actual
problem.
G
Find
my
complex
solution
so
can:
can
we
return
back
to
to
either
like
because,
like
time
frame
for
for
something
like
kid
fragments
or
relaxing
rules,
we
need
to
ask
like
implementers.
We
need
to
ask
like
people
who
generate
sdks
for
for
like
clients,
so
time
frame,
for
that
is
like
half
a
year.
Probably
how
thing
is
done
and
it's
unpredictable
if
we
have
champion
for
it
at
all.
G
On
other
hand,
this
is
pretty
simple.
We
sure
and
we
can
make
decision
in
like
move
it
to
stage
one
this
month
and
merge
something
into
graphql
js
next,
one
so
to
kind
of
yeah.
So
my
question:
if
he,
if
we
recognize
this
as
as
a
bug,
basically
because
for
me
this
transformation
should
work
and
also
it's
like
what
they
said
about
being
surprising
for
requirements.
G
D
Yeah
well
so
so
in
the
in
this
case
I
I
agree,
but
what
is
with
if
it's
too,
if
it's
a
union.
G
So
if
the
mean
like
covariance,
if
it's
a
union
and.
I
D
I
B
K
D
K
D
B
Because
the
pro,
like
the
actual
spec
change
proposal
here,
actually
has
nothing
to
do
with
interfaces
right.
It's
about
relaxing
the
same
response,
shape
algorithm
to
allow
for
nullable
and
non-nullable
fields
of
the
same
type
to
be
considered
the
same,
which
is
not
quite
the
same
as
saying
two
fields
which
implement
the
same
interface.
B
That
are,
you
know,
covariant
to
one
another,
can
be
merged.
Yeah.
D
G
So
if
I
change
it
to
to
this
address
with
specific
use
case,
one
thing
like
to
lisa
argument:
why
we
have
complex
rules
at
all
is
to
represented
cojon.
G
Codjan
can
figure
out
it's
like
combination
of
knowable,
non-noble
and
covariance
representable
in
any
like
type
system,
you
can
say
just
adjust
nullable
if
you
have
no,
no
no
go
common
version
is
knowable
so.
J
I
don't
I
personally
don't
think
it
makes
sense
to
just
limit
it
to
interfaces.
I
do
feel
like
any
client,
so
my
argument
about
any
client
kind
of
has
to
deal
with
this
already
is
an
argument
for
this
probably
does
no
harm
to
existing
clients
because,
like
if
you
have
multiple
fragment,
spreads
of
different
types
and
one
of
them
has
a
field
and
another
doesn't
well
in
your
code.
Gen,
the
field
access
has
to
be
knowable
in
some
way.
D
J
D
Yeah
but
anyway,
I
think
most
clients
really
rely
on
the
thunder
type
name
anyway,
because
like
when
we
generate
a
client
in
c-sharp.
We
also
generate
inheritance
and
stuff
like
that,
so
you
can
drill
in.
A
My
main
concern
with
the
actual
implementation
at
the
moment
seems
to
be
that
it
strips
the
nullability
from
the
entire
stack
of
a
type,
for
example.
If
it
was
a
list
of
something
else
like
a
list
of
strings,
then
the
inner
type
can
be
changed.
I
think
as
it
currently
stands,
if
I'm
reading
the
repeat
from
step
three
correctly,
is
that
something
that
we
actually
allow
with
interfaces?
I
thought
yeah,
we
didn't
yeah,
but
it
is.
G
A
G
Yeah,
I've
studied
it.
It's
I
actually
spent
like
hours
today
going
through
all
use
cases,
and
I
think
it's
the
only
thing
missing.
So
interfaces
have
like
bugs
to
list
early
questions
that
inside
there.
G
So
the
only
thing
that
missing
right
now
is
you
know
everything
else
is
working
just
by
coincidence,
like
I
think,
no
one
checked
like
what
thing
when
we
did
the
interface
into
imaging
interfaces
or
something
some
other
stuff,
but
it's
automatically
working
on
all
composite
types
just
by
the
way
how
we
through
written.
G
G
D
B
Going
back
to
your
question
before
yvonne:
is
this
a
bug?
I
don't
think
this
is
a
bug
I
think
it's
unintuitive,
but
I
don't
think
this
is
a
bug.
I
think
this
is
actually
our
the
constraints
that
we've
put
in
place
working
as
advertised.
B
It's
just
that
in
this
particular
example,
it's
maybe
a
surprising
constraint
to
find,
but
it
points
out
that
there
is
actually,
since
when
you
implement
an
interface,
you
can
implement
it.
Covariantly
such
that
you
can
supply
a
more
strict
version
of
the
type
of
a
field.
B
There's
a
difference
between
querying
a
field
on
an
interface
versus
querying
a
field
on
a
specific
implementation
of
that
interface.
They
don't
give
you
the
same
type.
They
give
you
a
potential
covariant
version
of
that
type.
So
I
I
don't
think
this
is
a
bug
that
we
need
to
think
about
how
to
go
fix
the
bug,
but
it
certainly
is
unintuitive
and
that
I
think,
should
help
guide
the
conversation
where
we're
not
patching
something
not
working
as
advertised.
It
is
working
as
advertised.
B
It's
just
not
not
in
this
particular
example,
not
very
clear,
which
then
I
think
circles
back
to
the
path,
four
that
we
were
talking
about,
and
I
think
there
are
two
three
paths
forward.
One
path
forward
is
the
null
case,
which
is
we
all
agree
that
this
is
unintuitive,
but
working
is
advertised
and
we
we
make
no
change.
B
The
second
path
is
we
make
some
decision
about
same
response,
shape
being
more
strict
than
we
would
like
and
decide
to
make
that
more
like
covariant
response
shape
or
make
nullability
not
part
of
the
the
definition
of
same
when
it
comes
to
same
response
shape
or
the
third
is
that
we
introduce
a
specific
carve
out
for
for
when
two
fields
implement
the
same
or
come
from
the
same
interface,
which
this
is
already
a
complicated
algorithm
that
might
make
it
a
little
bit
more
complicated.
G
G
Yeah,
I
I
I
agree.
It's
like
the
three
option.
I
personally
prefer
number
two.
I
don't
like
number
three,
but
I
can
live
with
it.
G
G
B
I
lightly
favor
the
first
option,
which
is
make
no
change
really
how
I'm
thinking
about
that
is
the
primary
impact
that
this
will
have
is
on
any
downstream
tool,
which
is
doing
type
generation.
This.
This
essentially
loosens
a
assumed
constraint
that
those
tools
will
have
and
can
generate
like
they
currently
could
be
generating
code.
That
assumes
a
field
is
not
null,
and
this
would
allow
a
null
through
there,
which
could
lead
to
null
pointer
exception
failures
for
that
existing
code,
which
is
what,
like,
I
don't.
G
B
That's
what
I'm
worried
about
yeah,
I'm
imagining
a
piece
of
code
generation,
client,
side,
code
generation
code
that
says:
okay
at
this
point,
I
assume
that
your
query
is
valid,
because
some
tool,
upstream
from
me,
would
have
rejected
it
now,
given
that
it's
valid,
I
will
do
type
generation
for
you,
which
my
understanding
is
how
most
of
the
most
of
the
code
that
I've
seen
before,
that
the
code
generation
works
and
so
it'll
look
at
that
and
say
like
yeah.
B
This
is
a
valid
query
and
now
I'm
going
to
go
generate
my
types
and
it
will
make
some
assumption
about
the
return
types
there
and
potentially
get
it
wrong,
not
to
say
that
those
aren't
bugs
that
could
be
fixed.
It's
just
it's
it's
a
it
does.
It
makes
it
like
not
a
a
cleanly
safe
change,
because
it
requires
fixing
assumptions
in
other
software.
B
Right,
that's
why
I
kind
of
loosely
favor
making
no
change,
but
I
think
what
would
be
compelling
is
how
how
frequently
does
this
kind
of
confusion
point
surface
and
how
complicated
is
it
to
resolve?
B
If
this
is
like
a
serious-
and
you
know
like
you
mentioned
sasha's
conversation
before
it's
not
the
first
time,
we've
talked
about
this,
restricting
being
a
limitation,
so
maybe
the
maybe
the
right
thing
to
do
is
sort
of
bring
it
back
to
that
discussion
and
say
how,
if
we
didn't
want
to
loosen
this,
how
how
loose
would
we
want
it
to
be?
B
D
But
I
would
also
like
to
go
in
that
direction
more
because
then
explore
instead
of
patching,
something
that
is
very
complicated
and
a
lot
of
things
to
rely
on
is
exploring
what
makes
sense
to
change
and
does
it
makes
change?
Does
it
make
sense
even
to
widen
it
further
and
then
come
to
a
decision,
but
not
in
a
rush.
G
When
I
was
presented
with
this
case,
I
thought
it's
like
hundred
percent
bug
or
something
and
then
so
I
just
assume
interface
implementation
rule
should
match
with
overlapping
fragment
because
they're
like
90,
something
percent
might
match
itself
so
without
context.
Knowing
how
how
spike
was
written.
That
time,
I
assumed
it
was
intentional
that
they
were
so
close
to
each
other.
G
So
I
assume
it
was
like
only
missing
think
it's
a
bug,
but
now
I
understand
it's
not
a
bug
which
make
stuff
harder
to
to
decide
and
reason
about.
G
B
What
it's
worth
of
on
when
you
dropped
your
message
to
say:
hey!
Please,
take
a
look
at
this
before
the
meeting
I
my
immediate
response
was
also
oh
wow.
This
looks
like
a
bug
that
we
should
fix
and
then
only
after,
like
really
thinking
about
a
hard
they
realize
like.
Oh,
no.
B
Actually,
this
is
one
of
our
constraints,
working
as
it's
designed
to,
but
this
is
a
very
confusing
edge
case,
which
is
why
I
say
I
only
I'm
loosely
favor
making
no
change,
but
if
we
were
to
loosen
up
our
constraint
on
response
shapes,
this
seems
this
seems
like
a
reasonable
place
to
loosen
it
such
that
it
actually
would
unlock
otherwise
confusing
behavior.
B
So
I'm
not
going
to
block
further
pursuing
the
path,
but
I
I
do
think
michael's
guidance
here
is
very
smart
to
instead
of
thinking
this
thinking
of
this
or
phrasing
it
as
there
is
a
bug
with
how
we
think
about
inline
fragments
for
for
implemented
interfaces,
but
instead
reframe
it
as
what,
if
we
generalized
the
constraint
that
we
have
on
same
shape
to
allow
variability
in
nullability,
because
that
is
then
the
superset
right
it.
B
I'm
personally,
okay,
relaxing
it
step
by
step,
or
rather
I
would
say
I
I'd
be
very
dubious-
of
the
idea
of
completely
removing
it.
Whereas
I
think
your
proposed
change
here
is
is
very
kind
of
sharp
and
smart
and
that
it
specifically
narrows
in
on
nullability
being
sort
of
a
different
class
of
response
shape
variation.
B
Then,
just
like
general
any
field
can
be
a
union
of
any
scalar
or
object
which
feels
much
more
dangerous
to
introduce,
and
it
might
make
sense
to
do
like
a
little
bit
of
analysis.
There,
like
what's
the
the
kind
of
the
range
of
of
removing
the
constraint
and
like
what
makes
sense
to
do
now
and
doing
one
doesn't
mean
that
we
could
never
do
the
other
ones
later,
but
it
makes
sense.
I
I
like
the
way
you
think
about
that
in
terms
of
structure.
G
G
Basically,
I
will
consult
with
the
team
and
see
how
to
approach
it
better
but
to
to
because
I
still
think,
even
if
we
decide
to
do
some
alternative
solution
for
the
meantime,
I
think
it's
valuable
so
for
next
time
I
will
try
to
prepare
graphql
js
pr
and
speak
with
people
working
on
coin.
G
B
All
right
that
wraps
us
up
almost
exactly
on
time.
I'm
gonna
drop
that
last
agenda
item
that
I
added
at
the
last
minute
anyway.
So
I'll
just
leave
you
all
with
a
note
to
go
check
out
the
discussion.
That's
happening
there
in
the
working
group
channel.
I
thought
it
was
pretty
interesting
and
otherwise
hope
everybody
has
a
good
rest
of
your
day.