►
From YouTube: GraphQL.js Working Group - 2022-05-25
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
Great
you
not
too
bad
just
starting
the
day
off,
with
releasing
a
security
advisory.
B
D
D
F
C
H
Do
you
hear
my
vow
can
yeah?
Okay,
because
I
don't
hear
anybody
yep.
C
H
Right
now,
I'm
trying
to
stand
during
every
meeting
and
every
option
I
have
so
sorry
about,
like
I'm,
wait
for
a
couple
of
minutes.
H
And
it's,
I
think,
like
I
had
friends
for
adrian
quiet
agenda
for
rest
of
the
year
and
yeah,
and
also
big
thanks
to
rob
who
I
created
agenda
for
forward
meeting
particular
meeting.
H
Yeah,
so
we're
ready
to
start,
I
will
send
link
to
agenda
in
the
chat
so
on
some
bridge
yeah.
So,
like
first
thing,
we
will
go
through
agenda
quickly.
First
thing
is:
if
somebody
watching
and
want
to
join
and
special
journey
for
the
first
time,
please
sign
a
participation
guidelines,
membership
agreement,
the
code
of
conduct.
You
can
sign
this
individual
if
you
watching,
like
it
on
youtube
and
want
to
join
the
next
one.
Please
spike.
H
E
Yeah
sorry
about
that
hi
hope
you
can
hear
me
with
this
new
microphone.
G
Hey
folks,
I'm
benji-
this
is
my
first
graphql
js
working
group,
exciting.
D
I
am
hugh
also
from
apollo,
so.
H
Let's
start
and
it's
cool
that
it's
more
people,
it
was
meeting
we
still
fit
like
a
zoom
screen.
We
see
more
people
to
have
free,
buy
free,
but
the
more
people
the
better
so
about
the
discussion.
Quality
discussion
so
review
agenda
item.
So
today
we
have
like
a
couple
agenda
items
I
think
like
free,
but
all
of
them
are
kind
of
big
and
we
have
one
hour
so
and
actually
it's
like
perfectly
perfectly
fitting
so
15
15
and
20.
It's
like
50
minutes
and
yeah.
We
kind
of
on
the
schedule.
H
F
H
H
H
Yeah,
I'm
trying
to
remember
what
particular
one
was
on
the
previous
one,
because
we
have
like
one
standing
one
and
actually
the
good
thing
it
was
also.
I
think
it
was
those
action
items
thanks
to
banjo.
Now
we
have
like
security
policy
for
all
the
projects,
so
I
think
we
discussed
having
security
policy
on
graphql
json
and
we
didn't
feel
it
as
a
topic,
but
yeah
we
had
that.
H
So
yeah.
H
So
I
think
I
need
to
check
like
security,
it's
actually
from
you.
So
can
you
check
if
you
like?
What
issue?
Can
you
check
like
security
document
provided
by
banjo
and
if
it
satisfy
you,
can
you
please
close
it
or
we
can
add
like
additional
stuff?
Hopefully
we
will
have
white
policy
for
entire
project
for
the
project
and
the
foundation,
and
it
will
be
the
same.
H
So
let's,
let's
start
anybody
any
other
action
item
update
from
anybody
else
before
we
start
discussing
async
iteratable.
F
Yeah,
so
I
think
it's
well:
it's
agreed
on
that.
Having
the
ability
for
resolvers
to
return,
async
controls
would
be
a
prerequisite
for
supporting
the
stream
directive,
so
I
have
a
pull
request
for
that
that
I've
had
open
for
a
while,
and
there
was
some
discussion
about
if
how
we
would
handle
returning
multiple
results.
Multiple
results
from
the
resolvers
one
second
I'll
share
my
screen
with
the
discussion
topic.
F
Yeah,
so
the
what
what
I
have
implemented
right
now
is
basically
this
option
a
where
each
you
return
an
async
interval
from
the
resolver
that
yields
individual
values
and
those
values
get
processed
by
the
rest
of
the
graphql
execution.
F
How
it
was
proposed
should
we
return
list
of
values,
and
there
was
some
discussion
on
that,
where
I
think
both
ivan
and
benji
had
proposed
that
we
should
maybe
support
returning
yielding
individual
values,
but
have
some
way
of
indicating
to
the
executor
that
here
is
a
batch
of
results,
potentially
with
some
kind
of
symbol
or
something,
but
probably
with
a
helper
function
in
graphql
js.
That
would
handle
the
the
implementation
details.
F
H
E
I
mean
I,
I
think
I
personally
favor
just
just
just
keeping
the
signature
with
just
one
form,
meaning
with
an
array
of
single
items,
but
I
don't
really
have
strong
feelings
about
it.
I
wonder
if
everyone
or
if
anyone
has
an
intuition
as
to
which
is,
is
faster,
meaning,
meaning
in
general
like
or
sorry
what
what?
What
overheads
there
would
be
in
the
two
paths,
meaning
for
single
items.
My
route
would
involve.
E
You
know
the
client,
always
wrapping
them
in
an
array
and
and
then
be
assumed.
It
doesn't
have
to
be
checked
whether
they
need
to
be
unwrapped,
but
they
do
need
to
be
unwrapped
and
iterated
through
you
know.
The
other
way
is,
you
know
it
has
to
be
checked
whether
there's
a
single
item
or
an
array.
I
don't
know
if
it's
obvious,
which
one
I
don't
I
mean.
E
I
don't
know,
if
that's
an
obvious
concern
in
terms
of
speed
in
my
mind
you
know,
I
doubt
that
that'll,
because
you
know
that
speed
difference
is
an
issue,
so
I'm
sort
of
discounting
that
and
I
just
think
it's
simpler
with
one.
But
you
know
again,
I
don't
have
strong
feelings
about
it
and
I
agree
with
rob
that
it's
kind
of
time
to
advance
this
one
way.
H
Yeah,
I
provide
some
context
because
I,
like
personally
disagree
with
the
idea
of
the
return
by
one
just
to
document
with
discussion.
I
I
need
to
catch
up
because
us
understand
after
merging
rupiah,
we
still
need
to
continue
it
and
figure
out
a
way.
Basically,
why?
I
think
we
need
to
have
to
support,
like
I
think
it
readable
with
one
item:
it's
because
it's
like
javascript
primitive.
H
We
already
have
this
in
subscription
and
if,
if
you
have
like
third
party
library
for
doing
something
that
returns
iteratable
or
if
you
like-
basically
it's
like
it's
not
for
performance
because
for
performance
actually
yakov's
approach
is
it's
simple,
so
you
don't
need
to
do
a
check
and
but
my
concern
is
like
developer
experience.
So
for
me,
it's
like
weird,
if,
if
you
can
return
a
synthetic
ratable
in
subscription,
but
not
in
like
as
a
usual
field,
plus
with
particular
feature
to
put
in
context,
this
particular
pr
is
not
stream
and
defer
specific.
E
Well,
I
would,
I
would
stop
you
there.
I
think
it
does
make
sense,
because
every
time
you
know
you
need
a
the
algorithm
needs
to
separate.
You
know,
step
through
it's
better
to
have.
You
know
not
to
go
back
to
the
event
loop.
You
know
you
know
it's
better
to
have
whatever
results.
It's
always
better
to
do
better
when
huge
batches
block
the
event
loop.
I
mean
that's
a
separate
problem.
H
E
H
E
E
H
H
If,
if
you,
if
we
have,
if
we
return,
I
think
it
readable
for
list
of
lists
or,
like
some
nested
list
thing
field.
So
it's
like
errors
can
be
like
very
interesting
yeah.
But
in
any
case
since,
like
we're
now
in
alpha
stage-
and
there
is
like
not
a
strong
opinion,
we
can
merge
with
swing
and
work
on
a
wrapper
and
even
if
we
had
a
way
continue
basically
discussion,
just
not
to
block
rope,
because
I
think
rob
for
one
time
he's
rebasing
three
pr's
first
one
about
benchmark.
H
I
was
I
had
some
concerns
about
it,
but
why?
I
changed
benchmark
a
lot
recently
yesterday.
So
now
I'm
sure
like
rob.
Your
changes
of
doing
adrenal
weight
is
not
changing
anything.
It's
like
safe
to
merge,
because
yeah
and
with
the
second
pair
about
the
sim
card,
readable
and
yeah.
So
I
think,
like
core
issue.
We're
discussing
right
now
is
unbroken
rope,
and
since
we
have
like
a
c
phase.
E
Ivan
I
don't,
I
don't
think
that
make
that
make
sense,
meaning
if
you
know
we're.
Basically,
if
we
merge
this
pr,
then
we're
going
to
have
to
support
it.
I
know
we're
in
alpha,
but
we're
not
going
to
go
back
and
unsupport
it
before
it
gets
released.
I
mean
we're
essentially,
or
at
least
it
wouldn't
be
efficient,
meaning
you
know
we
can
just
decide
right
now
that
you
know
to
unblock
rob
and
to
just
go
for
it.
On
the
merits,
I
mean,
I
don't
think
anyone
else
is
really.
H
Yeah,
like
basically
I'm
saying
like,
if
you
don't
have
strong
opinion
and
if
everybody
else
I
agree
on
supporting
like
two
styles,
we
can
much
like
styles,
like
simple
version
and
much
performance,
optimization
as
second
pr,
and
I
actually
think
we
can
change
stuff
same
with
like
reverting
like
deprecation
removal
or
any
other
changes.
It's
like
experimentation
phase
in
a
sense
to
figure
out
and
to
get
feedback,
because
actually
stream
d4
is
not
technically
stage
two,
and
we
really
like
planning
to
do
some.
H
If,
if
you
do
performance
benchmarking
and
finding
out
like
there
is
huge
difference
in
with
checking
with,
is
it
array
or
not,
we
can
change
it.
E
C
H
I
now
say
what
yeah
I
say
like:
I
had
one
concern
about
performance,
but
since
I
might
finally-
and
previously
it
was
hard
to
measure
a
performance,
but
I
improved
benchmark
a
lot
so
now
we
can
really
measure
performance.
So
answer
question:
I
didn't
run
it
updated
version
yet
on
a
by
casing:
iteratable,
if
it's,
if
there
is
no
performance
degradation
for
existing
cases,
I'm
I'm
like
for
it.
H
And
and
let's
please
everybody
like
review
pr
because
yeah
it's
like,
I
think
we
have
a
spare
for
a
long
time
and
there
is
like
somebody
bases
and
changes,
and
we
can
do
final
read
before
matching,
but
basically
yeah.
I
think
it's
ready
to
match.
Let's
wait
like
a
day
and
have
everybody
chance
yeah
to
review
it.
I'm
also,
I
previewed
it
like
half
a
year
ago
or
something
I
need
to
like
review
it
to
see
like
if
the
basis
and
everything
is
is
okay.
H
So
one
thing
pl,
please
don't
cause
with
discussion
about,
like
I
think,
iteratable
and
bachank.
I
think
because
it
is
you
really
want,
even
after
the
much
eopr
discussion
should
stay.
F
H
C
H
C
H
H
No
so
yeah
I'm.
I
wanted
actually
to
prepare
to
this
one
and
I
didn't
prepare
slides,
but
I
will
try
to
explain
you
and
maybe
I
will
send
some
links
into
the
chat
so
we're
on
the
same
page.
So
so
we
had
this
issue.
We
had
this
issue
about
yeah
jakku
helped
me
and
answer
answered
a
bunch
of
like
issues
on
github.
So
now
it's
like
harder
to
find
discussions
yeah,
but
it's
a
good
thing
that
more
things
get
answered.
So
we
had
like
this
discussion
background.
H
So
basically
I
want
to
generalize
this
issue,
but
let's
start
from
decision
particular
in,
I
think
like
in
early
days
of
crafty,
js
2016-17,
it
was
at
the
some
experimental
feature
was
added
by
facebook
to
specifically
to.
H
So
later
I
marked
it
as
deprecated
hero
and
like
original
description.
I
I
agree
with
feedback
from
sahaj
and
others
like
not.
Everybody
should
go
through
git
boom,
so
I
need
to
to
have
like
better
description
on
brs.
I'm
not
working
on
it.
So,
like
all,
the
latest
vrs
have
like
significantly
bigger
description
and
all
of
them
have
description.
H
So
what
feature
was
added
to
support
non-spec
component
base
as
a
facebook
experiment?
Years
ago
I
spent
like
every
year
or
so
before
next
release.
I
think
facebook
guys
asking
to
remove
it
as
part
of
removing
of
facebook.
I
guess
is
it
specific
facebook,
luggage,
stuff
and
yeah?
I
tried
to
remove
it
now
and
find
out
that
it's
actually
used
by
jakob
to
implement
a
non
spa
component
feature.
So
it's
not
a
question
of
ipa.
I
used
for
ipl
used
for
like
speed
up
things.
H
H
Okay,
so
watching
it's
clear
so
another
big
example,
we
have
like
different
sdl
syntaxes
experiment,
so
initially
supported
descriptions
commands
and
it
was
in
bad
form
for
years
until
like
letter,
they
actually
changed
like
as
part
of
experiment.
He
changed
it
into
dog
strings
that
we
have
now
and
for
a
period
of
time.
We
actually
supported
that.
H
H
There
is
like
other
issues
like
fully
support,
like
add
a
new
new
like
symbols
to
waxer,
so
I'm
personally
for
having
a
policy
on
that,
because
every
time
we
have
like
this
one
discussion
like
not
in
in
some
cases
not,
but
in
other
cases
we
have
like
one
discussion
for
supporting
something
is
not
spec
component
and
for
me
answer
is
clear
if
it's
like
not
very
reference,
implementation
of
specification
and
it's
okay,
to
provide
some
like
customization
or
stuff,
but
provide
features
specifically
and
support
them
specifically
to
implement
non-spa
component
code
base,
I'm
like
against
it,
especially
since
we
have
rfc
process
and
we
have
icon
rebuilds,
and
we
have
other
mechanisms,
I'm
like
in
favor
of
like
just
saying,
if,
if
the
only
use
case
for
for
wet
features,
support
notes
by
component
think
we
should
not.
H
We
should
not
add
this
feature
and
we
should
remove
like
this
kind
of
hacks
we
already
have
but
asterisks
here.
If
something
is
used
for
like
have
valid
use
case,
but
can
also
be
used
to
support
non-spec
component
things,
it
will
remain
so,
for
example,
if
it's
performance,
optimization
or
if
it's
something
else.
H
G
You've
effectively
got
two
two
things
here:
right
you've
got
supporting,
as
you
say,
the
rfc
process
and
you've
got
supporting
other
people
that
aren't
using
the
rfc
per
process,
but
want
to
make
non-spec
compliant
changes.
So
personally,
I'm
all
in
favor
of
saying
no,
it's
the
reference
implementation.
It's
it
implements
the
graphql
spec
everything
that
we
put
into
graphql.js,
as
we
know
other
some
of
the
other
languages
literally
just
copy
that
and
translate
it
into
the
other
languages,
and
we
shouldn't
need
to
support
that.
We
shouldn't
need
them
to
have
to
support
that.
G
If
people
want
to
do
that,
the
the
graphql
library
itself
is
mit
licensed,
so
they
can
go
ahead
and
fork
it,
and
do
that
I
would
say,
maybe
have
a
policy
of
if
it's
a
rfc
one,
then
it's
okay
to
have
the
changes
in.
But
if
it's
not
in
an
rfc
process,
if
it's
not
reached
rfc
one
yet,
then
we
don't
add
it
to
graphql
js,
that's
my
opinion.
H
Small
small,
like
addition
to
your
command-
and
I
send
it
in
in
a
chat-
it's
like
a
reason
why
I'm
also
against
it,
because
people
copy
this
particular
feature
have
like
big
commands,
saying
you
should
not
use
it.
It's
experimental
and
other
disclaimers,
but
they
still
get
copied
to
python
implementation,
go
implementation
pro
and
one
implementation,
even
though
it
was
quite
clearly
marked
as
like
something
you
should
not
copy
so
yeah.
I
don't
want
to
influence
discussion.
Just
wanted
to
emphasize
your.
B
E
Yeah
so
I'll,
just
chime
in
here
I
mean
my
opinion.
To
those
who
read
the
thread
is
clear,
but
to
those
maybe
not
actively
following
is
maybe
and
listening
to
this
recording
later,
you
know,
maybe
many
years
from
now
the
github
is
no
longer
available.
E
So
I
just
want
to
point
out
some
context
and
because
I
think
it's
important
to
to
the
discussion
ivan
ivan
is
talking
about
a
broad
policy
and
couching
it
in
in
terms
of
examples
that
aren't
you
know
carefully
couching
it.
I
think
appropriately.
So
in
terms
of
examples
that
aren't
you
know
about
improving
the
speed
and
you
know
totally
custom
behavior,
and
I
think
it's
important
to
realize
that
that
could
be
happening.
E
That's
actually
not
what
happened
in
the
original
case,
not
this
time,
nor
the
last
time
this
came
up,
which
was
in
terms
of
customizing
execution
both
times
it
was
a
discussion
of
something
that
we
could
call
not
rfc
one,
not
rfc
0,
but
rfc.
You
know
sort
of
pre
rfc
0
in
which,
which,
last
time
I
was
talking
about
customizing
execution
to
work
on
a
version
of
defer
and
stream.
E
That
could
be
that
could
be
later
further
optimized
to
support
schema
stitching
that
that
you
know
hasn't
worked
out
just
in
terms
of
my
time
and
bandwidth,
and
here
we're
talking
about
the
addition
of
a
new,
a
new
introspective
directive
that
could
certainly
be
submitted
as
an
rfc.
E
That's
what
it's
actually
used
for
in
graphql
executor,
and
I
think
it's
important
to
realize
because
benji
was
talking
about
and
we
want
to
support
the
rfc
process,
and
we
can
also
talk
about
people
customizing
things
outside
of
the
rfc
process,
and
I
haven't
mentioned
that
we
might
want
to
use
these
hooks
later
for
people
that
people
that
are
want
to
experiment.
You
know
and
something
that's
being
actively
explored,
but
I
think
it's
important
to
realize
it's
the
same
hook
that
we're
talking
about
meaning.
E
Let's
say
later
six
weeks
from
now
or
three
days
from
now
or
next
year,
somebody
wants
to
submit
an
rfc
where
we
provide
experimental
support
for
a
custom
meta
field.
It's
the
same
exact
hook
that
would
need
to
be
brought
back,
meaning
so
the
hook
itself
provides
access
a
way
for
you
know
that
custom
behavior
to
be
injected,
but
the
hook
is
not
anything
that
violates
the
spec.
The
existence
of
the
hook
lets
someone
violate
the
spec,
but
they
certainly
don't
have
to
it
gets
copied
into
other
implementations,
which
is
true,
not
every
language.
E
I
suppose
put
the
hooks
in
that
customization.
Does
that
workflow
makes
sense?
I
think
that's
not
really
on
the
graphql.js.
E
You
know
you
know
reference
implementation
to
outlaw
and
the
hook
says
it's
deprecated.
You
should
never
need
to
use
it.
It's
not
marked,
as
you
know,
specifically
as
something
that
should
not
be
copied
into
other
languages,
and
even
if
it
is
copied
into
other
languages,
I
don't
know
sitting.
You
know
where
I
am
basically
in
the
javascript
world.
That
hook
wouldn't
be
helpful
in.
E
That's
that's
one
point
second
point
is
is
in
terms
of
what
benji
mentioned
about
forking,
graphql
js,
and
something
and
providing
something:
that's
not
spec
compliance.
There
is
a
broader.
You
know:
javascript
ecosystem,
that's
built
around.
E
Graphql
js
cannot
be
easily
for
and
the
reason
why
is
because
it
doesn't
provide,
or
to
my
understanding
I
could
be
wrong-
is
that
graphql
js
does
not
provide
like
a
typescript
signature,
that's
interoperable
with
any
other.
I
think
it.
You
know
it
provides
classes
and
it
has
instance
of
checks
that
you
know
will
fail.
E
You
know
if
you're
not
exactly
the
same
instance,
and
you
know
I'm
not
gonna,
I
I
you
know
we
could
talk
a
little
bit,
maybe
at
a
separate
meeting
or
in
terms
of
a
separate
issue,
a
separate
discussion,
whether
that's
a
good
thing
or
it's
a
bad
thing,
but
practically
speaking,
graphql
js
cannot
be
easily
forked.
Nor
do
I
think
it
would
be
good
for
the
ecosystem
for
it
to
be
poor.
I
think
it
would
be
very
bad
actually
for
the
ecosystem
and
I
think
it's
important
for
us.
E
You
know
to
realize
you
know
sitting
here
today.
This
is
a
graphql
foundation
project.
It's
meant
to
be
the
reference
implementation.
It's
meant
to
support
the
reference
implementation.
It's
meant
to
support
the
spec
and
support
changes
to
the
spec
and
it's
meant
to
serve
as
a
boilerplate
to
other
languages,
but
graphql.js
is
also
you
know,
a
production
ready,
graphql
runtime,
and
it's
used
that
way.
E
It's
used
that
way
by
many
companies,
some
of
whom
are
represented
here
and
some
of
whom
you
know,
are
not,
and
maybe
don't
care
or
maybe
have
their
own
implementations
you
know
could
be,
but
it's
it's
it's
very
important
to
the
broader
ecosystem
as
a
whole.
And
it's
you
know,
the
ability
to
you
know
hook
hook
into
that
pipeline
is
is
broad,
and
so
I
think,
taking
those
two
issues
together.
E
You
know
when
you
have
hooks
like
this,
that
don't
violate
the
spec
but
just
allow
access
to
experimentation
and
to
other
users
to
customize
but
are
not
per
se
against.
You
know,
you
know
anything
they
could
be
used
in
spec
compliant
ways
or
for
research
ways.
There's
no
reason
to
actively
you
know
tr,
you
know,
search
them
out
and
destroy,
let's
just
remove
them,
and
I
think
they
should.
There
should
be
better
ways
to
to
customize
the
existing
ways.
Now
we
have
a
few
ways
of
customizing.
E
It's
been
decided
that
the
general
way
of
customizing
things
is
to
export
them
as
a
class,
and
so
you
can
override
methods
and
in
some
cases,
that
that
is
actually
a
better
way
of
customizing.
E
Because
then
you
have
access,
you
don't
have
to
customize
in
the
real
place
it's
more
elegant,
but
I
think
basically
we
should
be
providing
as
hooks
as
appropriate
and
certainly
not
where
they
interfere
with
what
the
reference
implementation
is
trying
to
do.
We
shouldn't
be
bending
over
backwards
and
making
the
reference
implementation.
You
know
you
know
worse
or
non
itself.
E
You
know
not
really
demonstrating
the
language,
but
it
doesn't
seem
to
me
to
be
fair
to
the
overall
community
to
abandon
that
second
role
that
graphql
js
has,
and
it
doesn't
make
sense
to
remove
a
hook
or
things
that
are
not.
You
know
rfc
one
yet
and
put
it
back
in
in
a
couple
weeks,
the
same
hook,
you
know
for
things
that
once
they
become
rfc
one,
so
those
that's
my
two
cents,
thanks
for
listening,
yeah.
H
Can
I
clarify
so
like
hooks
and
rfc
process
is
not
in
a
sense.
It's
not
related.
If
you
want
to
add
top
level
and
transfection
field,
you
will
create
pr
that
at
top
level
introspection
fields.
So
if
you
try
to
do
experimentation
to
see
if
it's
work,
you
don't
need
the
hook.
You
just
create
icon
repo
and
add
the
introspection
hook.
If
you're
doing
rfc
0
1
like
any
rfc,
you
don't
need
the
hook.
You
just
add
introspection
field.
H
If
you
want
to
use
to
customize
something
in
in
your
just
your
application
experiment
with
your
own
applications,
you
can
use
canary
build,
you
can
build
it
yourself
and
use
actually.
Graphql
js
is
a
because
it's
peer
dependency,
it's
ideal
for
experimenting
in
your
own
code
bases,
so
you
just
build
the
package
and
you
use
your
custom
version
in
as
a
per
dependency
where
it
doesn't
work
in
one
specific
situation
when
you
want
to
provide
experimental
features.
H
It's
the
only
scenario
when
you
actually
need
those
hooks.
In
all
other
scenario,
paths
it
should
be
production.
Another
scenario
is
simpler
and
easy
if
you're
doing
like
experimenting,
prfc
or
rfc
or
like
for
simpler
to
just
like
modify
source
code
and
add
it
there
only
case
of
production
library
that
exists
outside
of
graphql.js
to
support.
One
spec
component
feature
is
like
visual
cases
restricted.
H
Anything
else
is
possible.
It's
like
clarification
about
like
fork
and
other
things,
but
yeah,
but
I
don't
want
to
like
idea
to
bring
in
a
graphql
dress.
Working
group
is
not
to
have
conversation
between
me
and
jakob,
because
we
already
have
this
inside
an
issue
bunch
of
time,
and
also
I
might
we
can
even
split
in
two
questions
like
should,
should
we
block
I
didn't
like
we
should
not
add
features
without
use
case.
Any
person
provide
the
use
case
for
a
feature
and
explicitly
say
I
need
to
implement
nonspec
component
thing.
H
C
H
H
Yeah,
so
in
this
case
I
tried
to
search
who
actually
using
it
it's
hard,
because
it's
not
a
function.
It's
positional
argument.
As
far
as
I
understand
it's
used
only
by
yaakov
and
he
he
starts
using
it
when
it
was
deprecated
to
ex
to
support
with,
like
fulfilled,
underscore
underscore
field
and
I'm
just
not
under
the
underscore
predictive.
H
H
D
H
So
I
think,
like
hook's
question
in
general,
as
jacob
said,
like
one
type
of
hooks,
it's
like
I
don't
know
like
disable
something
and
if,
if
like
you're,
completely
sure
that
it's
up
to
discussions
so
like
sometimes
hooks
makes
sense,
sometimes
not,
but
if,
like
you
have
a
use
case
that
don't
break
a
spec,
there
is
no
like
easy
answer.
It's
like
pros
and
cons
what
I
want
to
figure
out
with
this
discussion.
H
If,
if,
if
we,
if
like
no
spec
complaint
thing,
is
valid
use
case
or
not,
if
somebody
came
up
with
other
use
case
for
this
particular
function,
I
I
would
either
propose
like
alternative
ipi
or
like
not
remove
this
one.
But
with
this
ip
I
was
experienced
layered
to
support
on
spec
component
things,
and
there
is
nobody
waste.
Any
other
use
case
beyond
support.
Non-Compliant
thing
so,
like
question
here
should
be
how
like
basically
like
I
like
that
graphql
spark
have
a
clear
policy.
H
What
should
I
watch?
Wait,
favor,
no
change
in
other
policies
and
it's
helped
like
a
process
of
not
having
like
one
discussion
about
stuff
that
we
agreed
and
steer
like
a
project.
Have
a
clear
lake
what
what's
use
case?
What's
valid
use
case
for
this
project
and
what's
not,
and
for
me,
I
wanted
to
raise
this
up
to
start
this
process
for
graphql
js,
where
we're
publicly
discussing
what
valid
use
case
and
goes
for
his
project
and
what
not
and
use
with
this
discussion
as
like
opportunity
to
have
like
first
one
of
a
kind.
D
Yakov,
if
this
is
deprecated
and
removed,
how
much
does
it
impact?
Is
this
for
graphql
executor,
for
example,
where
it
would
have
the
biggest
impact.
E
Well,
I
mean
I,
I
doubt
the
impact
would
be
just
there
but
yeah.
It
would
be
very
large
at
all
yeah
to
me
and
if
anyone
would
know
ask
me
we
could
go
into
later
about
my
background
in
the
community.
Like
I
don't
represent,
you
know
high-paying
customers
or
any
or
any
like
any,
but
you
know
I
come.
I
come
at
this
as
a
you
know:
an
open
source
contributor,
meaning
if
this
hook
didn't
exist.
E
You
know
I
could
see
myself
submitting
a
pr
for
one.
I
could
you
know
in
my
mind:
it's
it's
it's
something
that
is
important
because
again,
there
are
two
roles.
In
general
I
mean
I
I
I
disagreed
with
the
framing
of
this.
You
know
discussion
to
begin
with.
I
didn't
think
we
should
make
it
a
global
policy
discussion.
I
thought
we
should.
E
That
we
could
that
we
could
do
things
to
begin
with
once
you
know,
once
ivan
turned,
you
know,
wants
to
talk
about
it.
The
other
way
around,
which
is
fine.
If
we're
talking
about
it.
The
other
way
around
you
know
you're
getting
away
from
what
would
happen
with
this
hook.
If
we're
talking
about
the
way
other
way
around,
I
think
it's
very
important.
Currently
you
know
and
again
not
really
representing
any
major
stakeholders
myself,
but
just
my
opinion.
E
It's
very
very
important
that
graphql
js
is
as
functional
as
possible
as
performance
as
possible
in
production
for
customers
you
know,
or
for
users
who
are
using
it.
I
don't
think
that
enabling
non-spec
behavior
in
the
spec
implementation
is
an
oxymoron.
I
don't
think
it's
bad.
I
don't
think,
there's
anything
wrong
with
the
code.
I
think
it
gets
copied
to
other
languages
and
I
think
that's
also.
E
Okay,
I
don't
think
a
spec
implementation
suffers
from
having
a
clearly
labeled
entry
point
to
say:
if
you
want
a
veer
from
the
spec,
here's
where
you
would
do
it,
if,
if
it's
harming
the
implementation,
if
it's
making
it
more
difficult
to
express
how
the
spec
could
be
implemented,
then
by
all
means,
but
if
it's
usually
it
shouldn't
be
like
that
meaning
having
an
entry
point
to
say:
okay,
here's
where
you
would
you
know,
branch
off
to
change.
Something
is
actually
more
explanatory
about
how
this
is
all
implemented
and
how
this
all
fits
together.
E
If
it's
done
right
and
again,
I
think
we
could
talk
about
how
the
hooks
could
be
done
better,
but
I
do
I
you
know
just
strongly
disagree.
I
guess
about
the
role
of
graphql
js
repository.
I
mean
the
github
repository.
It
is
the
spec
implementation.
It
is
a
graphql
foundation
project,
but
it
is
an
open
source
project.
That's
currently
maintained
you
know
by
the
community
at
large.
If
there's
a
clash
between
those
two
different
roles,
I
think
you
can
say
for
sure
that
the
spec
should
win
but
those
two
roles.
E
I
don't
really
think
the
roles
that
graphql
just
plays
one
is
the
referencing
location,
the
other
is
the
dominant.
You
know
pipeline
in
the
javascript
language.
In
this
case,
I
don't
think
those
two
roles
are
really
clashing
at
all.
It's
just
a
question
and
I
that
I
think
ivan
is
saying
we
should
only
focus
on
the
one
role
in
this
in
this.
You
know
to
answer
this
particular
question,
maybe
not
in
general,
and
I
don't
think
that's
true.
D
If
nobody
else
has
any
comments,
I'm
just
curious:
how
much
is
there
a
lot
of
maintenance
headache
involved
right
now
ivan
by
this
staying
in
place.
H
H
Yeah
and
every
time
every
time
we
support
a
feature,
for
example
like
if
person
using
this
hook
and
at
the
same
time
we
add
new
introspection
field.
It's
not
a
question
of
updating
graphql
js.
So
if
you
update
graphql
js
in
new
introspection
field,
edit
and
you're
using
this
hook,
you
will
not
get
it
like
yeah.
It's
like
that's.
H
E
H
Yeah
so
like
to
note
over
overwork-
and
we
still
have
a
topic
from
benji
like
my
proposal-
is
like
twofold
one
thing:
we
can
continue
discussion
in
what
topic
and
I
created
a
new
pair
to
separate
one.
It's
still
draft
about
getting
same
function
to
schema
and
now
going
to
subclass
graphql
schema.
If
people
want,
we
can
continue
technical
discussion
either
like
in
issues
that
echo
open
or
like
in
pr
that
I
opened
and
to
continue
and
to
have
public
discussion
long-term
public
asynchronous
discussion
about
this
policy.
H
I
will
create
a
pr
to
add
it
into
some
kind
of
document,
probably
like
development
document
on
something
else
with
like
a
text,
I
propose
to
add
as
a
policy
and
we
have
will-
we
can
have
like
long
term
asynchronous
discussion.
There.
D
Yeah,
I
think-
and
I
think
yakov
you
suggested
this
in
the
the
issue
thread.
This
does
kind
of
touch
on
both
responsibilities
of
I
think
this
working
group
and
also
the
graphql
working
group.
So
it
might
be
great
to
bring
this
up
as
a
a
bigger
topic
at
the
working
group
meetings
to
get
more
more
people
to
give
their
input
as
well.
E
Yeah,
I
don't
know
meaning
I
I
don't
know.
If
yeah
you
know,
I'm
not
hearing
any
strong
opinions
here.
It's
actually
that's
not
true.
We
had
an
opinion
from
benji.
C
Also-
and
I
guess.
C
D
Could
go
both
ways,
couldn't
it
because
you
know
having
this
flexibility
there
and
saying
that
graphql
js
is
also
a
library
that
can
be
used
for
experimentation
and
supporting
these
things
behind
the
scenes
and
letting
people
use.
Custom
servers
is
all
part
of
that
experimentation.
It's
a
really
compelling
argument
to
have
it
there
for
sure,
but
on
the
other
hand,
limiting
the
public
api
surface
area
that
you
have
to
support.
H
E
I
I
again,
I
you
know,
I
I
don't
think
I
I
guess
I
can
agree
with
you.
I
I
don't
think
the
the
eight
of
us
here,
the
six
of
us
with
our
video
on
really
really
represent
the
broader
ecosystem
and
I
think
the
graphql
js,
the
graphql
working
group.
You
know
rather
rather
than
a
pr
you
know,
describing
a
text
of
the
pilot.
E
I
mean,
I
think,
that's
sort
of
like
not
a
bad
idea
in
theory,
but
just
sort
of
like
punting
the
discussion
that
that
is
harder
to
do.
Asynchronously.
You
know
doing
it.
E
It's
hard
we're
doing
it
synchronously
now
and
we're
you
know,
and
we
did
it
asynchronously
on
the
previous
pr.
I
think,
opening
up
another
pr
is
not
the
best
way
forward.
I
think
bringing
it
to
the
working
group
to
the
main
working
group,
you
know,
might
be
dispositive
I
mean,
I
guess
you
know
they
sort
of
represent.
E
Will
be
going
to
represent,
you
know
the
the
the
repository
and
can
better,
maybe
tease
out
those
different
roles
and
form
a
policy.
C
E
Think,
that's
that's
what.
E
D
Yeah,
it
sounds
like
we
need
more
input
and
whether
that's
coming
from
the
community,
whether
we're
outreaching
trying
to
get
a
lot
of
people
to
chime
in
in
this
or
whether
it's
going
to
a
larger
group
and
getting
people
to
be
more
aware
of
this,
it
sounds
like
we
need
more
input
either
way.
I
mean.
A
Well,
I
would
say
we
need
a
base
to
customize
things
or,
like
at
least
have
hooks
for
stuff,
because,
like
it's
kind
of
a
need
like
you
can't
really
I
mean
yeah.
I
get
the
point
that
you
need
to
support
spec
and
be
spec
compliant,
but
if
you're
exporting
a
function
that
may
be
used
for
like
non-spec
ways
but
like
we
are
not,
I
don't
think
we
should
be
the
ones
deciding
like
it's
wrong
or
something
like
like
that
thing
may
be
used
for,
like
some
other
purpose
or
something
right
like
okay.
A
Maybe
this
use
case
was
specific
enough
that
you
may
not
support
any
spec
features,
but
like
customizing
graphql
js
itself
is
like
a
pain.
You
can't
really
do
anything
and
it's
even
harder
to
support
the
various
different
versions
of
graphical
js
so
like.
I
think
we
need
a
better
ways
within
graphql
js
to
just
customize
it
for,
like
at
least
get
rid
of
the
instance
objects,
because
those
are
like
the
biggest
ones
that
stop
us
from
being
able
to
do
much
more
customization.
H
Key
difference
like
for
me
is
like:
is
it
customization
based
on
like
you
want
more
performance,
you
want
like
certain
features
that
not
contradictory
spec
or
you
want
to
customize
it
in
a
way
that,
like
this
non-spec
compliant,
but
so
a
question
about
exporting
a
function,
everything
exported,
so
you
can
subclass
things.
You
can
well.
A
The
class
problem
is
like
a
bigger
problem
because,
like
now,
I
have
like
that
instance
off
with,
like
various
different
versions
of
graphql,
which
we
do
run
into
so
there's
like
a
bigger
discussion
to
have
like
how
do
we
get
rid
of
instance,
objects
and
then
customizing
could
it
depend
on
like?
Yes,
their
performance
needs?
And
yes,
maybe
sometimes
I
may
not
like
some
servers.
A
H
C
H
So
I'm
not
opposing
like
right
now
in
validate.
You
can
select
like
a
rule
that
you
apply.
You
can
bypass
any
validation
you
want
because
there
is
assumed
valid
so
assume
it
even
like
it's
by
passion,
validation,
but
people
have
a
validity
and
people
have
like
use
cases,
that's
back
compliant.
They
just
want
faster
server
startup,
so
I'm
like
for
skipping
but
not
to
yeah,
because
he
already
disconnected-
and
we
still
have
a
bench
topic
so
jacob
to
be
clear.
E
Yeah
yeah,
I
mean,
I
think,
honestly,
right
legally
and
and
sort
of
organizationally.
You
know
we
have
two
members
of
the
dsc
here,
but
decisions
in
general,
seen
by
the
group
of
the
you
know,
made
by
consensus
in
general.
You
know
of
all
the
working
group
members
I
mean,
and
I
and
I
think
we
could.
I
think
we
could
really
narrow
it
down.
E
I
mean
I've
heard
a
lot
of
discussion,
but
basically
the
main
arguments
that
I
see
is
in
terms
of
the
the
public
api
surface
and
what's
required
to
support
and
the
maintenance
burden.
I
don't
see
anyone
saying
that
it
detracts
from
the
reference
implementation
per
se
being
a
reference
implementation.
E
You
know
it
meaning
it
it
doesn't
yeah,
so
I
mean
so
that
I
think
again
and
I
think
there's
that
tension
there
between
the
two
two
different
things
and
I
think
it's
important
to
balance
it
and
I
think
respect
should
win,
but
I
think
that
you
know
bringing
it
to
the
main
working
group
and
just
you
know
getting
it
over
with.
E
H
Is
I
probably
like
open
pr
anyway
to
clearly
formulate
with
like
policy
and
having
it
calculate
so
like,
for
example,
there
is
valid
concern
from
sahaj
about
like
not
exposing
function,
not
allowing
to
use
it,
and
I'm
not
mentioning
that,
and
I
think,
if
we
put
it
as
a
policy,
it's
it
should
be
written
in
correct
form,
since
people
will
use
it
once
in
the
future.
H
E
H
Yeah
so
I'm
I
will
open
pr
and
I
will
open
edit
to
agenda
to
mine,
graphql
working
group
great
and
please
like
review
pr
like.
Even
if
we
disagree
on
a
policy
itself,
we
can
figure
out
a
way
how
to
don't,
have
collateral
damage
like
to
other
things
and
have
it
clearly
formulated
and
affecting
only
only
stuff
that
is
intended,
especially
like
yeah
police,
say,
save
a
lot
of
discussion
and
useful,
but
they
should
be
like
really.
H
If,
basically,
we
we're
creating
a
wall
in
a
sense
here,
yeah
so
switching
to
ubuntu
and
like
one-off
discussion,.
G
Cool
just
one
one
last
thing
before
we
move
on,
I
think
the
the
biggest
thing
out
of
this
is.
It
would
be
great
to
actually
gather
some
data
on
this.
So
maybe
we
can
add,
like
a
proxy
or
something
like
that
to
see
whether
people
are
actually
using
that
I
mean,
for
example,
with
the
validate
if
we
changed
the
argument
so
that
it
didn't
have
a
default,
and
then
we
just
see
if
someone's
passing
something
in,
do
a
console,
log
and
say
we're
thinking
of
removing
this
report
on
this
issue.
G
If
you
want
to
keep
it
something
like
that,
you
know
things
like
that
to
try
and
gather
more
data
to
see
how
widespread
this
is.
I
have
this
issue
with
my
open
source
stuff,
which
is,
I
don't
know
whether
people
are
using
these
apis,
that
I've
added
and
if
I
want
to
remove
them
later,
I've
literally
no
idea
there
could
be
zero
people
in
the
world
that
use
it.
There
could
be
like
just
the
one
person
somewhere.
It
could
be
that
10
of
the
user
base
use.
G
It
literally
don't
know
it's
a
really
challenging
problem,
especially
if
you
don't
want
to
add
monitoring
to
to
your
software,
which
obviously
no
thanks,
but
if
we
can
do
it
like
push
it
onto
them
and
just
put
a
log
the
first
time
it's
used.
This
is
deprecated,
we're
thinking
of
removing
it.
If
you
don't
want,
it
removed,
speak
up
and
then
leave
it
another
six
months
and
see
what
happens.
Yep.
H
It's
it's
valid,
I
think
I
felt
like
marking
stuff
is
duplicated
is
enough,
but
I
learned
that
typescript
is
not
validating
it.
H
It's
only
used
in
this
code,
which
is
strange,
so
we
scored
like
warn
you
about
using
duplicated
api,
but
no
ci
cd
2,
I'm
aware
of
like
don't
do
it
so
currently,
duplicate
directive
just
prevent
new
usage,
but
it's
not
like
95
people,
so
yeah,
it's
a
valid
proposal
of
improving
deprecated
and
actually
wait
having
all
this
discussion
upfront
and
not
have
like
yeah
back
and
forth
of
on
deprecated
type,
yeah
yeah,
it's
it's
it's!
Well!
H
It's
valid
sideway
of
this
discussion,
yeah
I'm
by
I'm
for
four
agent
deprecation
warnings
to
to
duplicate
stuff
that
we
have
yeah
cool
so.
G
So
one
off
yeah,
okay,
so
there
is
the
the
pull
request
raised.
It
was
originally
written
by
eric
and
I
have
done
a
number
of
changes
to
it
recently
to
to
bring
it
in
line,
make
it
past
the
tests.
You
know.
C
G
It
past
yvonne's
review,
which
was
of
course
very
important
and
good
spots.
I
think
if
I'm
there,
especially
with
the
the
is
one
of
versus
the
one
of
good
to
have
consistency
there,
so
I've
made
that
change
to
the
spec
proposal
as
well
as
to
the
graphql
js.
G
So
I
think
it's
in
a
good
state.
One
thing
that
I'd
like
to
know,
I
think
I
made
a
comment
at
the
time
is:
do
we
have
a
particular
policy
when
it
comes
to
error
messages
like?
Is
there
a
something
that
they
should
conform
to
or
like
that?
I
think
that
was
one
of
the
things
that
needs
like
validating,
but,
of
course
the
specific
wording
could
be
changed
after
it's
merged.
I'm
just
saying
that's
one
of
the
the
points
that
needs
looking
at
other
than
that.
G
What's
the
process
for
getting
this
merged,
and
would
it
would
this
be
something
that
would
only
be
in
in
17
or
is
it
something
that
we
might
backport
to
16,
for
example
like?
What's
what's
the
status
of
that
kind
of
thing.
H
Yeah,
so
to
to
simplify
like
first
thing,
you
need
to
do
and
it
will
make
my
wife
easier
and
it's
it's
like
a
machinist.
We
have
you
can
ping
graphql.js
reviewer's
theme
in
a
reviewer
button
and
five
people
get
gets
notified,
so
more
more
feedback,
and
we
also
decided
because
previously
we
had
like
with
with
process.
So
we
decided,
if,
like
two
two
people
from
from
review
or
sim
green
check,
like
with
pr,
we
still
have
like
two
weeks
to
to
get
the
feedback,
and
I'm
like
actually
like.
H
I
I
want
to
spend
a
little
bit
more
time
to
review
it.
I
see
like
some
some
stuff
missing
and
I'm
worried
previously.
We
have
like
that's
why
I'm
super
super
particular
with
introspection
field,
because
previously
we
have
problem
with
specify
by
url.
In
one
version,
url
was
capitalized
another
version.
The
url
was
written
as
like
the
url,
and
it
was
discrepancy
and
that
it
was
like
kind
of
breaking
change
to
change.
H
That's
why
I'm
I'm
like
what
I'm
doing
during
review
and
what
I
ask
like
sahaj,
yakov
and
anybody
else
to
review
during
to
do
during
review.
If
you
review
a
spec,
if
you
are
related
to
spec,
you
should
read
like
two
things
in
paraguay.
We
should
read
spectex
specs
proposal
and
graphqs
implementation
to
not
only
have
like
a
javascript
code
make
sense,
but
for
it
too
much
like
a
spec.
H
I
think
it's
super
important,
but
basically
answering
to
your
question
benj.
So
next
step
for
you
is
to
add,
like
a
review
team
in
reviewers
and
to
people,
and
I
will
try
to
also
to
speed
this
up
my
personal
review
process.
It's
just
pretty
pretty
big.
We
are
considering
spec
changes
that
you
review
in
two
parts
at
the
same
time
and
answering
a
question
about
versions:
16
versus
version
17,
if
with
pr,
doesn't
contain
a
breaking
change.
H
H
So
breaking
changes
are
okay,
but
there
should
be,
should
have
like
migration
paths
between
them,
so
yeah
without
breaking
change
stuff
can
be
backported
did
I
answer
both
of
your
questions.
Yeah.
G
That
sounds
good.
The
the
final
question
I
guess
is:
do
we
have
like
a
strategy
for
canary
releases
or
is
it
best
if
I
just
publish
a
fork,
and
we
can
just
substitute
that
in
our
dependencies
until
you
know
it
gets
matched
so.
H
Canary,
probably
your
pr
probably
is
a
little
bit
old.
That's
why
there
is
no
like
notification.
I
spent.
I
think
I
spent
like
too
much
time
on
it,
but
basically
in
all
new
pairs.
You
automatically
get
this
comment
and
I
will
send
it
to
you
in
a
second.
So,
for
example,
one
hour
ago
I
opened
a
vr
and
it's
how
we
have
this
command
in
it.
H
So
it's
like
comments.
You
can
post
comments
to
create
canary
releases.
You
don't
need
to
do
fork.
You
don't
need
to
to
have
like
a
branch.
You
just
write
inside
your
commit
message.
You
can
you
just
write.
Github
action,
publish
pr
on
npm
and
I
will
copy
past
it
here
and
I
can
start
it
for
you.
G
B
Yeah
do
other
packages
that
have
pure
dependencies
respect
this,
or
will
you
get
npm
errors
for
trying
to
install
a
canary
build
like
this?
I
see
they're
published
as
like
a
dash
alpha,
so
it
may
not
yeah.
H
H
What's
what's
wrong
with
this
experiment,
because
now
you
need
to
post
a
comment.
It's
clear
first
time,
contributors
can
execute
that
you
need
something
merged
into
repo
to
have
github
action.
Unblocked.
H
I
like
spend
a
lot
of
efforts
making
it
secure,
I'm
not
security
researcher
but
yeah.
I
did
all
my
best
to
do
it,
so
I
would
say:
wait
so
it's
run
with
it.
E
Yeah,
oh
I'm
sorry,
angie,
just
a
quick
question.
Maybe
you
could
review
the
one
of
directive.
I
think
it's
at
stage
two
now,
but
but
does
that
mean
that
this
pr,
you
know
basically
should
be
merged
at
this
point
as
long
as
it
passes
review?
Is
that
what
we're
up
to.
G
I'm
gonna
read
that
from
the
contributors
thing
to
make
sure,
but
I
think
so,
yes,
so
it
may
or
may
not
be
merged
in
order
for
it
to
get
to
stage
two,
it
may
or
may
not
be
merged
to
graphql
js,
and
that
is
the
state,
which
is
how
it
has
achieved
stage.
Two
I.e
having
a
pr
was
sufficient
to
reach
stage
two,
but
it's.
G
Yeah,
it
needs
to
be
it
either
needs
to
be
fully
tested
and
merged
in
graphql
js,
or
it
needs
to
be
like
ready
to
merge
for
it
to
advance
to
stage
three
I.e.
It's
up
to
you.
We
can,
or
we
can
choose
whether
or
not
to
merge
it
like
that.
Won't
stop
it
advancing
to
stage
three,
but
it
will
make
it
a
lot
easier
to
advance
to
stage
three
if
it
does
get
merged,
because
it's
then
easier
for
everyone
to
play
with
it.
E
And
we
certainly
can
merge
it
for
sure
right,
okay,
yeah
and
then
the
second
question
I
put
in
the
chat
in
terms
of
back
porting
it
it
does
introduce.
Basically,
a
new
reserved
word
in
the
directive
name
space
is
that
yeah.
Is
that
an
issue.
G
That's
an
interesting
question
and
it
has
come
up
before
in
the
graphql
working
group
proper
and
basically.
G
We
reserve
the
right
to
add
introspection
fields,
obviously
because
they're
reserved
with
the
double
underscore,
but
we
do
reserve
the
right
to
add
directives,
and
I
think
we
actually
went
to
the
effort
of
adding
a
non-normative
note
to
the
spec
to
suggest
that
you
name
space,
any
directives
that
you
add
now
I'd
have
to
look
that
up
and
actually
make
sure
that
we
did
add
that
in
the
end,
but
I'm
pretty
sure
that
that
was
discussed.
G
E
No,
but
I
I
don't
mean
to
introduce
it,
I
I
mean
to
backboard
it.
G
G
E
G
G
Sense
so
my
my
gut
feeling
for
this
kind
of
thing
would
be
like.
I
would
be
happy.
You
know
if,
if
graphql
js
hadn't
gone
undergone
any
things
that
required
major
version
changes
to
push
this
out
in
a
minor,
because
I'm
not
a
big
fan
of
masses
and
masses
of
of
major
version
bumps
for
things
that
should
not
be
generally
breaking
sure
you
may
have
done
something
but
like
this
is
very
much
like
the
the
slither.
G
You
know
the
naught
point,
not
one
percent
of
users
potentially
now
one
of
is
in
a
slightly
different
bucket
here,
because
certain
members
of
the
community
have
decided
to
go
ahead
and
implement
it
already
in
advance
of
the
spec
being
ready,
which
is
fun
so
that
may
be
more
challenging.
So
certainly
from
that
perspective,
I
think
we
should
wear
it
on
its
own
thing.
So.
H
Okay,
just
to
qualify,
it's
like
really
happen
in
javascript,
so
like
somebody
implement
one
of
as
in
javascript
ecosystem,
okay,
yeah
yeah.
If
if
what
happened,
I
think
like
a
way
forward,
if
we
discuss,
if
it's
not
purely
theoretical,
but
potential
conflict
test,
if
it's
conflict
or
not
like,
maybe
maybe
it's
like
implemented
and
in
a
way
that
not
conflicting,
so
it's
it's
executor
right
or
some
some
other
personal
okay
so
like.
If.
E
You
know
it's
an
envelope
plug-in.
C
H
Yeah,
but
we
need
to
test
it,
maybe
it's
compatible
and
if
it's
the
only
one
use
case
for
it.
Actually
we
can.
I
don't
know
if
it's
possible
through
github
code
search,
but
it
would
be
ideal
to
try
to
craft
a
query
saying:
did
somebody
call
the
new
graphql
directive
with
the
name?
One
of
I'm
not
sure
that
codes
are
support
that,
but
we
can
try.
We
can
definitely
put
one
off
and
graph
your
directive
in
the
same
query
and
see
like
if
there
is
any
matches.
H
If
it's
like
end
up
envelope,
we
can
just
test
it.
G
I
I
gotta
say,
though
I
think
that
when
it
was
added
to
envelope
like
yuri
and
the
team,
knew
that
this
is
a
feature
that's
being
added
to
graphql
right,
that's
why
that's
why
they,
you
can
use
it
before
it's
ready.
You
know
that
go
play
with
it
like.
It
was
very
explicitly
said
that
this
is
a
thing
that's
coming,
but
it's
not
here
yet,
but
now
you
can
use
it
with
envelope.
H
Yeah
one
one
thing:
maybe
it
might
be
worry
if
you
listen
to
because
expect
like
it
can
happen
to
to
other
changes,
is
if
you're
doing
plugins
just
add
experimental
to
a
name
so
x.
I
don't
know
if
it's
have
right
now,
experimental,
prefix
or
not,
but
yeah
so
basically
try
to
emphasize
its
experimental.
G
Again
the
name
spacing
like
yeah:
it
is
a
best
practice
for
that
kind
of
thing
I
think,
but
who
knows
maybe
they've
got
something
in
there.
I
haven't
actually
looked
at
it,
but
maybe
it's
got
something
in
there
that
checks
to
see
if
there's
a
one-off
directive
from
graphql.js,
and
if
so
it
doesn't
add
itself.
That
would
be
a
smart
workaround.
H
H
If
you
review
bench
apr
and
you
see
a
way
to
improve
proposal
like
it's
better
to
open
like
rfc
to
spec
and
suggest
it's
there,
I
think
we
can
suggest
a
lot
of
things.
I
have.
I
still
have
a
question
for
about
validation.
I
need
to
put
it
there.
Is
it
really
to
have
one
field
inside
one
or
for
not
and
like
other
things,
it's
just
like
before
posting
a
new
thing.
H
That's
why
I'm
actually
like
thinking
it's
okay
to
have
like
a
little
bit
longer
review
period.
So
everybody
have
like
this
apache,
because
when
it's
in
spike
it's
why
people
read
it
diagonally
a
lot
of
time,
like
some
people
read
it
carefully,
but
we
have
this
attitude
of
spending
more
time
reviewing
code
and
I
think
it's
beneficial
for
the
host
backpacks.
G
G
Oh
and
in
answer
to
your
question.
Yes,
one
field
is
perfectly
valid
on
a
one-off,
and
it
has
been
asked
before.
What
would
not
be
valid
would
be
zero
fields
which
is
currently
not
allowed,
but
obviously
there's
a
lot
of
people
that
keep
wanting
to
push
the
zero
fields
as
being
allowed,
and
then
we
would
have
to
add
a
validation
rule
for
one
off
to
forbid
that,
for.
C
G
H
Yeah
anybody
else
want
to
add
something
about
one
of
discussion,
because
before
we
finish
with
topic
and
with
working
group
now
any
other
important
discussion,
we
actually
over
run
half
an
hour
by
the
time
yeah.
Because
partly
we
have
this
heated
discussion
about
about
non
non-spec
component
things,
yeah
manly,.
H
Friendly
discussion,
yeah
yeah,
so
hopefully
we
have
a
next
step
for
all
items
for
all
discussion
we
have
today
yeah.
I
think
it
was
very
productive
meeting
yeah
feel
free
to
add
a
gender
items
to
the
next
one,
especially
since
we
have
like
agendas
until
the
end
of
the
year
and
feel
free
to
start
any
asynchronous
discussion
or
answer
like
discuss,
stuff
asynchronously
and
see
you
in
next
working
group
in
person
and
hopefully
we'll
have
even
more
people.
Then.