►
From YouTube: GraphQL Working Group - April 1, 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).
A
B
B
D
E
We
have
a
very
small
agenda
today
surprising
compared
to
the
last
handful
we've
had,
so
we
might
we'll
let
this
one
be
a
little
bit
more
like.
Maybe
we
can
go
deep
into
action
items
today
or
have
a
little
bit
more
ad
hoc
discussion
or
just
have
a
short
meet.
That's
okay,
too,
but
we'll
wait.
A
couple
minutes
for
the
rest
of
folks
to
show.
E
F
B
Since
we're
just
waiting
for
people
to
show
up
before
the
meeting
starts,
can
we
just
have
an
unofficial
discussion
for
sure
I'm?
I
think
it
would
be
better
for
the
graphql
working
group.
If
we
put
like
a
deadline
on
adding
things
to
the
agenda,
we
tend
to
add
things
like
literally
in
the
hours
leading
up
to
the
meeting,
which
makes
it
very
hard
for
people
to
to
show
up
for
things
that
they're
interested
in.
B
So
I'm
wondering
whether
we
should
have
some
kind
of
cut
off
and
if
so,
what's
a
reasonable
period
of
time.
I
was
thinking
like
maybe
even
a
week.
E
B
D
B
D
I
could
propose
like
a
little
bit
middle
variant,
so
my
issue
with
adding
stuff
last
minute
is
that
I
need
to
think
about
it
if
I
agree
with
it
or
not
or
prepare
contra
proposal
so
like,
if
think,
I'm
against
is
like
to
start
discussion
of
something
and
frustrated
without
giving
enough
time
to
think
so,
I
would
like
say
we
should
not
move
or
give
like
people
ability
to
voice
alternative
opinion,
so
I
say
like
we
should
not
move
like
staff
pass
stage
two
if
they
that
last
minute,
like
moving
stuff
to
stage
one
is
like
have
small
consequences
even
like
stage
two,
it's
kind
of
bad
later
stage
like
imagine
something
into
spec
or
something
I
totally
agree.
E
B
Yeah,
I
totally
get
the
the
hesitation
I
have
heard
from,
for
example,
within
apollo
that
they
they
can't
justify
going
to
every
single
graphql
working
group
or
at
least
sending
the
relevant
engineers.
So
they'd,
rather
only
send
it
when
the
relevant
topics
are
there
and
they
don't
know
until
too
late
for
them
to
actually
sort
of
schedule.
G
We
we
could
reasonably
like
allow
people
to
put
stuff
on
the
agenda
and,
if
it
immediately
like
same
day,
even
and
then,
if,
like
stuff,
that's
put
on
same
day,
we'll
just
we'll
try
to
keep
very
short
and
like
tight
and
have
a
relatively
low
bar
for
like
telling
the
people
hey.
This
was
added
late.
People
didn't
have
a
chance
to
respond.
Let's
table
this,
for
the
next
meeting,
put
it
on
next
meetings
agenda
tonight
and
just
like:
let's
flush
this
out
more,
if
it
ends
up
being
anything
like
significant.
A
Yeah,
I
think,
what's
up
because
because
forbidding
to
put
something
in
late,
I
don't
know
spitacious,
because
it
could
still
be
yield
a
good
discussion,
and
I
mean
we-
we
don't
tend
to
make
decisions
just
after
one
time
talking
about
something
so.
E
B
Sounds
good
anyway,
I
distracted
from
starting
the
meeting.
So
no.
E
Worries
a
worthwhile
thing
to
discuss
and
participant,
let's
grow
in
the
meantime,
so
well
and
done.
Okay,
we
have
a
very
tight
agenda
today,
so
I'm
totally
happy
for
the
majority
of
the
agenda
to
be
these
a
little
bit
more
ad
hoc
conversations
and
today's
meeting
will
probably
be
relatively
short
yeah
there.
A
Was
also
a
lot
of
discussion
around
directive,
introspection
or
introspection
that
has
more
information
like
extensions
and
stuff.
Maybe
if
enough
people
interested
in
the
top
pick
are
here,
we
can
do
it
yeah.
I
don't
know.
If
there
is
enough
people.
E
Okay,
so
we're
all
here.
We
agree
to
the
membership
agreement,
participation,
guidelines
and
code
of
conduct
they're
all
linked
in
the
agenda
for
those
of
you
who
have
been
around
for
a
long
time.
None
of
that
will
look
familiar
or
all
that
should
look
familiar,
but
if
any
of
that
looks
new
to
you,
click
the
links
and
with
that,
let's
just
do
a
quick
round
of
intros,
so
we
can
put
names
to
faces.
E
H
C
F
A
C
Hi
andrew
here
also
from
take
shape.
I
Hey
I'm
sasha.
I
work
at
twitter
on
the
graphql
team.
E
Awesome,
I
think
that
was
a
perfect
match.
Didn't
miss
anybody,
amazing
all
right.
So
now
we
get
to
review
the
agenda
which,
as
you
all
can
see,
is
exceptionally
tiny.
So
I'm
happy
to
dive
into
our
action
items
and
spend
a
bunch
of
time
on
that
and
have
ad
hoc
discussion
there's
also
probably
a
handful
of
things
that
would
be
interesting
to
discuss.
E
So
maybe
we
can
just
take
a
minute
and
I'll
drop,
some
notes
directly
into
the
agenda
file.
Anything
you'll
want
to
discuss
today.
C
D
I
have
like
a
small
proposal.
I
didn't
had
time
to
prepare
pr
for
spark,
but
it's
for
adding
a
description
to
acquiring
some
fragments
like
right.
Now
only
types
have
description
and
we
have
some
some
need
for
description
on
queries
and
fragments.
B
There's
there's
a
few
quite
small,
open
pull
requests
against
the
graphql
spec
that
I've
got
some
of
them
like
only
words
or
sentences,
that
I'd
be
interested
in
getting.
E
I'm
ready
for
review.
Okay
I'll
share
this
link
here,
we're
not
expecting
andy
today,
or
at
least
he
didn't
put
his
name
on
the
agenda,
which
is
a
little
interesting
because
part
of
the
rationale
for
changing
our
meeting
time
was
to
make
it
easier
for
folks
in
the
asia
and
australia
time
zones
to
join,
but
that's
okay,
maybe
next
time.
E
Maybe
that's
also
another
thing
we
can
discuss
briefly.
I
know
in
the
past
meeting
we
talked
about
adding
in
back
and
forth,
shifted
time
slots
where
we
had
one
that
was
bad
for
the
us,
but
good
for
asia,
australia,.
E
And
maybe
we
can
put
one
of
those
on
the
books.
Okay,
we
have
four
action
items,
two
from
the
previous
meeting,
two
from
the
one
before
that
that
are
up
for
review.
I'm
gonna
look
at
these
in
upside
down
order,
so
636.
E
E
Brian
resolved
this
one,
google
summer
of
clothes,
this
google
summer
of
code
applications
are
closed.
I
actually
don't
know
what
projects
we
applied
for.
Yes,
brian,
for
an
update.
Do
you
know
evan.
D
E
Okay,
I
know
there's
plenty
of
work
to
be
done,
so
that
would
be
great
if
we
got
somebody
there
season
of
docs
is
open
too.
I
know
that
that
was
pretty
successful
last
time
and
there's
quite
a
lot
of
work
that
we
can
do
there.
So
if
anybody
has
documentation
projects,
so
they
want
to
submit
consider
this
a
call
for
those,
and
if
you
need
help
figuring
out
how
to
do
that,
just
drop
a
note
to
brian.
He
can
help
connect
the
dots.
D
I
think
we
have
like
in
foundation
repo.
There
is
like
undergraduate
organization,
there
is
foundation
repo
and
also
there
is
a
mentorship
folder
and
you
can
see
application
for
last
year
for
google
seasonal
docs.
One
thing
I
think,
maybe
action
items
for
brian
if
we
can
make
it
to
figure
to
find
out.
Why
why
we
got
rejected
for
summer
of
code
and
if
it's
worth
chop,
why?
E
E
D
Some
I
can
do
like
a
quick
check.
I
don't
think
we
need
to
change
something
in
archive
repositories
and
in
non-archive
repositories.
I
will
do
checks
for
facebook
just
like
search
for
facebook
on
the
graphql
organization.
This
should
mean
too
much,
so
I
can
take
it
on
myself
to
verify
it
completely
great.
E
Thank
you
I'll
preemptively
close
this,
since
the
main
thing
this
was
about
was
the
clas.
Copyright
notices
are
actually
like.
Don't
have
a
ton
of
impact,
but
class
were
something
that
we're
concerning.
So
I
think
that
one's
resolved
thanks
to
brian
that
one
is
closed
too.
E
E
One,
that's
still
open
is
continuing
to
collect
links
around
work,
that's
gone
into
the
spec
over
the
last
year
and
a
half
or
anything
that
any
ideas
that
you'll
want
to
write
about.
E
So
we
can
talk
a
little
bit
more
about
this
when
we
talk
about
updates
around
the
spec
cut,
but
this
one
is
still
open.
So
I
just
want
to
remind
folks
if
you
want
to
write
a
blog
about
anything
related
to
graphql
in
the
next
couple
of
months,
we'll
be
putting
a
lot
of
visibility
towards
it.
So
good
opportunity.
E
E
At
least
I
think
I
have
the
old
one,
there
was
one
that
came
out
of.
It
was
like
right
around
the
time
when
we
were
forming
the
foundation,
and
so
I
had
the
old
calendar.
Invite
and
brian
set
up
one
on
the
foundations
calendar
so
probably
subscribed
to
that
old
one
that
I
had.
So
that's
a
good
call
I'll
just
delete
it.
E
And
this
last
one
yep,
this
one's
good.
We
moved
this
default
value,
corrosion
rule
stuff
forward,
so
this
one
is
also
closed
and
looking
at
other
open
actions
from
last,
there
are
a
handful,
I
think,
they're
all
on
a
combination
of
benji
and
me,
although
two
of
them
are
marked
as
everyone
that
are
still
open
and
those
two
are
making
sure.
So
this
was
a
call
for
implementers
making
sure
that
the
changes
to
the
default
value,
coercion,
rules
weren't,
going
to
break
something
I'll
drop,
a
link
in
the
chat
to
that
one.
E
So
I
know
benji
especially
will
appreciate
some
following
on
this.
This
is
one
that
definitely
we
want
to
see
be
resolved,
but
we
want
to
make
sure
we're
not
breaking
anything
for
anyone,
so
dot
net
js.
Some
of
these
core
implementations.
We
should
make
sure
that
we're
not
breaking
anything
with
this
proposal.
E
E
E
Yeah,
I
don't
see
any
here-
that's
necessarily
relevant
for
lifting
up,
but
if
you
would
like
to
help
move
any
of
those
action
items
forward,
take
a
look
at
the
link.
That's
in
that
spec
agenda.
I'll
share
it
here
again.
This
is
all
the
open,
app
action
items
right
now
so
feel
free
to
scan
through
those,
and
you
see
any
ones
that
are
relevant
to
you.
E
Some
of
them
are
marked
to
everyone
so
worthwhile
to
look
at
those
first,
but
also
if
you
have
a
an
ability
to
move
any
of
these
forward,
a
lot
of
them
are
on
me,
brian
or
benji.
So
I
know
we're
we're
taking
a
lot
of
lift
here.
So
I'm
sure
we
could
all
appreciate
a
little
bit
of
help.
C
E
I
might
take
a
spool
through
them
tomorrow
and
and
flags
for
some
folks,
if
there's
some
room
to
delegate
some
of
those
at
but
yeah
the
administrative
ones,
I'll
make
sure
brian
and
I
get
on
top
of
quickly.
E
Alright,
so
spec
cut
update
great
question
this
one's
on
me,
so
we
are
almost
there.
There
is,
I
think,
one
or
two
more
final
phase
proposals
that
were
accepted
and
still
need
a
review
for
me
to
be
merged
in
there's
also
some
administrative
stuff.
I
need
to
do
on
top
of
that.
I'm
gonna
do
some
changes
to
the
top
there's
a
some
section
at
the
top.
That
has
some
legal
text
that
I
need
to
update
that
I
was
waiting
on
brian
and
one
other
person
from
the
gdf
to
get
me.
E
E
At
which
point
we
will
have
a
draft
that
is
a
candidate
for
a
cut,
and
so
the
like
formal
step
there
is
to
have
the
technical
steering
committee
take
a
formal
vote
on
making
a
cut
from
that
draft,
and
I
want
to
make
sure
that
everyone
has
ample
time
to
to
read
that
and
make
sure
that
that's
the
case.
E
If
we
haven't
gotten
everybody's
informal
vote
ahead
of
that
and
that'll,
be
it
we'll
do
a
cut
and
then
we'll
make
some
noise
go.
Do
some
tweets
and
write
a
bunch
of
blog
posts
or
put
a
bunch
of
traffic
towards
ones
that
are
already
up
and
yeah
if
you
want
to,
if
you
want
to
write
a
blog
post
about
something
that
has
been
added
over
the
last
couple
of
months,
my
plan
for
marketing
around
this
is
basically
going
to
be
over
the
like
month
or
so.
E
After
doing,
the
cut
is
to
just
like
routinely
drop
links
in
on
twitter,
from
both
my
account
and
the
graphql
account
towards
various
blogs.
That's
like
yeah.
We
did
this
cut
a
couple
weeks
ago,
like
check
out
this
great
blog
post,
talking
about
one
of
the
things
that
we
did
and
we'll
just
click
keep
doing
that
so
drawing
a
bunch
of
attention
to
more
towards
like
the
work
that
went
on
rather
than
to
the
fact
that
there
was
a
cut,
because
you
know
we
are
always
following
the
draft.
So
the
cut
is
really
just
there.
E
B
Hey
yeah,
no,
no
update,
yeah
I've
not
had
a
chance
to
work
on
it
in
the
last
month.
I
do
plan
to
this
month.
Hopefully,
though,
I
may
need
to
dedicate
some
time
to
obviously
having
a
look
at
the
spec
cup.
B
I
would
still
appreciate
any
more
feedback
if
there
is
any
that
wants
to
be
coming,
but
otherwise
I
think
it's
just
waiting
on
me
to
start
doing
some
changes
to
graphql.js
to
start
implementing
a
version,
and
I
need
to
talk
with
the
people
that
working
on
graphql
js
to
see
how
that
fits
in
with
the
the
rewrite
at
the
moment
for
typescript.
C
Yeah
I
did
want
to
call
out
so
I'm
shopify
is,
is
becoming
increasingly
interested
in
this
one
to
the
point
that
we're
thinking
about
adapting
adopting
the
current
kind
of
draft
pro
version
of
this
in
production,
just
because
we
need
something
to
do
to
accomplish
this,
and
this
seems
like
the
most
promising
candidate
so
far,
so
I
unfortunately
am
not
super
hip
with
a
js,
but
if
you
need
any
assistance
benji
like
please
tell
me
for
this
thanks.
I.
E
It
was
great
to
hear
excited
to
see.
I
mean
that's
also
good,
since
you
guys
have
a
lot
of
room
to
sort
of
figure
things
out
on
the
fly.
So
if
you
spot
like
real
issues
in
a
real
large
schema,
I'm
super
curious
to
hear
those.
I
think
that's
going
to
be
like
very,
very
useful
to
build
confidence
in
this
direction.
E
E
I
see
a
question
in
the
chat
around
names
for
spec
versions
in
the
past,
we've
named
them
for
the
year
in
which
they
were
released,
so
I'm
not
opposed
to
doing
something
more
cute.
I
don't
know
anyone
have
ideas.
E
Plants
interesting
interesting,
yeah
ubuntu's
was:
was
animals
I'd
like
to
say
that
they
started
that
trend,
although
maybe
there's
precedent
before
ubuntu
androids
are
desserts,
which
I
also
really
like.
Plants
is
interesting,
yeah
happy
to
to
take
more
ideas
on
this
one.
It's
pretty
funny.
E
All
right,
actually,
oh,
this
is
a
little
bit
in
the
middle
of
the
agenda.
So
sorry
for
this,
but
ivan
I
was
gonna
hand
it
to
you
next
anyway.
I'd
love
an
update
on
the
the
typescript
migration
for
graphql
js.
Can
you
tell
us
a
little
bit
about
how
that's
been
going
and
like
what
the
trajectory
of
that's
like.
D
Yeah,
so
we
have
like
almost,
I
think,
like
six
six
million
downloads
per
week
for
graphql
js
package,
so
we
try
not
not
to
break
unnecessary
break
stuff,
so
strategy
was
initially
we
tried
to
do
it
as
non-breaking
release
and
quickly
discover
it's
not
possible,
even
though
typescript
to
make
it
just
type
annotation
but
see
like
to
properly
type
things
in
typescript.
We
need
to
change
some
stuff,
but
most
of
them
show
ideas
not
to
do
like
script,
specific
stuff
ideas
to
clean
up
like
four
hacks
and
stuff.
D
D
Differently
so
yeah,
so
one
is
we
start
at
six
zero,
zero,
a
line
so
switch
like
main
to
it,
and
we
have
like
one
of
the
thing
we
kind
of
need
to
drop
flow
typings,
which
is
maintained
four
and
typescript,
and
parallel
doesn't
solve
our
main
issue,
encouraging
people
to
contribute.
If,
like
for
merchant
pr,
you
are
required
to
update
four
type.
Four
types
will
not
achieve
like
our
biggest
goal,
so
we
need
to
drop
four
types.
D
D
It's
a
hit
like
advanced
spr
and
right
now
we
fix
all
typescript
issues,
but
some
of
the
fixes
required
to
work
around,
which
is
not
really
stuff
that
we
want
to
to
merge
so
idea
that
we
incorporate
all
the
fixes
into
main
and
some
of
them
I
like
breaking,
but
at
the
same
time
we
have
like
95,
I
would
say,
percent
finished
pr.
D
I
expected
why,
like
one
or
two
weeks
for
us
to,
I
can
incorporate
all
the
fixes
at
least
try
to
solve
it
properly.
If
something
is
like
really
hard,
we
just
like
disable
typescript
checking
on
that
and
will
release
alpha
1
for.
D
16.000
with
4
typing
still
with
4,
typings
and
still
unfold,
and
immediately
after,
like
we
give
one
week
for
people
to
test
and
after
that
we
match
with
pair.
So
what
way
we
put
all
the
braking
changes
for
typings.
We
can
extract
them
the
net
to
fall
typed
and
allow
them
to
gradually
degrade,
so
they
will
be
usable
for
for
like
next
year
until
next
break
and
release
so
yeah,
it's
kind
of
like
a
little
bit
of
dancing
a
little
back
and
forth,
but
we
we're
going
there.
D
E
D
Him
on
gaspia,
but
it's
reviewable
and
it's
reversible
every
time
he
replaces
it.
It's
like
it's
took
us.
We
usually
do
like
zoomco
and
replace
it
together.
It's
usually
take
us
like
half
an
hour
to
a
base.
He
whiskey
mojosphere
because
he
did
like
one
specific
change
in
one
commit
over
the
whole
code
base.
So,
for
example,
in
for
it's,
like
plus
sign
means
read
only
in
typescript,
but
it
only
is
read-only.
D
It's
actually
like
written
really,
so
he
created
a
separate
commit
to
convert
all
plus
signs
to
read
only
through
the
whole
code
base.
So
it's
meant
mean
it's
like
reviewable,
even
though
it's
like
4000
line,
you
can
review
every
commit
and
say
yeah
this
committee
just
for
exchange
passed
already
only
so
it's
nothing
else
to
review
here,
but
with
commit
change
like
some
utility
types
exist
on
len,
4
and
typescript
is
done
differently,
so
I
need
to
spend
time
reviewing
this
one.
D
So
I
want
to
give
a
shout
out
to
him
about
this
and
for
everybody
else,
including
benji.
It's
not
idea
that
pr
stage
two
proposals:
it's
like
open
too
much
and
like,
except
like
big
stuff,
different
stream
and
other
things
they
like
huge
changes,
but
everything
is
open
and
even
we
don't
plan
to
change
ipi
major
change
to
ipi,
just
like
typings.
So
if
you
start
working
on
pr
on
the
current
code
base,
it
will
be
just
like
small
changes
and
typings
and
I
can
assist
with
rebase.
E
And
that
this
is
coming
close
to
a
close,
I
know
you've
been
working
on
this
for
a
long
time,
so
I
think
it
would
be
amazing
if
we
do
a
spec
cut
and
a
16-0
release
of
that
around
the
same
time
and
get
them
both
out
at
the
same
time.
That'd
be
just
great.
You
know
more
momentum
to
the
same
story.
E
Sometimes
I
worry
if
it's
time
to
just
rip
the
full
band-aid
off
on
flow
matt.
I
don't
know
if
you
have
any
sort
of
inside
knowledge
on
how
facebook
is
thinking
about
using
flow
versus
typescript.
These
days.
G
So
the
facebook,
in
terms
of
we
kind
of
mostly
use
graphql
js
for
tooling,
which
is
a
weird
usage
of
it
and
we've
in
fact,
totally
revamped.
The
like
relay
compiler,
which
I
believe
is
now
in
like
in
open
source.
It's
known,
rust
and
we've
been
pushing
most
of
our
build
tooling
there,
which
allows
us
to
do
like
weird
custom
things
necessary
to
support
legacy
stuff
without
polluting
graphql
js,
which
so
basically,
the
like.
Facebook
doesn't
really
need
long-term
graphqljs
to
like
be
flow
compatible
with
the
rest
of
facebook.
E
D
Approach
is
to
if,
if
somebody
needs
photo
typing,
they
can
volunteer
and
do
this
work
so
and
make
it
easier
for
them.
So
like
push
all
the
braking
changes
before
we
switch
to
typescript
plus,
like
we
have
like
interesting
idea
for
testing.
D
If
we
break
something
or
not
so
sahih
generated
packages
before
and
after
typescript
migration
and
here
running
div,
and
see
that
we
don't
change
code,
we
just
change
typings
and
so
far
we
managed
to
make
it
without
like
code
changes,
and
we
try
to
do
the
same
for
generated
dts
files.
So
even
dts
files
will
stay
mostly
the
same.
I
Just
curious
if
you've
tried
any
of
those
like
automatic
typescript
to
flow
converters,
because
we
have
like
a
couple
usages
of
importing
like
flow
types
from
graphql
js.
D
I
Too
huge
but
yeah
just
I
mean
even
even
something
done
like
that
would
be
like
vaguely
helpful,
but
also
not
a
big
deal
by
the
way,
but
just
curious
if
you've
investigated
that.
D
Yeah
when
investigated-
and
there
is
dotan
from
execute-
he
also
investigated
it,
so
my
personal
opinion
that
it
would
be
bad
to
release
something
that
we
cannot
test.
D
So
since
we
we
switch
our
tests.
Previously,
we
had
our
main
code
and,
like
we
choose
different
function,
and
we
have
like
test
suit,
also
in
full,
with
full
type
check.
D
But
since
we're
switching
fully
to
typescript
is
basically
mean
we,
we
can
run
with
two
and
we
can
produce
a
result,
but
we
don't
have
any
way
to
know
if
it's
like
make
any
sense
or
not
and
how
to
patch.
More
importantly,
even
if
somebody
discover
issue,
we
don't
know
how
to
apply
this
patch,
we
can
so
it's
required
some
investment.
First,
we
want
to
see
if
somebody
want-
and
I
don't
want
to
put
like
if
somebody
prepared
they
are
against
against
graphql
js.
D
I
don't
want
to
require
them
to
test
test
for
or
to
change
for
or
apply
some
patches
or
the
base
patches.
So
this
two
sounds
good,
but
we
have
like
300
x.
300
functions
like
ips
surface
is
huge
and
typings
are
huge,
so
I
would
expect
something
not
working
right.
So
only
if
somebody
volunteered
to
do
it
was
there
is
like
fall
type
tripod.
Nothing
prevents
people
from
collaborating
them
there
and
we
can.
D
G
So
we're
just
going
to
we'll
probably
cut
like
take
the
next
graphql
js
cut,
apply
that
and
then
just
freeze
like
we
will
not
upgrade
graphql
js
for
anything
that
depends
on
these
flow
types,
because
all
the
things
that
would
use
any
of
the
newest
graphql
features
won't
be
written
in
js.
I
Makes
sense
there
is
the
community
like
flow
types
project?
I
guess
so.
I'm
I'm
wondering
if
someone's
just
going
to
commit
that
and
some
some
you
know,
hero
is
going
to
maintain
the
flow
typed
version
of
graphql
js,
even
after
it's
been
converted
to
typescript.
I
E
I
E
Follow-On
of
the
type
scripts
like
typed
npm
space-
so
that's
probably
the
right
way
for
that
to
maintain
itself
over
the
long
run,
reduce
the
the
burden
on
the
project
maintainers
for
driftwood
js.
E
Sticking
with
you
yvonne,
you
wanted
to
to
talk
a
little
bit
about
adding
descriptions
to
queries
and
fragments.
Do
you
want
to
give
us
a
preview
of
that?
I'm
sure
you'll
have
more
to
share
in
the
next
meeting.
D
D
First
is
use
case,
and
second
is
why
I
think
it's
useful
in
general.
We
wanted
to
create
for
our
startup.
We
have
some
business
people
when
we
wanted
to
create
and
we
have
like
graphql
api
friends
to
postgraph
file
and
we
want
and
like
everybody
use,
graphql
scale.
But
business
people
need
the
comments,
so
we
wanted
to
generate
swag
commands
from
graphql
iris,
since
it's
like
co,
queries
can
have
a
name.
Arguments
can
have
a
name.
D
D
D
Nice
syntax
without
wait,
repeating
it
a
lot
and
you
can
put
mark
down
there
so
way
and
I
review
parser
and
it
will
actually
simplify
parser.
If
you
will,
we
already
have
all
the
necessary
code
and
semantics
and
everything
so
right
now
only
type
definitions:
how
to
have
descriptions.
D
D
So
I
think
it's
used
for
documentation,
purpose
and
even
for
code
generation.
So
if
you're
generating
some
function
or
types
from
from
queries
or
from
fragments,
it
would
be
nice
if
you
know
that
this
particular
thing
is
not
like
random
comment,
but
description
and
you
can
reuse
it
and
generate
stuff.
G
Yes,
this
sounds
like
something
that
lots
of
tooling
and
whatnot
could
use.
I
I
propose
we
put
it
on
the
agenda
for
next
meeting
table
it
for
this
one,
and
but
yes,
this,
like
I
like
off
the
top
of
my
head,
I
see
no
reason.
This
isn't
a
good
step.
E
Forward
this
is
kind
of
interesting
that
you
know.
Graphql
started
its
life
with
the
the
only
there's
like
two
very
different
worlds:
there's
the
schema
world
which
had
no
textual
representation.
It
was
purely
a
data
structure
that
came
out
of
code
and
then
queries,
which
was
a
textual
representation
and
the
two
had
like
very
different
properties
and,
like
over
time,
they're
getting
closer
and
closer
together,
such
that
at
some
point
in
the
future.
All
properties
of
one
will
apply
to
the
other.
E
So
interesting
like
until
you
brought
this
up,
I
hadn't
even
considered
the
the
thought
that
queries
and
fragments
might
need
descriptions
because
they're
not
part
of
your
schema
and
therefore,
where
would
they
show
up
and
have
those
descriptions
but
yeah?
I
see
the
value
so
looking
forward
to
seeing
a
proposal
and
some
work
put
into
like
exactly
what
the
details
of
this
would
look
like,
but
sounds
like
it's
going
to
be
straightforward
enough
that
it
might
be
fairly
easy
to
make
this
one
through
the
gauntlet.
E
B
This
there's
one
potential
thing
that
I
can
think
of,
but
I'm
not
sure
how
this
actually
works
anyway.
How
do
how
do
multi-line
strings
work
in
graphql
queries
like
as
as
arguments
to
say,
a
field
the
same
as
any
other
string,
so
it's
just
double
quotes
and
then
you
can
put
new
lines
and
stuff
inside
of
it
inside
triple
quotes,
but
yeah.
So
the
the
difference
would
be
where
the
location
of
the
triple
quotes
is
and
that's
it
I'm
a
little
concerned
that
that
may
cause
potentially
visual
confusion.
B
B
E
That's
interesting
yeah
if
we
followed
the
same
syntax
rules
which
seems
like
would
be
the
reasonable
path
to
pursue.
First,
then,
that's
not
a
pattern
that
is
currently
allowed
today
to
have
a
floating
quote
body
outside
of
the
context
of
a
place
where
you
could
put
one
today.
So
it
is
just
it's
purely
new
syntax,
no
conflict
and
but
yeah
that's
a
good
point,
and
maybe
an
idea
around,
like
syntax,
highlighters
and
sort
of
like
a
recognition
that
that
position
is
different
than
an
inline
quote.
I
think
python.
E
A
lot
of
python
syntax
highlighters
have
the
same
property
where
they.
This
is
like
the
documentation,
style
and
graphql
is
basically
directly
inspired
by
how
python
does
their
documentation
with
quote
bodies,
and
I
know
a
lot
of
their
syntax.
Highlighters
will
quote
or
will
color
descriptions
differently
than
they'll
color
quotes
that
appear
in
a
quote:
location
or
value
location,
but
yeah
great
thing.
D
To
think
about
qualify
with
point
quickly
like
there
is
two
forms
shorthand
form
with
just
like
curly
braces
and
for
curly
braces.
Adding
description.
Don't
make
sense
if
you
don't
bother
to
add,
like
a
name
to
your
query
like
why
do
you
want
a
description?
D
So
I
point
to
a
low
description
only
for
like
four
inquiries,
and
it's
mean,
like
word,
query
and
curly.
Braces
mutation,
curly,
braces
subscription,
curly
braces.
So
in
white
cases
it
was
confusing
because
it's
like
you
can
you
see
like
something
defined
and
before
that
description.
Another
point
is
like.
D
E
E
But
that's
a
good
point.
Actually,
maybe
now
I'm
interested
to
see
exactly
what
the
the
detail
of
how
your
how
your
syntax
proposal
is
gonna
work,
because
right
now
I
think
it's
written
where
there's
actually
a
there's,
so
there's
the
simplified
form
where
it's
just
purely
the
selection
set,
but
then
there's
also
a
form
where
you
say
you
know
query
whatever
and
the
name
there
is
optional.
So
you
can
just
have
like
an
unnamed
query,
but
it's
still
explicitly
described
as
a
query.
E
So
you've
got
some
some
room
just
to
figure
out
exactly
where
that
lives
would
be
interesting
to
see.
Okay,
I'm
excited
looking
forward
to
seeing
that.
E
I
think
the
last
thing
on
the
list
here
is
benji.
You
wanted
to
take
a
look
at
a
couple
specific
pr
reviews.
B
Yes,
that
is
correct,
let's,
let's
just
dive
straight
in
so
the
first
one
is
spec
pull
request.
Eight
two
eight,
where
there
just
seems
to
be
a
missing
definition
of
what
the
selection
set
is
in
this
particular
piece
of
text
I
noticed,
was
comparing
you
know,
create
source
event
stream
to
one
of
the
other
places.
That's
quite
similar,
and
this
one
just
sort
of
pulled
selection
set
out
of
the
air.
So
I
believe
that
what
I've
written
is
the
it's.
The
correct
text.
E
Yeah
well,
I'm
given
how
much
energy
went
into
review
for
streaming
or
for
streams
as
part
of
subscriptions.
I'm
surprised
that
this
one
slipped
through
nice
catch.
B
Cool
the
next
one
is.
B
I
can't
find
it
oh
yeah,
using
the
markdown
lists
in
the
one-offs.
B
You've
added
to
spec
md,
I
know
I
know
we
did
some
work
sort
of
together-ish
on
adding
better
support
for
potentially
doing
prettier
on
the
graphql
spec,
so
I'm
still
trying
to
push
that
forward.
So
what
I'm
trying
to
do
is
pull
pull
any
changes
to
the
markdown
that
aren't
purely
formatting
out
into
separate
pull
requests
so
that
the
final
prettification
of
it
will
basically
just
be
white
space.
That's
the
plan,
so
this
is
one
of
them
and
basically
it's
so
this
is
pull
request.
B
726..
We
can
ignore
some
of
the
discussion
in
there,
which
was
to
do
with
using
the
markdown
native
line
breaks.
So
instead
we
can
use
bulleted
lists,
so
I'm
just
suggesting
that
since
spec
md
already
supports
this,
can
we
just
merge
these
changes
now.
E
I,
like
your
amusing
here,
and
I
think,
you're
probably
right.
The
whoever
decided
to
allow
trailing
space
is
like
a
meaningful
thing.
In
markdown
it
makes
my
heart
hurt.
B
Cool
there's
also
another
one
that
is
relatively
minor.
It
came
out
of
the
work
on
the
tagged
type,
which
is
technically
no
longer
relevant,
but
I
figured
that
it
would
still
be
beneficial
because
it
will
make
it
easier
to
do
further
pull
requests
in
future,
and
it
is
basically
just
changing
a
small
piece
of
text
that
lists
all
of
the
type
system
types.
Sorry
all
of
the
different
types
in
the
introspection
system
and
just
says
the
double
underscore
type
represents
all.
D
B
In
the
type
system,
so
it's
quite
a
small
like
again
sonya
two
sentences.
B
B
Yeah,
it
also
represents
the
type
modifiers
you
can
see
that
in
both
the
old
and
the
new
text
so
effectively
like
the
the
type
would
be
like
it
has,
the
the
of
type
right.
B
E
Sense,
I'm
just
going
to
suggest
an
edit
and
I'll
I'll
just
like
layer
it
in
there,
and
you
can
comment
directly
there.
I
think,
like
the
trade-off
here
is
when
you
spell
them
all
out,
then
it
is
more
clearly
obvious
what
it
is,
and
actually
I
think
this
is
a
good
actually
yeah.
The
previous
one
did
cover
both
the
name
type
and
the
modifiers.
E
F
B
E
I
mean
they
are
immediately
listed
below.
I
think
it's
just
this.
I
agree
this
is
an
improvement,
like
is
essentially
the
categorization
of
name
types
and
type
modifiers,
and
both
of
those
two
things
being
represented
by
the
same
concept
and
introspection
like
that's
actually
a
clarifying
edit.
That,
I
think
is
quite
useful,
and
but
my
my
only
minor
worry
is
that
someone
is
going
to
look
at
the
seed
name,
type
and
type
modifiers
and
be
like
wait.
What
are
those
again,
but
maybe
the
sentence
immediately
below
that
is
enough.
B
That
was
it
on
the
miner
once
my
plan
is
to
attempt
the
the
prettification
of
the
graphql
spec
again
at
some
point,
which
may
require
a
few
other
minor
changes
which
I'll
push
through
separately
and
then
at
some
point,
just
a
beautiful
white
space.
Only
pull
request
to
the
graphql
spec.
B
One
intention
of
that
is
that
I'll
do
a
diff
of
the
generated
spec
html,
both
before
and
after
that
change
and
assert
that
they're
both
the
same.
E
E
E
Very
nice,
okay,
I
think
that's
the
lot
of
what
we
wanted
to
talk
about
anything
else
of
anything
they
wanted
to
cover
and
bring
up
questions.
D
I
think,
like
last
time,
we
discussed
with
directives
or
introspection
things
that
a
couple
implementation,
graphical
java
t-sharp
another
trying
to
do,
and
I
think
mikhail
recognized
discussion
around
that.
So
yeah.
A
A
But
there
are
issues
around
that
and
the
the
the
problem
is
energy.
Graphql,
java
and
graphql.net
just
went
along
with
that,
and
then
they
found
out
issues
around
that
and
I
think
we
have
to
do
the
proper
work
and
really
bring
it
into
an
rfc.
A
But
for
that
we
really
have
to
get
the
people
together.
If
we
now
talk
about
that,
I
think
then
we
have
more
and
more
groups
talking
about
different
versions
of
that,
and
I
really
want
to
have
one
meeting
where
we
have
all
the
participants
from
that
to
just
synchronize
and
then
start
working
on
an
rfc,
because
otherwise
this
will
be
for
the
been.
G
So
should
we
explicitly
table
that
and
put
it
on
the
agenda
for
the
next
meeting
with
a
ping
to
people.
A
Yes,
I
tried
to
ping
them
in
the
work
group,
but
it's
very
difficult
with
the
time
zone
differences
I
mean
I
I
tried
to
get
with
benji
and
them
together,
first
and
then
I
put
in
even
because
of
graphql
js
and
but
it's
very
difficult
to
get
a
time
slot
where
all
of
us
fit
in,
even
though
there
are
no
americans
yet
involved.
E
But
yeah,
let's
table
it,
okay!
Well,
I
very
much
hope
that
we
can
talk
about
that
at
the
next
meeting.
Hopefully
you
have
a
chance
to
connect
with
andy
and
and
come
to
some
kind
of
direction.
You
all
want
to
propose
and
we'll
have
the
same
sort
of
slightly
later
time
slot,
which
is
hopefully
a
little
bit
better
for
andy,
so
he
can
join,
although
I
think
like
we're,
treating
this
as
an
experiment.
So
if
we
want
to
shift
the
time
slot
around
a
little
bit
more,
we
can
consider
that.