►
From YouTube: GraphQL Working Group - February 4, 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
D
D
F
C
E
How
are
you
holding
up?
I'm
good
energy
levels
are
high
within
our
virtual
office
walls
so
but
yeah,
it's
good
lots
of
good
work
happening.
Okay.
Good
to
hear
I
was
trying
to
like
switch
my
brain
from
work
mode
to
graphql
mode
in
the
last
few
minutes.
H
It's
been
interesting
at
work
last
few
weeks.
E
E
E
E
To
add
your
name
to
the
agenda.
If
you,
if
you
missed
that,
okay,
let's
kick
things
off
going
down
my
list
of
agenda
here.
Hopefully
everybody
has
a
link
to
this.
Let
me
just
drop
it
in
the
chat
just
in
case,
but
hopefully
you
all
have
that
at
the
beginning.
We
always
like
to
remind
everyone
that
we
and
being
here
agree
to
the
membership
agreement,
participation,
guidelines
and
code
of
conduct
links
to
all
three
of
those
are
in
that
agenda
file.
E
In
case
you
forget,
what's
in
them,
one
reminder:
haven't,
read
them
before
they're
right
there,
and
then
we
like
to
do
around
the
room
intro
of
everybody
here,
so
we
can
put
some
names
to
faces.
E
We
have
a
nearly
alphabetical
sort,
which
is
great,
but
we'll
just
go
in
the
order
that
it
appears
in
the
agenda
at
the
moment.
So
that's
me.
On
top
I'm
leigh,
your
faithful
leader
and
we'll
go
to
alan
from
there.
I
Hi,
I'm
alan
cha,
I'm
representing
ibm
research.
I
maintain
the
open
kneepad
to
graphql
library
as
well
as
I'm
interested
in
graphcode
management.
F
Hey
everybody:
this
is
brian
with
the
linux
foundation
and
I
help
support
the
various
operations
of
the
graphql
foundation.
B
Hey
everyone.
This
is
benji.
I
maintain
the
graphos
suite
of
tools
and
also
have
various
spec
things
on
the
go.
G
I
don't
see
eloy
here
so
I'll
go
next
hi,
I'm
evan!
I
work
on
graph
field
at
shopify
and
also
ended
up
kind
of
the
fact
representative
of
graphql,
ruby.
J
All
here
I'll
go
next,
I'm
matt,
I'm
I
work
at
facebook
and
mostly
work
on
client-side
graphql.
G
Dan
schaefer
fellow
facebooker
these
days
working
less
on
graphql,
but
here
emeritus.
I
suppose.
G
E
H
Go
ahead,
give
sasha
a
minute
to
get
on.
I'm
steven
work
with
netflix
and
just
coming
back
from
parental
leave.
After
about
six
months.
That's
it's
gonna,
be
back.
K
I
am
hey
everyone,
I'm
sasha.
I
work
at
twitter
yeah,
I'm
here
to
to
lurk
and
stuff.
N
O
E
Pretty
wild
anybody
else
here
that
didn't
get
to
intro
themselves
so
far,.
P
E
All
right
thanks
everybody
thanks
for
being
here,
I
see
a
handful
of
pencils
in
our
list
and
I
see
our
notes
file
already
filling
up,
so
maybe
it's
just
a
formality,
but
we
have
everything
covered
for
note
takers.
I
assume
alan
benji
and
steven.
You
guys
are
in
there
doing
great
work.
E
Okay,
we
have
a
little
bit
of
an
upside
down
piece,
so
I
do
want
to
review
our
agenda
before
we
jump
all
the
way
into
it.
We
have
some
tsc
stuff
to
vote
on.
That's
going
to
be
exciting,
we're
going
to
talk
a
little
bit
about
summer
of
code
for
this
year,
we'll
do
review
action
items
at
the
end
of
the
meeting
and
we'll
do
this:
promoting
and
documenting
the
spec
release
as
well
so
relatively
short,
which
maybe
is
a
good
thing,
but
anything
anybody
wants
to
add
to
this
agenda.
E
E
What's
up
with
this
new
membership,
doc.
F
Sounds
good?
Can
everybody
see
my
screen?
Yes,
okay
great,
so
we
talked
about
this
a
little
bit
in,
I
believe
the
past
working
group
meeting.
Basically
when
graphql
was
set
up
underneath
graphql
foundation
and
when
the
graphql
specification
project
was
formally
set
up,
it's
done
under
a
certain
set
of
documents
from
the
joint
development
foundation,
which
allows
you
to
quickly
and
easily
spin
up
specification
projects.
F
The
version
that
we
used
when
we
set
up
the
graphql
specification
project
had
a
couple
of
things
in
it,
which
make
it
a
little
bit
difficult
to
release
specs
quickly,
for
example,
requiring
a
new
signed
document
when
everybody,
whenever
you
want
from
everybody
who
contributed
whenever
you
want
to
release
a
spec.
F
Since
the
time
when
we
set
this
up,
linux
foundation
had
taken
over
management
of
joint
development
foundation
and
made
some
improvements
to
make
this
process
considerably
easier.
One
of
the
notable
improvements
was
that
you
sign
the
specification
membership
agreement,
one
time
which
is,
of
course,
what
everybody's
done
in
order
to
be
here.
There's
no
cost
to
that
or
anything.
It's
just
you're.
Basically
saying
you
agree
to
it
and
then
that's
it.
F
Then
we
don't
need
to
collect
signatures
again
every
time
we
want
to
do
a
release,
and
this
is
of
course
you
know
important
for
a
project
like
graphql
that
has
multiple
working
groups
underneath
it
multiple
different
projects,
that
this
is
a
definite
improvement
in
the
amount
of
overhead
that
it
would
take
to
have
things
be
formally
adopted.
F
F
The
there
are
a
couple
of
things
I'll
go
through
before
I
actually
take
you
through
the
vote.
It's
a
somewhat
formal
process,
but
I'll
walk
you
through
it.
Basically,
this
the
slide
that
I
have
up
here
says
you
know,
here's
the
the
this
is
what's
like,
what's
changing,
but
also
what
to
expect
so.
F
One
of
the
things
which
we
were
somewhat
concerned
about
was
that
there's
a
30-day
notice
period
after
we
take
this
vote
before
we
can
say
this
new
version
of
the
specs
or
new
new
version
of
the
specification
membership
agreements
are
adopted.
What
this
means,
though,
is
at
the
end
of
that
time.
F
Then
the
tsc
can
reconvene
vote
to
approve
the
spec
as
a
released
specification,
and
then
you
know
we
have
the
the
newest
version
of
the
graphql
spec
tsc
has
had
the
the
documents
to
review
and
then
also
reviewed
the
red
line
from
the
v4
to
the
v5.
I
didn't
get
any
questions
on
it,
but
if
anybody
does
have
any
questions
now
probably
be
a
good
time
to
ask.
G
Any
questions
about
this
just
for
somebody
who's,
not
a
tsc
member
or
the
two
documents
available
somewhere.
F
Yeah,
so
I
opened
up
the
new
document
or
open
up
a
pull
request
with
the
new
document.
It's
I
think,
currently,
the
only
pr
that's
open.
The
main
thing
really
to
be
aware
of
is
just
that.
It
it
moves
some
things
around.
It
doesn't
change
any
of
the
commitments,
so
that
maybe
start
with
that.
It
just
moves
some
things
around
and
makes
some
processes
easier
like
releases.
F
Otherwise,
the
existing
signatures
on
the
existing
documents
are
good.
You
know
we
don't
have
to
come,
come
back
and
collect
new
new
signatures
from
everybody.
E
You're,
referring
to
the
jdf
pdf
file
that
you
have
yep
called
correct,
I
did.
I
did
merge
that
one
and
I'll
post
the
link
in
the
chat,
because
thanks
yep
absolutely.
F
Okay,
so
we
have
met
our
fairly
strict
quorum
requirements
here.
So
I
guess
if
there
are
no
questions
here,
we'll
just
take
this
forward
for
a
vote.
Would
somebody
like
to
make
a
motion
to
adopt
a
new
version
of
the
jdf
specification
or
the
graphql
specification
membership
agreements?
I
moved
to
adopt.
G
F
F
Thanks:
matt,
okay,
a
second
okay,
now
tsc
members,
all
in
favor,
please
say:
aye.
P
E
F
Great,
thank
you.
So
now
we
have
adopted
the
v5
documents.
This
will
make
things
a
little
bit
easier
going
forward,
specifically
for
lee
and
myself,
but
should
make
things
hopefully
easier
for
the
other
maintainers
of
the
working
groups
as
well.
F
I
think
that's
everything
that
I
had
on
this
particular
topic,
the
one
closing
piece
of
information.
So
in
that
pr
that
that
lee
just
merged
it
has
the
final
version
of
the
documents
I
also
included
in
their
write-up
on
how
to
actually
sign
the
documents
for
people
who
haven't
signed
them
already.
Just
as
a
recap,
this
is
pretty
straightforward.
F
So
now
we
do
have
that
and
I
believe
it
is
in
a
directory
called
cla.
So
it
should
be,
hopefully
pretty
easy
to
find.
If
you
do
run
into
any
issues,
though,
or
if
any
of
your
colleagues
run
into
any
issues,
please
definitely
reach
out
to
me
we're
going
to
be
turning
on
the
cla
bot
for
the
rest
of
the
repos
here
now
that
everything's
well
documented.
E
E
I
will
fix
that
so
that
one
should
be
pretty
easy
and
the
other
one
is
that
we
actually
do
have
a
nice
little
phrase
at
the
top
of
the
graphical
working
group,
readme
file.
That
says
anyone
can
show
up,
but
they
have
to
go
sign
this
spec
membership
agreement
and
it
links
out
to
that
foundation
repo,
I'm
just
going
to
change
that
link
to
point
to
this
new
membership.
Folder
that
you
added
since
it
also
has
that
nice
explainer
yeah.
I.
F
Think
that's
a
lot,
a
much
more
logical
place
to
find
it.
The
other
side
of
this
too.
One
of
the
reasons
for
asking
people
to
pr
themselves
onto
the
agenda
is
that
it
will
take
them
through
this
flow
and
it
will
make
sure
that
everybody
who's
attending
the
meetings
has
actually
signed
the
membership
agreement.
So
this
is
something
for
the
other
project
maintainers
or
the
work
working
group
maintainers.
F
When
we
get
this
turned
on
for
your
repos,
it
will
also
enforce
and
make
sure
that
the
attendees
to
your
meetings
have
signed
all
the
necessary
documents.
They
need
to
do
sweet.
E
I
believe
that
worked
yep
okay,
I
just
updated
the
link
on
the
graphical
working
group.
Repos
read
me
file.
F
So
for
the
summer
of
code
we
did
summer
of
code
last
year.
Yvonne
was
very
helpful
in
the
mentorship
process
and
yuri,
I
believe
you
may
have
also
mentored
as
well.
Last
year
the
process
is
or
the
the
application
period
is
open
again,
and
I
opened
up
a
a
file
where
you
can
drop
in
your
suggestions
for
projects.
F
F
It
should
be
pretty
straightforward.
I
lee
I
don't
know
if
you
want
to
say
something.
I
know
many
of
the
folks
here
aren't
on
the
governing
board,
but
there
was
some
discussion
last
year
about
how
you
know.
Mentorship
is
a
really
it's
a
core
part
of
the
way
that
the
foundation
wants
to
help
support
the
actual
graphql
projects
and
at
the
time
we
had
said,
was
it
that
we
wanted
to
have
at
least
three
interns
per
year.
I'm
trying
to
recall
exactly
what
it
was.
I
don't.
E
E
That
include
me,
and
I
don't
remember
who
was
there
the
last
time
we
talked
about
it
yuri
he
may
have
been
there,
but
I
remember,
most
of
the
discussion
was
actually
from
the
technical
contributors
talking
about
which
projects
could
or
couldn't
take
summer
of
code
mentees,
and
we
realized
that
we
were
just
having
that
conversation
in
the
wrong
place,
and
this
working
group
would
be
a
much
more
fruitful
place
to
talk
about
this,
since
we
actually
have
a
large
set
of
people
who
work
on
projects
in
the
graphql
ecosystem.
E
So
this
really
like
the
main
thing
that
I
want
to
point
out
is,
I
feel
like
last
summer.
We
actually
got
a
fair
amount
of
value
out
of
this
and
yvonne.
Maybe
you
can
say
something
about
what
that
process
looks
like
for
you,
and
my
sense
is
that
we
should
do
this
again
and
we
should
kind
of
double
down,
but
we
should
spread
out
across
more
projects,
so
we're
not
only
in
graphical
js
graphical
could
be
another
one.
E
O
O
O
This
year
is
180
or
something
so
it's
for
shorter
projects
which
make
it
easier
for
maintainers,
and
it's
my
selection
of
ideas,
bigger
and
last
year
it
was
our
first
year
as
organization
for
summer
of
code,
so
we
had
like
two
mentors
me
and
graphical
maintainer
and
I
don't
remember
what
happened
with
like
student
for
graphical.
It
was
some
situation,
but
we
had
a
student
for
graphql
js
and
he
created
the
password
experimental
project
issue.
Experiment.
We
need
to
clean
up
some
stuff
after
it.
O
But
important
thing
I
want
to
point
out
is
how
both
sides
is
help
students
and
help
like
promote,
promote
contributions
and
it
helped
onboard
new
maintainers
and
new
contributors,
but
the
same
time.
It's
like
helped
me
personally
because,
like
I
pressed,
I
didn't
have
any
experience
of
mentoring,
somebody
and
it's
like
teaching
you
how
to
basically
mentor
people
and
how
to
onboard
on
a
project.
O
Another
thing
you
can
suggest,
for
example,
right
now
for
graphql
js,
we
have
active
contributor
saheed
and
he
helped
with
typescript
immigration
award.
He
like
did
tremendous
job
making
like
pr
super,
clean
and
separate
commits.
O
O
So
a
summer
of
code
is
a
way
for
to
find
new
contributors
and
it's
a
good
way
to
help
contributors
for
the
students
and
looking
for
summer
practice.
One
thing
I
would
say
it
was
my
favorite
and
like
general
problem
for
krav
keel
foundation
last
year,
is
that
we
failed
to
create
good
communication
with
applicants.
O
I
think,
like
uri,
helped
and
communicate
with
some
of
applicants
for
summer
of
code
and
seasonal
dogs,
but
in
general
we
had
a
bunch
of
emails
and
with
like
simple
questions,
and
we
here
we
should
like
write
document
answering
them
instead
of
like
ignoring
them
or
like.
So,
I
think
like.
We
need
to
prepare
more
for
communicating
with
applicants,
because
previously
previous
year
it
was
like
50
or
70
applicants
and
a
huge
amount
of
females.
L
I
want
to
maybe
I
don't
want
to
beat
the
downer,
but
I
want
to
maybe
add
another
thing
that
we
might
consider
when
we
going
to
google
summer
of
code.
L
I
think
we
should
also
always
remember
that
at
this
stage
of
the
graphql
js
project
events
time
is
the
most
expensive
thing
we
have
and,
and
I
and
current-
and
we
have
like
a
very
large
project,
currently
the
typescript
migration
that
we're
working
on
for
a
very
long
while-
and
it's
basically
also
holding
up
a
lot
of
other
projects
that
are
waiting,
and
I
think
that
what
we
should
be
very
careful
of
is
making
sure
that
as
much
as
google
summer
of
code
is
extremely
important,
and
I
support
this
project
a
lot-
maybe
others,
including
myself,
that
I
can
volunteer
to
it-
can
be
the
mentors
and
maybe
offload
some
of
that
work
for
events,
so
at
least
ivan
can
keep
focusing
on.
L
You
know
getting
the
type
sigma
type
stream
migration
done.
So
all
the
rest
of
the
projects
will
come
in
and
we
can
add
more
contributio
contributors,
including
you
know.
There's
also,
I
mean
it's
important
to
bring
on
new
students
and
new
people
for
the
code,
but
there's
also
a
lot
of
people
in
the
community
that
have
a
lot
of
experience.
That
also
can
become
contributors,
so
just
to
make
sure
that
we
have
the
right
priorities
here.
E
It's
a
good
point.
I
hope
we
can
land
this
in
a
spot
where
it's
not
either
or
but
it's
a
really
good
point
that
we
should
be
thoughtful
about
what
projects
we
want
to
land
people
on
to
make
sure
that
they're
adding
value.
E
The
goal
that
I
have
for
the
google
summer
of
code
work
is
to
create
new
future
members
of
this
community
and
long-term
contributors.
So
if
someone
shows
up
does
a
couple
of
projects
for
a
few
months
and
then
disappears
never
to
be
seen
up
again,
hopefully
they
leave
behind
some
valuable
work
and
like,
but
I
see
that
as
a
wash
like
the
real
win
is:
if
we
get
someone
land
them
there,
they're
really
excited
about
it.
They
like
the
work
and
they
want
to
stick
around
in
the
open
source
community
over
the
long
haul.
E
Beyond
just
the
internship
period.
Obviously
their
frequency
of
work
is
going
to
slow
down
once
they
go
back
to
school,
but
if
we
can
keep
them
around,
that's
a
good
thing.
The
other
thing
I'd
like
to
see
if
we
get
some
summer
of
code
mentees
is
to
make
sure
that
they
join
at
least
one
of
these
meetings.
E
I
think
that
was
a
I
identified
as
a
miss
last
time
is
that
we
had
them
working,
but
they
never
really
got
to
like
meet
this
group
of
people
who
are
really
proactively
pushing
graphql
forward
across
all
projects,
and
that
meant
that
we
also
didn't
really
get
to
like
build
a
personal
link
to
each
of
these
folks.
So
that's
one
thing
that
I
want
to
make
sure
that
we
we
do
next
time
around,
but
great
points
to
both
of
you.
E
I
I
do
want
to
make
sure
we
can
move
on
to
our
next
topics.
The
one
lightweight
action
that
I
want
to
land
here
is:
if
everyone
could
just
think
about
potential
projects,
it's
just
much
easier
to
do
the
connection.
If
we
already
know
what
interesting
projects
look
like,
rather
than
sort
of
getting
them
pre-booked
to
a
project
and
having
them
self
assign
a
project
after
the
fact
and
last
time
we
did
it
for
graphical
and
graph
graphical
and
graphql
js
going
forward.
We
could
expand
that
set
to
a
wider
set
of
projects.
E
So
as
long
as
it's
open
source,
as
long
as
it's
sort
of
like
a
core
piece
of
the
graphical
community,
then
we
can
make
it
part
of
the
foundation
umbrella.
We
can
consider
them.
M
O
O
One
thing
is
that
you
can
organize
a
lot
of
voice
work
asynchronously,
you
don't
need
to
spend
like
five
hours
on
a
call
like
you
can
ask
your
student
to
prepare
like
a
fork
or
a
branch
or
pr
and
just
monitor
his
comments.
But
I
think,
like
five
seven
hours
per
week
is
per
student
is
a
requirement.
O
This
year
was
actually
doing
a
shorter
period.
So
it's
like
appreciate
was
three
months
right
now.
I
think
it's
like
month
and
a
half
or
something
so
wow.
That's
sure.
E
F
The
mentee,
so
it's
they
cut
it
basically
in
half,
so
it's
still
roughly
the
same
length.
It's
just
about
half
time,
I'm
just
looking
to
see
if
the
mentor
guide
has
any
expectations
on.
E
Cool
a
process
that
I
found
works
really
well
for
this
is
have
two
synchronous,
check-ins
and
then
time
for
code
review.
So
if
you're
proactive
with
code
review
and
you've
got
usually
30
minutes
is
good.
Sometimes
the
follow-up
can
be
shorter,
but
sometimes
you
need
30
minutes
for
both
and
you
just
kind
of
stick
two
in
a
week
spaced
out
that
tends
to
be
good.
E
You,
like
you,
can
catch
high-level
stuff
in
those,
and
you
can
also
you
know
talk
about
broader,
more
interesting
things,
questions
on
their
mind
beyond
just
the
work
and
that
that
probably
does
add
up.
I
would
suspect
it
adds
up
to
less
than
five
hours,
but
that's
not
an
unreasonable
like
high
water
mark
time,
expectation.
E
Yeah
absolutely
any
other
questions
on
mentors
summer
of
good
stuff.
Otherwise
we
can
move
on.
L
A
F
E
Then
the
agenda
is
a
link
to
the
a
proposal
template
and
we
have
a
channel
in
the
slack.
E
I
think
probably
the
right
thing
to
do
here
is
to
use
this
this
directory
and
just
make
them
individual
files
so
like
copy
the
the
template
that
brian
put
together
fill
out
the
idea
they
don't
have
to
be
super
in
depth.
E
As
you'll
see,
it's
like
two
sentences
of
the
description,
a
couple
bullet
points
of
the
objectives,
what
you
need
to
see
in
a
mentee
and
then
who's
available
as
a
mentor
and
then
submit
that
as
its
own
markdown
file
and
we'll
just
have
a
bunch
of
files
that
we
can
then
sift
through
at
the
end.
And
then
you
can
just
like
ping
in
the
channel.
If
you
have
questions
or
if
you
just
want
to
say,
like
hey
commerce,
my
pull
request.
F
Yeah,
so
this
is
another
one
that
I
put
in
the
agenda.
So
basically,
now
that
we
have
the
the
v5
membership
agreements
adopted,
it
will
be
a
lot
easier
to
cut
the
release
and
we
need
to
actually
start
preparing
for
it
lee.
I
think
you've
been
doing
a
bit
of
work
on
on
cleanup
on
the
spec,
and
I
won't
talk
about
that
since
you're.
F
The
expert
on
that,
but
I
just
will
mention
that
we
had
a
foundation
marketing
meeting
and
we're
gonna
be
having
these
monthly
from
now
on,
and
one
of
the
things
which
we
discussed
is
just
ways
which
you
know
we
can
prepare
for
the
spec
release,
how
we
can
promote
it
and
how
we
can
make
sure
that
we
have
enough
information
out
there
about
what
exactly
is
hap.
You
know
what
exactly
is
changing
and
what's
been
happening
over
the
past
18
months
or
so.
F
I
won't
take
up
too
much
time
on
this,
but
if
you
have
documented
one
of
your
features
or
have
written
up
anything
or
are
interested
in
writing
up
something,
please
let
me
know-
or
let
me
know,
we'd
like
to
accumulate
these
things
and
maybe
put
together
just
kind
of
a
comprehensive
picture
of
what
we
can
use
and
what
we
can
point
to
when
the
spec
gets
released,
to
be
able
to
build
the
narrative
around
it.
F
You
know
here's
what's
changed
or
here's
something
subtle
which
was
resolved
or
here's
a
community
experience
of
working
in
the
graphql
community.
You
know
all
of
these
things
are
really
it's.
These
things
are
all
really
good
to
have,
and
this
would
be
a
really
good
time
to
point
to
some
of
those
things
whether
they
are
brand
new
or
things
which
have
been
written.
You
know
over
the
past
18
months.
Lee
do
you
want
to
say
anything
else
about
that.
E
Yeah
just
to
back
up
a
bit
and
kind
of
explain
the
strategy
and
why
we
would
do
this
in
the
first
place,
so
you
all
know
that
for
the
most
part,
reference
implementations
and
even
internal
implementations,
more
or
less
track,
the
draft
or
even
beyond
that
they
track
just
approved
proposals
even
before
they've
been
merged
into
the
draft.
E
So
like,
what's
the
value
of
doing
these
spec
cuts
beyond
the
legal
process,
the
other
value
is
having
a
moment
in
time
that
it's
relatively
irregular
to
essentially
retrospectively
look
at
all
the
work
that's
gone
into
it
and
celebrate
it
at
the
same
time,
and
that's
kind
of
the
perspective
I
want
to
take
on
this.
It's
not
like
the
story,
isn't
hey.
You
can
finally
use
all
these
things
because
people
have
been
able
to
use
them
all
along.
It's.
Let's
look
back
at
all
of
the
work:
that's
gone
into
graphql
over
the
last.
E
It's
been
18
months,
at
least
probably
longer
since
the
last
cut
and
the
strategy
for
doing
that
is
not
a
you
know.
Pr
briefing
from
the
graphql
foundation
blog
something
like
that.
I
think
that
would
be
a
not
a
great
way
to
celebrate
our
work
and
be
probably
mostly
ignored
by
the
people
who
we
want
to
see
this.
E
Instead,
I
think
it's
actually
just
to
let
the
individual
people
who
are
actually
doing
the
work
aka.
All
of
us
to
spend
a
bit
of
time
writing
about
what
the
experience
was
like
to
contribute
the
details
of
the
work
you
know
there
are.
There
are
definitely
a
handful
of
things
that
are
practical
like
this
is
useful.
You
can.
You
can
do
a
new
thing
that
you
couldn't
do
before
and
it's
worth
hearing
what
that's
about.
There's
also
a
lot
of
stuff.
E
That's
just
kind
of
wonky
and
you
know,
ambiguity,
resolution,
and
I
think
that
stuff
is
interesting.
Maybe
I'm
weird,
but
I
suspect,
a
bunch
of
other
people
will
also
find
that
interesting
that
don't
regularly
show
up
to
these
meetings
and
just
to
say,
like
hey,
so
maybe
you're
curious,
like
what's
it
like
to
write
a
spec
document
and
when
you
find
an
ambiguity
like
what
does
that
mean?
What's
the
real
world
consequence
and
how
do
you
go
about
solving
it?
E
E
I
know
some
of
these
have
already
been
launched,
I
think,
maybe,
halfway
through
last
year,
we
started
making
it
kind
of
an
unofficial
policy
that
for
semi
major
changes
as
they're
getting
close
to
finalized,
we
want
someone
to
go,
go
write
a
blog
post
that
explains
what
they
are
and
how
to
write
them.
E
We're
just
going
to
start
to
collect
both
the
ones
that
we've
already
written
and
then
also
like
the
stories
that
we
want
to
tell
and
get
them
into
a
list,
so
both
in
the
the
graphql
twitter
account
and
then
our
newsletter
and
all
the
various
other
ways
we
have
to
talk
to
people.
We
can
like
regularly
link
out
these
blog
posts
and
then
hopefully,
that'll
create
energy,
not
around
the
fact
that
a
cut
happens
but
energy
around
the
fact
that
there's
work
over
the
last
year
and
change
to
celebrate.
E
So
the
the
concrete
request
here
is,
if
you've,
if
you've
written
such
a
thing,
we
haven't
been
tracking
this
so
like
please
ping
it
to
brian,
bring
it
ping
it
to
me
on
slack
or
wherever,
because
we
want
to
start
to
track
all
these
things
in
a
list
and
b.
If
you
have
an
idea
either
whether
it's
for
something
that
you've
done
yourself,
you
want
to
write
a
post.
You've
got
a
topic
that
you
want
to
write
about
or
something
you
want
to
kind
of.
E
E
Please
message
that
to
brian
and
me:
we're
gonna
do
a
little
bit
of
that
ourselves,
but
I
don't
anticipate
that
the
two
of
us
will
be
able
to
come
up
with
that
full
set
of
ideas
and
we're
gonna
build
that
into
a
list
and
then
start
to
kind
of
build
a
process
around
it
where
for
the
ones
that
we
want
to
see
written,
we're,
you
know
putting
them
in
front
of
people
as
opportunities
to
see
if
they
want
to
grab
them
and
then
seeing
how
much
of
that
we
can
finish
in
the
next
month
or
so
before
we
go
live
with.
G
Everything
not
directly
about
the
marketing
side
of
things,
but
about
the
spec
release.
There
are
a
handful
of
rfcs
that
are
in
kind
of
very
late
stages
of
just
needing
a
kind
of
final
editorial
pass
and
then
merge.
Are
you
planning
to
do
all
of
those
like
in
a
batch
after
the
release,
or
are
we
going
to
try
and
squeeze
them
in.
E
I'm
going
to
squeeze
them
in
yeah.
Almost
all
of
these
are
finalized
and
they
just
need
final
editorial
passing
from
me
before,
adding
them
in
like
they
don't
need
any
action
from
this
group.
Therefore
they
should
be
completed.
E
I
I
know
of
at
least
two
or
three,
and
actually
one
thing
that
you
can
do
to
help.
I
think
I
I
know
about
all
of
them,
but
most
of
what
I've
been
using
to
find
those
are
tags.
So
I
look
for
things
that
are
either
tagged
as
editorial
or
tagged
as
stage
two
and
those
are
the
ones
that
I've
been
giving
most
of
the
attention
at
some
point.
E
In
the
end,
I'll
probably
just
call
through
all
of
the
pull
requests
just
to
make
sure
I
haven't
missed
anything,
but
there
there
definitely
are
pretty
significant
amount
of
pull
requests
there.
I
want
to
make
sure
I'm
putting
my
energy
into
the
ones
that
we
most
want
to
have
merged
all
of
the
ones
I
can
think
of
have.
O
Them
I
have
one
thing
to
suggest:
one
thing
that
may
cause
frustration
is
that
some
things
are
included
in
release
and
some
are
not
stuff
for
extreme
and
deform.
For
example,
it's
like
usable,
but
we
decided
to
give
it
like
experimental
pass
and
over
the
last
couple
of
months,
people
using
it
and
they
discovered
some
things
about
it
so
and
it's
becoming
popular
so
like
rob
and
lydia
are
speaking
on
every
conference
and
stuff.
O
So
and
one
of
the
question
I
was
like
on
some
panel
organized
by
hazura
a
couple
days
ago,
and
the
question
was:
why
is
tremendously
experimental?
So
I
think,
like
in
release
notes,
not
the
release,
notes.
Obviously,
release
notes
should
include
only
stuff
that
released,
but
in
a
blog
post
about
new
release.
I
think
it
would
be
good
to
point
out
or
extremely
default
plus
we
have
a
bunch
of
articles
about
it.
O
Maybe
like
a
couple
couple
sentences
explaining
why
it's
experimental
with
you
like
still
collecting
feedback
the
same
with
about
input,
unions,
people
actually
like
what
and
put
unions,
and
we
did
a
bunch
of
progress
on
it,
but
it's
still
not
on
the
smack.
O
So,
like
I
would
say,
book
cost
can
like
mention
some
stuff
mentioned
by
current
progress
of
office
proposal
and
some
links
in
case
of
stream
streaming
default.
Who
wrote
an
article
about
that
and
in
case
of
in
case
of
input,
unions,
wins
and
a
bunch
of
other
contributors
create
rfc,
and
we
can
point
rfc
and
say
like
we're
working
on
it
and
you
can
track
progress
here.
E
Very
good
point:
yeah,
that's
a
great
suggestion,
so
I
do
plan
on
writing
a
release,
notes
kind
of
like
a
very
detailed
here's.
Every
kind
of
detailed
change
that's
landed
in,
but
I
really
like
that
suggestion
and
I
think
that's
a
good
way
to
kind
of
frame
the
overall
messaging
is:
we've
done
a
spec
cut.
Here's
everything!
That's
in
this
version
of
the
spec,
but
then
also
here's
all
the
stuff
that
we're
currently
working
on
and
like
give
a
just
like
a
brief
kind
of
sense
of
where
it
is
in
its
process.
E
Yeah,
that's
a
great
idea!
I
really
like.
E
E
Thoughts
all
right,
I
think
the
last
thing
we
have
is
to
work
through
our
open
action
items
and
get
a
sense
of
which
ones
are
done,
that
we
can
close
benji,
usually
help
us
work
our
way
through
here.
Where
should
we
start.
B
Well,
someone's
been
very
helpfully
filling
this
all
out
in
the
notes
which
is
fantastic,
so
I
would
normally
do
the
ready
for
reviews
first.
So
let's
do
them
in.
I
guess
oldest
order
first,
so
we'll
look
at
507,
which
is
moving
the
deprecated
directive
in
the
input
fields
rfc
to
stage
two.
B
2.,
so
I
think
this
one
is
it's
uncertain.
What
the
actual
state
of
this
is-
and
I
think
you
lee
need
to-
I
think
you
were
gonna-
promote
it
at
one
point,
but
I'm
not
sure
what
the
conclusion
of
that
was.
E
E
I'm
gonna
move
this
to
stage
two
because
yeah
I
I
remember
last
time
we
reviewed
these.
E
I
took
a
look
at
the
thread
realized
that
there
was
quite
a
lot
of
discussion
remembered
that
I
had
completely
forgotten
the
context
on
this,
because
I
think
this
was
a
number
of
months
ago
that
it
was
last
in
a
working
group
meeting
and
thought
hey.
E
I
should
probably
read
that
before
I
make
a
decision
on
moving
it
to
stage
two,
but
in
the
in
the
in
the
light
of
what
I
just
previously
said
that
I'm
paying
close
attention
to
stage
two
tags,
I'm
going
to
do
that
because
it's
just
a
github
tag.
So
worst
case
scenario,
I
see
something
go.
Oh
oh
crap!
This
was
has
some
serious
issue
that
needs
it
to
be
revised,
but
I'm
going
to
go
ahead
and
do
that
because
I
believe
we
have
everything
here
that
we
need.
E
I
think
maybe
one
thing
that
I
might
need
your
help
with
yvonne
is
whether
the
deprecation
of
input
values
is
up
and
running
in
graphical
js.
Usually
we
look
for
that
before
moving
to
stage
two.
Yes,
it's
running
and
one
merchant.
O
Long
ago,
one
thing
I
need
to
check,
if
I
add
validation
rule
so
like
initial
pr
was
abandoned
by
its
laughter,
so
I
adopted
it
as
a
new
pro
on
on
the
space
repo,
and
I
need
to
check
that.
I
added
validation
rule
to
spark
text
about
forbidden
to
duplicate
required
fields.
O
We
had
like
a
bunch
of
discussion
about
withdrawal
and
I
need
to
check
if
I
edit
it
or
not
in
case
I
like
it's
like
small
with
it,
so
I
will.
I
will
do
it
tomorrow
or
not
to
walk
like
release
process,
because,
basically,
one
merchant
a
long
time
ago
and
the
only
negative
feedback
we
get
on
it.
It
was
because
people
misused
graphql,
js
and
because
they
didn't
use
typescript
for,
and
so
it
was
technical
problems.
There
is
no
like
real
big
issues
with
that
will
match
it.
O
O
E
Oh
sorry,
I
was
muted
yeah.
That
sounds
like
that's
the
piece
that
might
have
needed
some
editorial,
so
I
moved
this
to
stage
two
sounds
like
there's
a
little
bit
of
follow-up
that
we
might
need.
E
If
anyone's
taking
notes,
we've
moved
to
stage
two,
but
let's
open
a
new
action
item
to
make
sure
that
we've
done
the
follow-up
on
this
one
that
there's
everything
that
needs
to
be
done
for
this
is
done
close
book.
B
Okay,
so
close
close
this
one
and
open
a
new
one
to
just
check
that
it's
all
been
followed
up.
B
Okay,
so
next
would
be
550,
which
is
send
removal
notices
to
existing
graphql
js
contributors.
I
believe
we
discussed
this
last
month
and
we
said
if
it's
still
open
this
month,
we'll
do
it
the
fast
way.
O
D
E
We
can
always
add
people
back.
That's
this
is
the
my
pitch,
for
the
fast
way
is,
if
you
want
to
clean
up
the
committers
you
just
whatever
flesh
them
all
out,
and
if
someone
shows
up
later
and
says
hey,
why
can't
I
commit?
I
should
be
able
to
commit-
and
you
say,
welcome
back
and
you
add
them
right
back
in.
O
One
thing
we
need
to
be:
why
are
actually
stuck
on
that
because,
like
there
is
no
way
to
check
at
least
I
didn't
find
a
good
way
to
check
if
somebody
committed
into
organization
for
last
like
half
a
year
or
so
so
there
is
a
bunch
of
people
from
facebook,
some
of
them
like
never
committed
to
with
repo
to
this
organization,
but
some
of
them
actually
was
active
or
is
active.
D
E
I
don't
think
we
need
to
manually
check
each
person.
I
think
you
should
just
like
knock
them
all
out,
because
if
they
need
to
commit
they're
going
to
show
up
and
say
I
need
to
commit
and
the
moment
they
do,
that
easy
cla
is
going
to
hit
him
if
they
haven't
done
that
yet
and
then
like
you'll,
have
the
bot
do
it
for
you.
You
won't
have
to
manually
check.
O
E
You
know
if
you
want
to
do
this
in
two
passes.
You
can
do
a
first
pass
where
you
look
and
see
like
these
people
obviously
have
never
committed
anywhere
super
clean,
remove
other
ones
that
you're
not
sure
about
then
ping
me
or
ping
matt
and
were
happy
to
help
follow
up.
B
On
on
that
point,
it
seems
like
it
seems
to
me,
like
most
contributors
would
only
need
to
access
a
few
repositories
rather
than
all
of
the
repositories.
I
think
the
broader
access
is
is,
should
generally
be
restricted
so
lee.
Maybe
it
would
make
sense
for
you
to
to
whittle
that
that
list
down
quite
considerably
anyway.
E
I
will
do
that
yeah
if
it's
the
graphql
js
committers
list
specifically,
then
yvonne
I'll
leave
it
to
you
to
maintain
that
list
there.
I
think
there
is
still
a
handful
of
sets
that
have
broader
access
and
I
will
take
the
action
to
manage
those.
O
J
E
E
At
least
I
haven't
looked
at
graphical
yet
is
there
seven
and
matt
turn
on
two
factor
for
fgm.
E
I
think
there's
a
couple
old
school
or
relay
crew
in
here
that
probably
can
be
deleted.
So
I'll
just
go
ahead
and
do
that
now.
E
I'll
leave
them
I'll
leave
you
there
anyway,
just
in
case
you
know,
you
need
to
help
fix
something.
That's
why
you're.
P
B
Shall
we
move
on,
I
think
so,
awesome,
okay,
the
next
one
is
issue
586,
which
was
tasked
to
me.
This
was
to
ping
apollo
about
the
apollo
schema
store
regarding
potentially
doing
some
research
using
any
public
schemas
that
they
may
have
in
there.
James
pointed
me
on
to
talking
to
jesse,
about
that.
I
have
done
so
and
at
the
moment
apollo
don't
have
anything
in
place
that
would
enable
us
to
do
that
or
even
to
detect,
which
of
the
schemas
may
or
may
not
be
public.
B
It
is
something
that
he's
interested
in
assigning
as
like
a
like
a
passion
project
for
one
of
the
apollo
engineers
potentially,
but
we
can't
he
can't
commit
to
any
timeline
on
that.
So
as
regards
doing
research
for
the
the
project
that
this
was
proposed,
for
which
was
the
the
default
value,
coercion
rules,
it's
it's
a
no-go,
but
we
may
have
access
to
some
subset
of
that
in
future.
B
Potentially
I
mentioned
it
might
be
interesting,
for
example,
to
let
people
opt
into
allowing,
for
example,
the
graphql
foundation
to
use
your
schema
as
part
of
graphql
research,
and
I
think
that
would
be
a
really
cool
thing
for
apollo
to
be
able
to
to
offer
to
the
community
and
for
people
to
be
able
to
offer.
So
I
think
something
positive
might
come
out
of
it,
but
I
think
it
will
be
a
long
a
long
while
before
it
does
so
anywho.
I
think
that
this
can
be
closed,
cool.
B
I
am,
I
proposed
that
idea
to
jessie
apollo
and
he
pointed
out
that
you
could
use
that
to,
for
example,
you
could
de-anonymize
it.
If
you
have
a
collection
of
schemas,
you
can
see
which
one
ends
up
being
this
anonymized
schema,
and
then
you
could
potentially
use
that
to
discover
things
that
maybe
haven't
been
released
yet
that
they're,
adding
to
their
internal
schema
that
they've
not
published
yet
so
there
is,
there
is
still
risk
in
that.
Just
changing
names
may
not
be
sufficient
to
anonymize
when
the
structure
is
still
similar.
M
Terms
of
it
was
not
only
a
suggestion.
Even
graphical
java
offers
this
feature
already.
It's
a
traffic
java
has
an
anonymizer
which
takes
schema
and
the
query
and
returns
an
anonymized
schema
query.
So
yeah
it's
fairly
new,
but
it's
already
existing,
but
maybe
still
an
interesting
project
for
some
of
code.
M
The
interesting
part
for
me
would
be
like
not
just
to
make
it
a
internal
class
in
graphical
java
or
in
anywhere
else,
but
maybe
like
making
it
make
it
a
repo
and
something
you
can
submit
to
also
you
know
like
like
make
it
accessible
to
people
so
that
they
can
contribute
schemas
and
kind
of
help.
The
overall
ecosystem
by
just
saying
look.
This
is
what
we
did
it's
anonymized,
but
still
this
is
what
we
did.
Please
make
sure
it's
performed.
For
example,
we
sometimes
get
issues
for
whoa.
M
This
is
slow
and
then
okay,
your
query
is
ten
thousand
lines.
Long,
that's
not
a
joke.
By
the
way.
It's
it's
reality,
and
and
and
then
okay,
ten
thousand
lines,
that's
a
lot.
What
are
you
doing
and
we
can't
easily
reproduce
it
and
then
please
yeah.
M
This
is
where
the
idea
from
this
anonymizer
came
in
to
make
it
actually
possible
to
submit
people
per
request
and
source
correct
and
help
us
to
actually
fix
bugs
and
improve
performance
so
and
to
make
this
even
for
a
bigger
ecosystem
and
have
like
kind
of
a
repo
like
benji
pointed
out
for
schemas
would
be
absolutely.
B
Okay,
so
the
next
one
is
issue
587,
which
is
explaining
why
the
initial
count
behaves
as
it
does
I.e.
I
think
it's
a
required
parameter,
or
maybe
it's
not,
but
either
way
explaining
whether
it
is
or
not,
and
what
the
reason
for
that
is
that
was
originally
assigned
to
kuwait,
and
I
think
rob
has
gone
through
his
rob
thinks
it's
been
addressed
in
the
the
rfc.
B
E
Cool,
I
remember
the
context
on
this.
One
was
in
the
discussion.
We,
we
realized
that
none
of
us
really
understood
why
it
was
working.
The
way
it
did,
including
rob
and
so
rob
took
the
action
to
do
a
follow-up,
and
we
thought
qa,
who
was
sort
of
the
originator
of
this
particular
piece
of
the
api,
would
would
have
that
answer
and
then
I
think
I
think
he
probably
like
looked
back
in
his
notes
and
realized
that
he
had
just
missed
the
understanding
himself.
E
B
To
do
with
like
whether
it
acts
as
a
minimum
or
a
maximum,
I
think
something
lovely
okay.
Next
up
would
be
588,
which
is
to
make
the
initial
account
nullable.
As
we
discussed
last
session
and
rob
has
mentioned
that
he's
updated
the
spec
pull
request
and
the
graphql
js
branch
to
reflect
that
change.
B
That
sorry,
a
second
okay,
so
I
think
that's
it
for
the
issues
that
I
have
the
action
items
that
I've
actually
marked
as
ready
for
review,
where
people
have
told
me
that
this
is
done.
There
is
still
quite
a
lot
of
actions
remaining
from
the
last
meeting.
B
Yeah,
I
can
certainly
tell
you
that
I
haven't
made
any
progress
on
any
of
mine.
Would
anyone
else
like
to
close
any
of
their
actions
that
they
they
had
assigned
to
them?
B
You
if
you've
got
the
live,
notes
open,
there's
a
there's,
a
nice
summary
of
some
of
them
there
mark
is
not
on
the
call
ivan
you
had
one
about
reviewing
the
rfc
to
assert
a
subscription
field
is
not
introspection,
but
I
don't
think
you've
done
that,
because
that's
also
one
that
I
raised
so
no
never
mind
lee
won
on
an
editorial
review
of
the
no
introspection
of
the
subscription
rfc.
E
I
have
not
finished
that
yet,
but
that
one
is
actually
pretty
high
on
my
list
because
that's
part
of
finalizing
the
spec
cut
so
that
one
should
be
done
by
next
meeting.
E
Okay
and
same
for
my
other
one
from
last
meeting
is
on
my
short
list
and
sorry
I
didn't
get
to
that
before
this
meeting,
especially
you
andy,
since
I
knew
you
were
the
one
who
proposed
this
one,
but
this
one's
also
on
my
shortlist
so
I'll
get
to
this
before
next
meeting.
So
our
next
batch
is
scheduled
at
new
times.
B
We
also
have
an
a
couple
of
everyone
issues:
everyone
to
review
the
defer
and
stream
specs.
So
please,
if
you
haven't
already,
please
go
and
do
that.
B
The
other
thing
was
if
people
are
using
default,
values
that
are
input,
objects
or
if
they
have
input,
objects
that
have
default
values
on
their
fields
or
if
they
have
both
of
those
things.
We'd
very
much
like
to
hear
from
you
please
reach
out
and
say
that
you're
using
one
or
both
of
these
features,
we
would
like
to
collect
more
data
on
this.
So
it'd
be
very
helpful.
B
If
you
could,
there
has
been
one
person,
I
I'm
sorry,
I
forget
who
it
was,
but
one
person
has
replied
to
that
already,
but
it
would
be
great
to
get
more
data
on
that
front.
O
E
I'm
just
going
to
go
ahead
and
close
this.
This
was
from.
This
is
a
pretty
old
issue
and
it
was
before
we
had
figured
out
the
lf
and
jdf
legal
processes,
and
so
the
information
here
is
pretty
out
of
date.
So
I'll
just
drop
a
note
here
that
we
are
in
the
final
phases
and
expect
it
to
be
released
in
the
next
like
45
days.
I
think,
is
a
reasonable
goal
from
now,
since
it's
30
days
until
that
jdf
paperwork
takes
effect.
B
On
that
subject,
there's
a
really
old
issue
from
2019
about
updating,
clas
and
copyright
notices
in
graphql
repos,
which
I
assume
has
been
dealt
with
by
now.
That
is
issue
number
291
I'll
paste
it
into
the
chat
was
time.
I
checked.
O
It
wasn't-
and
I
spoke
with
brian
about
that
so
brian
said:
technically
we
can
change
copyrights
and
other
stuff,
but
it's
better
if
it's
done
by
facebook
engineers.
E
H
E
Let
me
take
this
one
as
an
action
item
and
if
whoever's
taking
notes,
can
just
drop
a
link
to
this
in
that
action
item,
so
we
know
to
follow
up
with
it.
I
think
I
got
the
live.
Graphql
parser.
A
One
yeah,
so
that's
why
it's
crossed
out.
You
opened
that,
like
two
years
ago
or
whatever,
and
you
did
do
it
lee
you
fixed
it
years
ago.
The
remaining
thing
was
the
cla.
There
wasn't
at
the
time
anywhere
to
point
to
a
graphql
foundation
c
like
and
the
so
the
language
wasn't
a
problem,
but
they're
just
I
think
everybody
agreed
that
language
was
fine.
We
just
needed
one
that
wasn't
facebook.
E
Yep
yeah
the
leave
this
action
item
on
me
and
brian
we're
just
we'll
just
do
an
audit
we're
going
to
comb
through
everything
in
that
name,
space,
repo
by
repo
and
just
got
checked
that
we
haven't
missed
anything.
I
believe
I
did
that
last
time.
This
issue
is
passed
and
I'm
I'm
sure
I
missed
something
so
because
I
think
I've
heard
reports
of
it
in
the
last
couple
of
months
as
well
that
there's
still
some
places
that
we
haven't
caught.
A
So
that
in
the
old
issue,
the
like
sorry
for
the
throat
and
the
the
one
you
crossed
out
is
done,
but
the
I
don't
know
is
there
a
cla
now
that
can
be
pointed
to.
I
think
that
part
was
remaining.
E
The
data
loader
one
that's
also
linked
is
is
also
fixed.
I
just
clicked
through
to
that
one,
and
it
says
project's
code
of
content
is
described
in
graphql,
foundations,
go
to
contact
md
and
that
one
links
to
the
right
place.
A
E
It
has
a
link,
but
it's
like
not
a
good
one.
It
says
see
the
code
of
contact
featured
in
and
then
it
just
links
you
to
the
folder,
which
is
like
not
terrible
because
you
click
there
and
then
you
see
another
link
there
that
says
code
of
conduct,
but
it
would
be
nicer
filling
straight
to
it.
So
let
me
take
that
as
part
of
that
follow-up
action
item
just
to
I'll
just
get
the
same
template
for
code
of
conduct,
links
and
just
make
sure
it's
applied
to
every
single
repo.
A
A
B
Well,
did
the
whoever
did
the
notes
for
this
section
like
good
job,
really
good
notes.
H
E
They're
all
various
anonymous
animals,
so
I
don't
know.
E
Oh
welcome
ella,
you
we
missed
you
in
the
intros
at
the
beginning.
R
B
E
It
amazing,
okay,
folks,
let's
wrap
up
thanks
for
all
your
hard
work
if
things
pop
up
between
now
and
next,
that
need
attention,
please
leverage
slack
otherwise,
thanks
everybody
for
your
attention,
work
and
great
contribution
to
the
discussion
so
far
see
you
next
time
thanks.
Everyone.