►
From YouTube: GraphQL Working Group - November 7, 2019
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
Everybody
looks
like
we
are
getting
really
close
to
quorum,
so
we
will
get
started
in
just
a
second
just
so
everyone
here
is
aware.
I
finally
got
call
recording
working
so
I'm
recording
this
meeting
and
I'll
actually
get
it
posted
up
onto
the
agenda
after
the
meeting
took
me
long
enough
to
figure
it
out.
A
Got
a
pretty
packed
agenda,
lots
of
good
stuff
to
talk
about
today,
but
as
we
always
do,
let's
start
by
doing
a
quick
introductions.
Just
we
can
put
names
to
faces.
I
did
sort
our
attendee
list,
so
we
should
be
able
to
just
lock
down
the
order
in
the
attendee
list.
So
I'll
start,
hey
everybody,
I'm,
Lee
and
I
will
help
lead.
This
meeting.
B
M
K
N
A
Welcome
she.
L
O
P
Q
A
Great,
do
you
have
everybody
for
those
of
you
who
weren't
on
the
list?
Yet
please
and
pull
requests
just
so
we
can
have
an
accurate
record
of
everyone
that
was
here.
I
seems
like
we
have
a
handful
of
people,
volunteering
to
help,
take
notes,
Bruno,
Benji,
Allen
and
Steven.
You
guys
all
feeling
comfortable
hashing
it
out
on
that
dock,
together,
yeah
yeah.
P
A
It
you
guys
are
awesome,
I
feel
like
we
used
to
have
to
beg
and
plead
people
to
take
notes,
and
our
notes
have
been
super
high-quality
over
the
last
few
meetings.
So
super
appreciate
it:
okay,
let's
take
a
look
at
our
agenda
for
the
day
and
make
sure
that
we're
covering
everything
that
you
all
want
to
talk
about,
so
we're
gonna
be
talking
about
some
upcoming
meetings
and
a
shift
to
the
agenda
format.
A
Okay,
first
agenda
Adam
is
mine,
so
yesterday,
I
went
through
and
added
a
handful
of
new
things.
I
added
our
next
upcoming
meetings
for
2020
I
added
the
January
meeting
and
the
February
meeting
I
also
changed
the
format
of
these
agenda
documents.
A
little
bit
I
added
a
link
here.
I,
don't
have
to
go
through
that
too
depths
to
in-depth
with
you
all
today,
but
I
went
ahead
and
updated
the
December
1
to
the
new
format
as
well.
Really
what
it
does
is
it
tries
to
capture
it.
Takes
this
chunk.
A
That's
the
guidelines,
that's
at
the
top
of
these
agenda
files
and
moves
them
in
line
into
the
attendees
section
in
the
agenda
section
and
I've
updated
those
guidelines
to
include
stuff
that
we
keep
saying
that
we
want
to
add
to
every
meeting
and
I've
made
it
part
of
this
document.
So
I've
made
it
a
little
easier
to
mark
that
you're
willing
to
take
notes.
Cuz
the
asterisks
is
probably
a
bad
idea
and
markdown
people
accidentally
bolded
the
whole
file.
A
A
couple
of
times
made
sure
that
people
include
their
country
code
made
sure
and
agenda
that
we
I
actually
have
an
example
now
in
that
agenda
and
asked
people
for
relevant
links
which
we've
been
getting
better
at
and
then
also
to
make
sure
that
there's
always
a
name
for
an
owner
on
each
agenda
item.
So
I
mostly
went
through
this
by
myself
yesterday.
A
You
can
add
it
to
your
google
calendar
I,
also
post
it
on
all
the
new
agendas
going
forward,
both
in
the
Google
Calendar
format
and
in
the
iCal
format.
If
you
don't
use
Google
Calendar,
but
you
use
Outlook
or
anything
else
that
accepts
iCal.
Hopefully
this
is
a
good
way
to
make
sure
that
people
don't
have
to
manually.
Add
this
on
to
their
calendar.
I
made
sure
that
they
have
links
back
to
the
irrelevant
agenda
for
each
meeting
and
set
them
up.
A
F
A
A
D
D
A
Because
I
know
a
lot
of
people
work
on
multiple
projects
but
yeah.
The
idea
is
that
if
there's
one
particular
thing
that
is
most
identifying
for
you
so
give
on
usually
mentions
that
he's
on
the
graphical
jst
I
supposed
to
benching
a
particular
organization
I
do
the
same.
I
mentioned
that
I'm
representing
Rahil
foundation,
rather
than
Robin
Hood,
where
I
work,
but
I
can
certainly
make
that
language
more
clear
as
well.
It's
a
great
point.
G
Hi
I'm
sorry
to
bring
up
this
boring
non-technical
issue,
but
we
basically
we
want
to
contribute
to
lip
graphical
passer
and
which
is
the
C++
parts
of
a
graph
QL
and
it
used
to
have
a
Facebook
hosted
CLA
so,
and
our
legal
team
basically
advised
us
that
this
was
an
issue
and
we
couldn't
contribute
before
that
was
resolved.
So
Li
just
changed
this
and
he
basically
updated.
G
First
of
all,
all
the
copyrights
in
the
project
which
still
said
Facebook
and
he
basically
removed
the
reference
to
the
CLA
and
I,
opened
an
issue
about
this
in
in
in
the
repository
of
the
working
group,
I
just
posted
the
link
in
the
chat
here
and
I
I
actually
went
through
all
the
repositories
under
the
foundation
and
saw
that
another
one,
namely
the
data.
Loader
one
has
the
same
issue.
G
It
basically
also
points
to
a
Facebook
hosted
CLA,
and
so
maybe
we
want
to
change
that
as
well,
and
I
was
actually
now
that
the
CLA
is
gone.
I
was
actually
now
asked
to
see
if
there's
a
possibility
to
get
a
CLA
back
and
if
so,
if
it
could
be
hosted
either
by
the
graphical
foundation,
or
maybe
this
isn't
even
an
easier
way
where
we
would
just
have
like
a
CLA
dot
txt
or
something
and
reference
it
from
the
contributing
file.
A
Yeah
I'm
glad
that
you
did
this
is
something
we've
been
talking
about.
Doing,
I,
actually
really
liked
the
tool
that
Facebook
had
set
up
for
this,
where
there's
just
a
web
form
that
you
could
punch
in
your
name
and
it
associated
to
your
github
account
and
like
once,
you
had
sent
one
poor
request
up.
They
knew
for
sure
that
you
were
safe
too
you're
doing
that.
That
was
really
helpful.
I,
don't
know
if
the
Linux
Foundation
has
a
tool
that
does
this,
but
that's
certainly
something
that
we
can
ask
about.
R
A
R
G
R
G
We
already
checked
the
CLA
text
and
the
text
that
was
provided
in
the
existing
CLA
from
Facebook
was
was
fine
like
they.
They
agree
with
it,
but
they
didn't
like
that.
It's
hosted
by
Facebook,
basically
because
it
implied
some
of
that
contributions.
You
know
what
go
to
Facebook
or
something
like
that:
I'm,
not
a
legal
expert,
I'm,
sorry,
but
maybe
there's
a
is
there
to
do
all
of
this,
where
maybe
we
have
a
follow
up,
call
brine
on
this
yeah.
A
A
Can
help
with
I'm
happy
to
join
on
that
as
well?
If
it's,
if
it's
useful
or
also
happy
to
just
hear
whatever
report
comes
back,
there's
I
think
there's
an
they're
open
question
that
we
were
asking
but
never
fully
solved
when
we
were
first
setting
the
foundation
up
is
whether
we
needed
a
structure,
a
legal
structure
based
around
textual
contributions
to
a
specification
document
or
a
legal
structure
around
in
an
open-source
technical
body.
That's
hosts
technical
projects.
A
The
my
understanding
is
that
the
the
legal
stature
is
different
in
both
the
like
stuff
that
you
set
up
in
the
clas.
It's
different
in
both.
Presumably
everybody
in
this
meeting
has
has
signed
that,
because
it's
requirement
to
attend
these
working
group
sessions
is
to
send
that
membership
agreement
signed
that
membership
agreement.
A
We
should
make
sure
that
that
membership
agreement
covers
everything
that
at
least
the
IBM
lawyers
are
concerned
about
by
the
way,
if
there's
anybody
on
the
call
who's
who's.
Thinking
like
oh
I,
wonder
if
my
lawyers
are
all
so
freaked
out
about
similar
kinds
of
things
reach
out
to
me
or
to
Brian,
and
we
can
also
kind
of
set
up
a
similar
call.
A
G
Yeah,
this
is
great
I'll
follow
up
issue,
I'm,
not
sure.
If
it's
worth
discussing
in
too
much
detail
but
Li,
you
actually
filed
an
issue
and
I'm
gonna
post
a
link
once
more
in
the
chat,
hear
that
in
lip
graph
QL
pass
across
it's
a
statically
typed
thing:
you
know
in
C++
you
have
a
name
space
and
the
name.
Space
currently
also
mentions
Facebook,
and
you
brought
up
the
question
whether
that
should
change.
G
A
That's
why
I
opened
the
issue
there
I
wanted
to
make
sure
that
there's
discussion,
I
kind
of
based
on
our
previous
conversations
weaved
through
that
project,
to
just
look
for
any
references
to
Facebook
to
see
which
ones
are
reasonable
and
which
ones
needed
to
be
replaced
and
I
saw
the
name
space
one
there
and
thought
like
it's.
Probably
fine,
because
there's
no
concern
about
having
that
name
space
there
a
little
bit
we're
a
facebook
project
anymore,
that
the
names
Jace's
facebook.
But
I
didn't
want
to
go
breaking
anybody
who
depended
on
that
project.
A
So
I
don't
know
Eric.
If
you
can
sort
of
lead
answering
that
question
since
you've
taken
an
interest
in
contributing
there.
I
can
also
kind
of
drum
up.
If
there's
anybody
at
Facebook
who
cares,
but
hopefully
it's
a
relatively
easy
change
or
an
easy,
easy
fix.
If
we
make
a
major
update
like
what
should
the
new
namespace
beat,
you
just
delete
that
anyway,
we'll
figure
that,
on
that
issue,
yeah.
G
I
agree-
and
it's
just
I
just
wanted-
also
to
bring
it
up.
So
if
anybody
has
an
opinion
or
forms
an
opinion
in
the
next
days,
then
obviously
feel
free
to
and
post
comments
to
that
issue.
I
think
that's
it
from
my
site
about
all
of
this
I
would
be
happy
to
have
a
follow
up
with
Brian,
at
least,
maybe
also
with
me.
A
Sounds
great
another
action
item
for
me
out
of
this
is
I,
am
gonna
comb
through
all
the
other
three
goes
in
our
github
org
and
do
the
same
thing
that
I
did
for
live
graphical,
parser,
just
search
for
all
references
to
Facebook
make
sure
that
they're
just
topical.
You
know
they're
explaining
the
history
of
the
project
rather
than
something
legal
or
copyright
based.
That's
no
longer
accurate.
A
Sorry,
it
took
me
forever
to
do
that.
That's
probably
something
I
should
have
done
six
months
ago,
but
better
better
late
than
never
and
I'll
make
sure
that
everything
is
updated
appropriately,
especially
for
the
projects
that
are
more
evergreen.
That
there's
not
like
a
lot
of
active
mean
it's
like
data
loader
is
the
prime
example
of
that.
Making
sure
that
that's
all
updated
should
be
worthwhile
quote.
A
S
S
Okay,
good
so
I
think
the
I
just
want
to
touch
briefly
on
the
whole,
like
interfaces
implementing
interfaces,
I'm
I'm
now
calling
it
intermediate
interfaces
because
that's
what
it
enables
and
it's
a
little
bit
less
of
a
mouthful.
It's
been
merged
into
graphical
ljs,
I
talked
with
James
briefly,
I
know
that
was
an
action
item
from
a
couple
months
ago
that
just
he
had
some
concerns,
but
I
think
we
we
no
longer
have
any
concerns
there.
S
In
particular,
I
got
a
blog
post,
ready
and
I
actually
saw
the
and
II
published
one
that
was
similar,
which
is
awesome.
I
wanted
to
just
link
that
here,
I
didn't
want
to
put
too
much
pressure
on
Avon
to
get
version
15
out
so
I
figured.
You
know,
I
think
it's
pretty
close
to
a
feature
lock
here,
so
maybe
it's
close
to
I
could
just
go
ahead
and
publish
it.
I
just
wanted
to
give
everyone
here
a
last
like
kind
of
chance
to
express
concerns
before
you
know
too
many
people's
expectations
change
so
yeah.
A
F
F
Last
week
up
like
it's
going
to
yes
and
back
I
saw
basically,
we
was
totally
booked
in
development,
but
return
back
and
I
want
to
continue
to
start
actual
technical
conversion
and
Micah
Nasser's
want
to
help
and
like
we
actually
worked
with
everything.
So
if
we
saw
all
intermediate
issue
and
everything
in
pipeline
so
kind
of
its
feature
phrase,
but
we
need
to
do
subscript
conversions
fast
as
possible
and
release
15
0
is.
S
F
Like
we
promised
to
have
after
1400
after
we
became
stable,
the
promise
havoc,
stable
release,
and
so
so
like
it,
I
thought
it
was
wasteful.
Just
have
a
really
specific
that
script
conversion,
because
there
was
like
things
that
really
duplicated
and
other
stuff.
So
actually
what
I
had
and
Kido
Kido
with
stuff
that
involve
a
duplication,
removing
and
point
for
breaking
changes,
release
alpha
0,
so
people
can
try
and
get
feedback
as
I
think
I
release
it
to
a
couple
ways:
go
over
I
think
I
release
it
after
merchant
Europe
er.
F
So
your
PR
is
actually
like
some
people,
probably
using
it
I,
don't
think
quite
so.
Most
of
users
switch
to
alpha
0,
but
I
ask
wake
up
or
another
one
just
to
try
it
out
to
see
if
it
breaking
something
for
them
or
not.
So
everybody
like
right
now
if
somebody
wants
to
try
with
intermediate
interface
by
the
way
I
like
the
new
name.
It's
like
really
this
whole
confusion.
So
if
you
anybody
wants.
Q
F
Like
I
need
to
do
some
preparation,
work
with
mainly
set
up
with
clinchers
I
stood
up
with
building
process
and
when
I
was
like
actually
accept
from
anybody
who
wants
to
cream
and
I.
Think
I
could
try
to
push
it
as
fast
as
possible,
because
I
understand
it's
partly
working
release
process
for
future
surgeries
like
rough
kid
2020,
because
it
would
be
great
to
have
everything
worse
than
Hawaii,
landfill
or
Cho
for
people
to
try
and
before
like
make
it
official
yeah.
S
S
A
Is
I
I
wanted
to
make
sure
that
when
you
do
publish
this,
that
people
can
can
actually
check
out
graphical
GS
and
play
with
this
thing
that
you're
talking
about
so
it
makes
sense
as
like
you
know,
the
graphical
Jay
house
comes
out,
and
then
this
blog
post
comes
out
right
alongside
it
and
they
say,
like
hey
this
new
version
of
graphical
jeaious
was
released.
This
is
one
of
the
big
new
features
in
it.
Here's
more
information
about
it,
yeah.
S
F
Actually,
he
cut
the
like
one
of
the
thing
we
need
to
do
breaking
changes
after
New
Year
anyway,
because
we
need
to
drop
no
date.
He
become
extremely
the
summer
yet
to
support
yeah
it
become
extremely
painful
to
support
like
old
know,
the
Russians.
It
was
like
the
dependencies,
stop
supporting
it
so
wait.
We
cannot
do
continuous
integration
so
Basin,
yes,
so
I
think
actually
yeah,
probably
right.
F
I
think
like
we
can
release
fifteen
and
we
can
wait
as
you
wanted
to
do
the
least
candidate
and
havoc
and
like
ask
one
more
time,
everybody
to
try
it
locally.
I
crave
a
team
apology
positives
and
get
it
back,
because
I
make
headway
around
them
breaking
changes.
Most
of
them
are
small.
Nothing
like
major
awake,
most
mostly
corner
cases,
the
stuff
that
we
wanted
to
duplicate
anyway,
and
we
was
explicitly
Marquis
a
but
I
think
right.
A
A
Absolutely
and
I'm
glad
that
you
got
to
hash
out
any
remaining
concerns
with
the
Apollo
tools.
Folks,
as
well,
that's
a
really
strong
sign.
It
seems
like
the
last
action
item
which
is
on
me,
for
this
is
to
do
a
final
review
of
your
spec
text
or
which
should
be
the
only
thing,
that's
keeping
this
from
going
to
RFC
three
great
awesome.
A
K
Earnest
not
not
well-suited
to
that
purpose,
but
it
also
will
serve
as
a
key
for
tooling
like
graphical
to
be
able
to
treat
as
kind
of
an
opaque
identifier
of
what
additional
features
can
I
provide
around
the
scalar.
So
if
you
know
we
consolidate
the
ecosystem
around
a
particular
eight-time
scalar
URL,
then
graphical
can
see
that
URL
in
the
definition
of
you
know
some
arbitrary
schema
and
say:
oh
I
can
treat
this
as
a
big-time.
K
K
We
don't
have
a
waiver,
we
know
right
now
on
what's
the
best
framework
for
actually
putting
the
URL
into
the
SDL.
You
know,
like
definition,
and
also
there's
the
question
of
how
do
we
define
what
the
URL
is
in
the
schema?
Do
we
import
the
entire
grammar
from
RFC
39.86
into
our
grammar,
which
would
be
a
huge
chunk
of
extra
like
patterns?
Do
we
just
reference
able
to
the
other
RFC?
K
K
F
D
In
a
way,
that
would
be
basically
like
extending
the
description,
because
that's
basically
what
is
efficacious
as
a
very
long
description,
yeah.
B
But
this
is
a
specific
field
like
it
was,
would
be
a
you
I
feel
that
it's
just
uses
it
as
a
link.
So
you
could
do
a
machine
interpretation
like
you
could
match
for
the
string
and
know
that
it's
a
you
are
that
it's
a
daytime
for
instance,
so
because
you
have
description
at
the
moment,
but
description
is
not
easily
possible
because
there
could
be
anything
in
it.
So
it
should
be
a
specific
field.
Or
what
was
the
idea
that
even
you
yeah.
Q
Maybe,
to
give
a
little
background
on
the
two
goats
we
wanted
to
achieve.
This,
like
like
I,
started
as
discussion
specifically
around
a
time
a
couple
of
months
ago,
and
this
was
kind
of
combined
with
the
idea
of
having
a
general
way
of
specifying
scalar
implementations.
So
datum
is
a
great
example,
for
example,
is
a
great
example
for
a
scalar
which
kind
of
needs
a
detailed
description,
and
it
should
also
be
possible
by
towards
or
identifiable
by
towards
that
the
scalar
implements
a
specific
thing.
Q
Do
you
extend
scalars,
where
you
just
specify
them
and
then
every
like
the
craft
wear
foundation,
or
this
graphical
working
group
could
specify
another
scalar
for
your
L,
for
example,
and
put
out
a
spec
and
and
say
the
recommended.
Scalar
name
focuses,
may
be
URL
and
then
every
server
is
able
to
say
are
there's
your
error
scalar,
and
this
actually
implements
the
official
URL
pattern,
but
it
doesn't
have
to
like,
if
you
have
a
legacy
system
which
implements
your
L
in
a
slightly
different
way.
Q
Well,
then,
put
up
your
own
proprietary
or
like
different
spec,
or
maybe
even
leave
the
specification
URL
out
of
it.
If
you
don't
care,
so
it's
it
offers
a
way
of
being
consistent
across
the
ecosystem,
but
nobody
is
forced
into
the
pranking
change.
I
was
forced
into
implementing
data
and
really
in
this
specific
way,
you
are
like,
maybe
encourage,
but
you
don't
have
to.
F
F
Q
Like
I
think,
my
initial
reaction
would
be
like
the
reason
is
to
keep
it
focused
like
the
the
question
would
be
like
what
is
the
URL
of
a
type
like?
What
do
you
specify
behind
the
type
system
right?
Does
the
problem
with
the
scalar
is
there's
nothing
in
the
SDL
which
says
what
the
scale
is.
This
is
well,
your
L
comes
into
play,
but
the
type
actually
has
a
description
insert
est
air.
So
it's
an
interesting
idea
and
yeah.
B
But
the
type
and
the
scale
are
actually
no
different
than
the
introspection,
so
you
also
have
on
the
scaler.
You
can
have
a
description
in
the
introspection
it
does.
It
doesn't
really
matter.
So,
if
we
add
just
a
speck,
you
out
types,
you
just
be
able
to
put
to
any
type
some
kind
of
a
specification
document.
I
don't
see
the
problem
there,
so
it
would
bring
us
where
we
actually
want
to
have
a
spec
document
for
a
scalar
and
we
can
use
it
in
a
machine
readable
way.
B
K
So
like
there's
the
fields
field,
we
could
only
for
objects
and
interfaces
and
there's
the
values
of
vehicles
will
just
really
only
14
ohms
and
that
sort
of
thing
it
wasn't.
If
we
want
to
start
making
types
more
generally,
it
doesn't.
It
feels
a
bit
weird
to
start
with
spec
you,
alright,
that's
it
I
use,
don't
understand
the.
B
Uk's
yeah,
but
the
under
underscore
type
they're,
actually
type
which
mean
patient
of
the
type.
That's
just
an
object,
art
and
it
has
either
fields,
but
they
just
can
be
none
able,
but
the
type
always
has
fields
you
can
select
on
them.
So
it's
not
a
union
even
for
scalar.
It
has
this
property
right.
A
I'll
speak
to
this
a
little
bit.
We
could
have
made
this
a
union
and
actually
not
about
Nick's
rock
talked
me
out
of
it.
He
said
it
would
be
way
too
confusing
for
the
first
thing
that
you
encounter
with
introspection
to
be
a
union,
and
he
convinced
me
just
to
make
a
much
simpler,
flattened
type.
The
trade-off
on
that
is
that
there's
language
in
the
spec
on
each
type.
A
That's
where
it
describes
introspection
that
it
describes
only
the
set
of
fields
where
you
see
what
to
expect
and
then
there's
always
the
last
bullets,
as
all
other
fields
must
return
null.
So
that
was
put
in
place
to
protect
against
exactly
the
kind
of
thing
that
we're
talking
about
now,
where,
if
we
added
a
field
to
any
one
of
these
types,
we
we
would
not
be
in
a
position
of
trying
to
figure
out
how
to
interpret
it
for
some
other
kind
of
type
that
we
didn't
anticipate.
A
So,
in
this
case,
I
kind
of
I
agree
that
it's
the
right
thing
to
start
small
and
not
worried
too
much
about
like
what
does
it
mean
to
have
a
specification
for
a
union
or
for
a
object,
type
or
an
interface
which
otherwise
already
have
pretty
good
specification
rules
where
scalars
have
very
few.
And
so
we
can
just
only
add
this
to
the
scalar
for
now
and
then
that
last
rule
for
all
the
other
kinds
of
types
will
apply
and
will
require
it
to
be
null.
D
D
F
Think
I'm
actually
way
consider
my
previous
point.
Actually
Finkley
and
ng
is
right.
We
should
not
like
features
required
for
us.
The
features
that
we
right
didn't
discuss
and
like
every
fish
should
be
atomic.
So,
if
like
with
clear
defined
problem,
so
we
agree
actually
I
was
kind
of
doing
so.
If
we
solving
the
problem
for
research
is
daytime
scour
and
we
found
solution
for
daytime
scour
well,
we
should
restrict
ourself
to
so
in
this
problem.
F
F
Yeah
we
design
its,
so
it
may
be
huge.
It
would
be
possible
to
edit
types.
It's
like
it's
not
hard
requirements
just
requirement,
so
I
don't
see
anything
quick
in
current
opposes
it
prevents
it
so
yeah
I
agree
with
what
start
from
scour
see
see
how
how
to
adopt
the
dot,
and
if
we
will,
you
need
miss
Mannis
whole
other
proposals,
like
extension
inside
the
prescription
and
other
things.
B
And
I
think
that
is
what
type
is
actually
the
specification
you
know.
Is
it
the
string?
We
say
this
appearance
in
ul,
but
it's
a
string
or
do
we
introduce
the
new
scalar
like
in
your
I
type?
Nothing
from
my
point
of
view.
We
should
use
the
string
because
it
keeps
the
scalar
set
smaller
and
easier
yeah.
K
I
think
I'm
pretty
convinced
that
also
that
we
should
use
string
for
the
introspection
response.
My
bigger
concern
was
the
actual
SDL
grammar,
because
that
is
them
really
yeah
that
feels
a
little
blonder
specified.
If
we
just
say
it's
a
string
and
not
like
polluting
the
graft.
Well,
the
only
thing
that
pollutes
if
we
imported
URL
grammar
into
that
is
the
graph
QL
grammar
itself,
which
is
yeah
I,
don't
I,
don't
know
how
I
feel
about
that.
I.
A
Posted
a
comment
on
your
on
your
RFC,
with
some
like
detailed
out
feedback,
but
one
idea
for
this
for
the
SDL
grammar
is
rather
than
adding
this
to
the
grammar
itself
is
to
use
a
directive,
so
in
the
same
way
that
when
we
want
to
deprecate
a
field,
we
use
a
deprecated
directive
to
do
that,
rather
than
something
that's
specific
in
the
grammar.
I
think
this
is
a
small
enough
thing
that
it
makes
sense
to
use
a
directive
instead.
A
The
nice
thing
about
that
is
that
when
you
read
a
scalar,
you
can
see
something
that
explicitly
tells
you
like
why.
Why
you're
seeing
a
URL
here
right
now,
which
will
be
nice?
It
means
that
the
grammar
change
won't
be
breaking,
which
should
also
make
it
easier
to
adopt
this,
and
then
really
all
we
have
to
do
is
is
spec.
A
D
A
A
We
don't
want
to
make
a
decision
without
knowing
for
sure
that
you're
solving
a
specific
problem,
because
you're
we're
almost
always
bad
at
predicting
the
future
and
people
end
up
using
something
in
a
way
that
we
didn't
anticipate
or
finding
out
that
it
actually
makes
it
harder
to
solve
the
problem
that
you
wanted
to
solve
that
pops
up
in
the
future.
That's
usually
the
reason
why
we
want
to
start
small
and
then
expand
outwards
so
say,
like
start
with
language.
A
That
says,
you're
only
allowed
to
use
this
on
scalars
and
then,
if
you
know
next
month,
we
realize
like
oh
actually,
this
would
be
incredibly
valuable
for
unions.
Then
we
expand
it
to
say
that
you
can
use
it
there
as
well
or
maybe
even
expand
it
to
all
types.
If
we
find
out
that
that's
particularly
useful
I
think
I
would
only
support
making
this
more
broadly
applicable
if
there
was
concrete
use
cases
for
why
you
would
want
to
put
this
on
types
of
and
scalars
so
far.
Q
B
B
Describe
higher
lever
types
like
the
first
case
that
came
into
my
mind,
was
basically
they
read
a
paging
and
I
found.
I
would
find
that
very
cool
because
then
I
don't
have
to
like.
We
are
building
a
client
generator
at
the
moment,
and
now
we
are
doing
Bezier
matching
name's
is
attending
misconnection
and
I
would
I
would
find
that
useful
for
that
cases,
what
I.
A
Definitely
hear
that
I
I
do
agree
with
Andy
that
it
does
make
sense
to
keep
this
focused
for
now.
I
would
love
it.
The
reason
why
it
makes
me
a
little
bit
nervous
is
I
want
to
make
sure
that
we
we
make
sure
that
we
have
an
order
of
starting
with
problems
and
then
working
towards
a
set
of
solutions
to
investigate
that
solved.
That
particular
problem
rather
than
finding
a
solution
and
then
finding
all
the
potential
problems
we
can
solve
with
that
solution.
A
I
found
problems
down
the
line
of
that
approach,
and
it's
really
easy
to
look
at,
especially
when
we're
looking
at
proposals
like
this
that
are
designed
to
solve
one
particular
problem.
You
go.
Oh
wow,
look
at
all
these
other
problems
that
we
might
be
able
to
solve
with
it
as
well
and
I.
Just
I
just
want
to
be
particularly
careful
as
we
dive
into
that,
not
saying
that
it
it's
a
bad
idea
or
that
it
won't
work
and
might
actually
be
the
case
that
this
is
the
right
thing
for
that.
A
But
I
would
love
to
have
a
sort
of
a
separate
discussion
and
a
separate
RFC
that
investigates.
How
can
we
have
tools
better,
be
able
to
identify
things
like
the
really
pagination
model
or
other
pagination
models?
And
if
this
and
if
it
arrives
on
exactly
the
same
solution,
then
beautiful
and
if
it
arrives
on
a
different
solution,
then
that
might
be
better.
I
Would
be
useful
as
part
of
the
sort
of
see
to
document
some
of
these
use
cases
like
pagination
that
we're
thinking
of
and
so
then
you
know
if,
if
there
are
some
that
clearly
fall
within
scope,
then
that's
great,
but
also
it
gives
us
a
place
to
say.
Yes,
we
thought
about
this
and
we
decided
that
this
is
out
of
scope
for,
for
this
particular
feature,
certainly.
B
K
A
K
I,
don't
think
so.
I
was
gonna,
ask
for
a
review
of
the
spec
edits,
I'm,
not
super
familiar.
Oh
yes,
there
is
one
other
thing
that
was
that
was
it
Andy
hasn't
kindly
written
a
short
version
of
what
would
be
like
the
first
spec
to
use
this
new
feature,
which
would
be
like
a
date
time
spec
and
that
needs
to
live
somewhere,
which
should
probably
be
separate
from
like
this
RFC
sort
of
technically
and
tech,
separate
from
the
graph
QL
spec
itself,
but
also
I.
Imagine
would
still
live
on
graphical
that
works
somewhere.
A
This
is
gonna,
be
a
really
interesting
discussion
that
lines
up
really
well
with
the
graphical
at
HTTP
topic.
That
kind
of
you
know
come
on
wants
to
talk
about
later.
Okay,
I
have
a
couple
of
thoughts
on
this
first
I
totally
agree.
We
need
to
have
a
space
where,
where
the
graphical
organ
pooling
and
website
and
everything
can
scale
up
to
support
more
than
just
one
spec,
because
it's
clear
that
we're
going
to
need
more
than
just
one,
the
other
thought
is
not
every
spec
needs
to
be
a
graphical,
Foundation,
official
spec.
A
In
fact,
part
of
what
I
really
love
about.
This
particular
proposal
of
the
specification
URL
for
scalars
is
that
anyone
could
come
up
with
whatever
one
that
they
want
and
they
hope
they
can
host
it
themselves
right,
so
that,
if
you
know
the
the
Shopify
API
has
its
own
very
custom
version
of
what
date-time
means
there
can
literally
be
you
know:
API
dot,
shop,
Viacom,
slash,
specs,
slash
daytime
and
that
like
details,
it
out,
and
then
that
can
be
the
thing,
that's
the
permanent
URI.
That's
awesome,
I
think
that's!
A
That's
the
real
superpower
behind
this
particular
proposal,
but
if
there
is
sort
of
consensus
around
like
hey,
if
you
want
to
like
use
the
same
one
that
everyone
else
in
the
community
uses,
here's
a
place
where
we
all
kind
of
agree
that
this
is
the
one
right
one.
Then
we
should
certainly
have
a
place
to
be
able
to
put
those
things.
I,
don't.
O
A
O
Extension
of
that
thought,
if
we're
going
to
have
a
place
to
host
the
specs
and
I,
think
that
might
also
be
a
reasonable
place
to
point
to
canonical
implementations
of
these
scalar
extensions.
So
imagine
if
we
had,
let's
say
three
or
four
very
common
custom.
Scalars
implementations
of
these
custom
scalars
on
both
the
server
and
the
client
for
a
given
library
is
something
that
somebody's
gonna
look
for
immediately.
O
A
It
matches
really
well
to
how
we've
been
how
we
introduced
the
graphical
spec
itself
right.
It
came
as
a
spec
and
the
reference
implementation,
and
we
should
probably
follow
that
lead
where
any
sort
of
graphical
foundation,
official
spec,
will
have
a
really
high
bar
for
the
quality
of
that
and
for
including
reference
implementations,
yeah.
K
Q
P
Q
Come
back
to
the
idea
of
I
think
having
like
promoting
a
specific
version
of
a
scaler,
it's
kind
of
the
decision
to
make
like
if
we
decide
that
we
want
promote
consistency,
the
ecosystem
for
specific
scalar,
to
kind
of
ease,
adoption
and
and
and
limited
surprises,
I
think
this
is
a
good
reason
to
kind
of
publish
it
craft
code.
A
torque
scaler
specification
like
this.
Q
This
proposal
we
put
up,
definitely
allows
you
to
come
up
with
anything
you
want,
but
the
other
aspect
is
like:
do
we
want
to
promote
consistency
and
then
I
think
this
is
a
good
time
to
think
about.
Okay,
this
specific
scalar
should
be
implemented
in
a
specific
way,
or
we
want
to
encourage
implementation
in
a
specific
way
and
then
I
think
it's
a
good
time
to
put
it
up
on
craft.
Build
a
dog
like
I.
Think
that's
the
kind
of
that's
how
I
think
about
it.
D
D
B
A
Yeah,
that's
and
that's
the
critical,
important
difference,
because
I
think
that
was
the
that
was
the
nail
in
the
coffin
for
the
date
time
specific
proposal
when
we
realized
like
we
started
pulling
the
community
and
we
found
out
that
there
was
like
no
good
name
for
that.
Scalar
people
were
using
the
word
date
time
to
represent
UNIX
timestamps
and
three
or
four
different
versions
of
the
of
the
IETF
version
of
the
day
time
and
you
just
we.
A
We
were
not
in
a
position
to
say
if
you
have
a
type
called
date
time,
here's
how
it
should
work,
which
is,
which
is
why
this
one
is
great.
But
like
yes,
your
point
is
exactly
right
that
this
is.
If,
if
we
end
up
hosting
those
on
graphical
org,
then
the
intent
would
for
those
to
be
official.
So,
like
the
hope
would
be
that
if
you
do
have
date/time
that
we
really
hope
that
you
opt
into
this
particular
spec
speaking.
A
O
But
you
see
what
I'm
saying
like
if
we
had
a
named
space
or
not
a
name
space
but
like
a
prefix
or
you
know,
graph,
QL,
colon
and
then
string
graph,
your
colon,
and
that
would
say
that-
gives
us
opportunity
to
kind
of
include
some
of
these
things.
If
you
ever
want
to
expand
that
set
of
official
customs
official
scalars,
we
could
also
do
that
by
that
mechanism.
K
Oh
yeah,
the
thing
I
want
to
add
in
it
is
once
you
publish
it,
it
shouldn't
change
again,
there's
no
burning
capacity
there.
My
my
thought
on
the
built-ins
was
actually
that
they
would
yeah
return
the
link
to
the
actual
core
Raffaele
specification,
because
that
is
where
they're
defined
and
it
does
run
into
this
issue.
You
traced
of
multiple
scalars
defined
in
one
spec
I.
Don't
feel
strongly
about
that.
Yeah.
K
A
Don't
know
I
feel
like
it's
probably
best
to
just
reserve
this
feature
for
custom
scalars,
where
you
need
the
disambiguation,
because
I
think
it
would
be
redundant
because
there's
already
spec
text
that
says,
if
you
have
a
type
named
string.
This
is
how
it
needs
to
work,
and
it
seems
like
not
particularly
additionally
helpful
to
also
say
there's
a
specified
field
for
it.
A
A
A
This
doesn't
have
to
be
a
custom
written
spec.
This
could
be.
Is
respect
already
exists,
especially
for
scalars,
which
are
typically
just
describing
how
a
string
is
being
formatted.
There's
not
a
lot
of
graphical
specific
behavior,
all
the
time,
and
so
you
know
date
date
time.
Maybe
you
want
exceptions,
or
maybe
you
want
like
a
graphical
specific
subset,
but
maybe
an
example
is
a
URL
type.
I
actually
think
we
already
talked
about
URLs
is
an
example
of
a
custom
scalar
and
that
one
you
could
just
point
to
the
yeah.
K
B
Q
B
B
And
yeah
in
this
case
actually
you're
right,
and
in
this
case
we
should
have
a
specification
document.
There
are
other
things
like
if
you're
looking
at
floating-point
numbers,
they
are
very
exact
specification
documents
where
you
could
just
point
to
I.
Don't
know
a
double
precision
floating
point
implementation
and
they
will
point
to
the
e
specification
document
and
it
would
be
sufficient,
but
in
this
case
I
would
actually
write
something
up.
Yeah.
Q
That
that's
exactly
our
intention,
like
you
can
point
to
official
specification.
If
it's
sufficient,
detailed
enough
and
not
ambiguous,
and
then
you
can
do
it
and
if
you
feel
the
need
like
in
the
case
of
daytime,
you
need
to
be
a
little
bit
more
specific
and
clear
up
some
some
details.
Then
you
need
to
write,
maybe
a
short
specification,
and
if
you
want
to
come
up
with
a
total
own
version
of
something,
then
you
need
to
write
a
full
specification.
You
can
do
all
of
this
with
because
it's
just
a
link
yeah.
K
I
think
we're
all
I
have
an
agreement
on
on
where
we
want
to
get
to.
As
far
as
next
steps
I
don't
know
what
works
best
be
if
you
want
and
need
to
take
his
daytime
spec
and
turn
it
into
the
separate
RFC
where
we
can,
where
it
should
live,
or
it
should
continue
to
just
be
part
of
the
general
spec
change
for
adding
a
URL
to
these
scalars
I.
K
A
It
should
definitely
be
its
own
thing,
yeah
I,
just
for
the
sake
of
the
future
of
this
particular
proposal.
I'd
love
for
it
to
be
fully
isolated,
even
though
it's
motivated
by
the
date/time
change
I
think
it's
actually
completely
reasonable.
That
people
would
pick
up
the
like.
You
know
our
RFC
3339
date/time,
because
there's
there's
a
bunch
of
existing
tools
out
there
that
do
that.
A
That
could
be
totally
reasonable,
so
I
wouldn't
want
to
hold
this
up
specifically
because
the
motivating
date
like
subset
of
date/time,
that
that
we
want
to
talk
through,
isn't
ready
yet
and
especially
for
stuff
like
URLs,
like
being
able
to
link
to
say
this
is
exactly
what
I
mean
when
I
say
this
is
URL
is
already
valuable
in
its
own
right,
so
I
would
like
to
keep
them
separated,
and
maybe
we
can
kind
of
listen
in
to
so
what
we
figure
out
with
the
graphically
HTTP
stuff.
Since
that's
next
on
our
agenda
yet
into.
B
To
clarify
I
think
the
question
was:
where
do
we
put
the
I
think
it's
clear
that
we
have
that
piece
of
separate
things
like
defining
the
daytime
and
defining
that?
But
where
should
we
put
those
specification
documents
for
daytime?
Should
it
go
in
the
aspect
repository
for
now?
Should
we
we
have
like
five
seas
or
where
to
start
the
work
on
a
specification
document
for
daytime
I,
see.
A
E
Could
I
ask
a
question
about
more
complex
types,
so
what
I
have
in
mind
at
the
moment
is
file
uploads,
for
example.
Is
this
something
that
you've
already
dealt
with,
because
at
the
moment
there
are
various
graph,
your
servers
that
support
file
uploads,
both
by
using
multi-part
form
data
or
by
uploading
through
JSON?
And
if
you
upload
through
JSON,
you
probably
use
like
base64
encoding,
where
is
for
multi-platform,
dotrice,
I,
think
binary
or
something
I'm,
not
sure,
with
obviously
the
the
the
mine
headers.
K
K
A
Totally
is,
and
it
I
can
see
this
being
a
useful
step
forward
for
that,
because
you
could
at
least
you
know,
I
I
know
that
Facebook's
API,
for
example,
has
does
have
a
type
called
file.
That's
an
input
used
as
for
inputs
and
they're
their
tools
just
understand.
If
you
see
a
type
called
file
that
you
have
to
submit
your
your
mutation
in
a
particular
way,
but
at
least
you'd
be
able
to
like
see
that
see
a
spec
for
it
or
respect
URL
as
an
opaque
identifier
and
then
behaves
the
right
way.
A
S
A
A
Own
list,
or
actually
URLs
really
a
good
point.
What
I
mean
when
I
say
opaque?
It
should
be
both
unique
and
opaque.
It's
not
opaque
to
a
human
viewer.
It
should
be
opaque
to
tooling.
So
all
the
tooling
knows
is
that
this
is
a
unique
string
that
I
can
like.
Does
this
equal?
This,
you
know.
Does
this
match
anything
I've
seen
before,
but
it
doesn't
know
the
difference
between
HTTP,
whatever
and
just
a
string
of
base64
encoded
blah
like
it.
It
doesn't
need
to
know
what
what
it
is.
A
All
it
needs
to
know
is
like
I
can
match
this
and
if
I
spot
a
thing
I've
known
before
then
I
have
pre-programmed
rules
for
how
to
handle
that
thing,
but
a
human
would
then
look
at
that
and
go.
Oh,
that's
URL,
I'm,
gonna,
open
it
up,
see
a
human
readable
document
and
then
write
their
software
that
subscribes
by
that.
But
the
reason
why
is
I
specifically
want
to
kind
of
keep
using
the
word.
A
Yeah
you
could
imagine
like.
Oh
it
has
to
match
this
regular
expression
or
something
like
that.
That's
very
much,
not
opaque
and
those
are
like
they
have
constraints
such
that
they're.
They
just
always
end
up
being
a
disappointment
which
is
I,
think
why
we
ended
up
bailing
on
those
directions
and
in
the
in
terms
of
a
opaque,
URL
identifier.
But
that's
the
reason
why
I'm
using
that
term,
but
a
really
good
point
to
bring
it
up,
because
I
do
think
when
we
end
up
writing
the
spec
text.
F
Yeah
so,
like
I,
have
some
problems
with
internet.
So
if
you
have
problem
here
me
or
anything,
just
post
and
chat
and
I
will
try
to
reconnect
to
another
Wi-Fi
point
so
about
graph,
kill,
/
CTP.
We
discuss
it
like
a
couple
times
a
year
ago
and
year
and
a
half
ago
and
like
motivation,
because
this
will
not
work
previously
like
photo.
We
need
the
motivation
and
to
stay
focused
on
with
motivation.
F
So
my
personal
motivation
for
doing
this
work
was
that
in
our
co-working
space
there
is
a
company
and
they
implemented
zone
craft
airserver
and
like
they
liked.
The
idea
and
I
was
really
enthusiastic
about
Raphael,
but
when
they
had
some
problems
and
I
try
to
troubleshoot
them.
I
have
trouble.
Connections
to
to
the
crack-tip
server
isn't
graphical,
like
I'll
stay
here
like
risk
wines
because
they
implemented
it
differently,
so
they
reduce
back
and
the
youth
graph
kill
net
while
by
him,
which
is
like
misunderstand,
don't
have
any
connection
to
http.
F
So
it's
the
same
type
of
fibrous
graph
cages,
so
there's
pure
execution,
validation
and
other
functions
and
they
permit
the
one-way
transport
wire
and
because
they
didn't
use
the
proper
name
for
fields.
They
just
call
it
like
I.
Think
like
wearables
was
code
differently
and
unlike
operation
name,
some
some
some
arguments
was
called
differently
for
a
sponsor.
F
But
at
the
same
time
there
is
some
did
some
difference
in
different
accommodation
with
with
with
was
motivation,
respect
to
have
mostly
interoperability,
interoperability
between
different
tools.
So
to
make
it
more
like
walking
way
because
I
know
like
graphical
to
have
constant
problem
with
people
asking
them
to
add
more
configuration
options
to
specify
like
URL,
also
header
so
stuff.
So
I
actually
want
to
reduce
number
of
configurations
for
connection
to
traffic
area
and
porn,
not
increase
it
and
so
idea
about
current
state.
It's
like
minimum
volleyball
spike.
F
It's
described
something
but
at
the
same
time
is
not
provide
to
experimentation,
and
it's
not
like
touching.
You
just
touch
the
common
thing.
Basically,
what's
most
of
human
tation
copied
copied
stuff
from
Express
graphical,
like
reference
server,
foie
gras,
kale
and
so
I,
basically
put
it
in
spec
text.
F
What's
currently
there,
an
idea
like
I
can
with
project
understocked
but
I,
so
X
Polk,
who
is
actually
person
pink
me
on
Twitter
and
asked
what
is
the
status
and
to
be
real
lightweight
I
have
20
Pro
projects
to
work
on
and
I
respect
already
in
minimal,
viable
state.
So
we
can
do
something
so
ideas
here
is
to
move
it
to
Foundation
and
to
create
like
working
group
and
awake
people.
Hawks
will
implement
servers
to
lead
like
like
a
bogus
AWS,
these
guys
and
Rob.
F
Who
actually
commented
one
issue
so
yeah
so
idea
is
like
not
about
technical
side
of
specification,
but
about
process
of
moving
T
to
Foundation.
Is
it
possible
how
to
do
that
if
people
interested
in
collaboration
and
how
were
set
up
like
subgroup
above
that
and
if
there
is
any
volunteers
for
participating,
I.
B
Think
it's
a
great
idea
to
finally
put
that
in
the
offices
back
I
mean
that's
for
long
time.
For
a
long
time
now
this
I
would
say
specification
draft
and
it's
kind
of
ambiguous,
because
every
graphic
word
server
actually
implements
this
minimal
set
of
specification
there
and
it's
basically
taking
what
everybody
is
using
to
make
it
more
efficient.
And
if
you
think
about
people
getting
started
with
graphic
well,
they
read
the
spec
and
ok.
The
spec
is
transport
agnostic,
but
the
main
transport
format
is
HTTP.
B
So
having
a
specification,
there
is
very
valuable,
even
though
that
we
can
use
it
on
an
other
transport
from
us
and
I
think
even's
proposal.
There
is
like
a
minimal
solution,
I'm
just
missing
there
that
we
have
an
extension
feel
there's
well
like
in
the
response,
and
then
it
would
be
kind
of
perfect.
It
wouldn't
be
overbearing
to
implement
it.
You
still
have
your
space
as
an
implementer
to
add
things,
but
it
would
be
a
great
minimum
minimum
specification
to
get
HTTP
running
yeah.
J
I
also
interested
in
this
and
I
think
I'm,
the
one
who
tweet
Ivan
about
it
I
think
it's
really
valuable
to
remove
conversation
about
ok.
How
do
we
handle
you
know?
What's
the
right
way
to
had
all
response
codes
or
things
like
that,
let's,
like
articulate
that
and
one
place
so
that
we
can
interrupt
interact
across
different
representations
of
that,
whether
that's
in
the
JavaScript
implementation-
or
this
was
a
different
languages,
implementing
graphic
UL
over
HTTP.
A
Yeah
I'm
excited
about
this.
We've
been
talking
about
it
for
a
long
time.
It's
time
that
we
really
push
this
to
the
the
right
point,
I
think,
there's
a
lot
of
things
that
we
need
to
get
right.
There's
you
know,
tools
need
to
be
able
to
know
just
because
there's
a
URL-
and
this
says
graph
QL-
is
it
complied
to
the
spec
or
not
so
you'll
have
to
have
some
sort
of
way
to
identify
that,
from
a
tooling
point
of
view,
we
should.
A
We
should
make
sure
that
it's
actually
handling
all
the
cases
that
tools
like
the
Apollo
client
tools
graphical
need
that
it's
actually
handling
the
cases
and
all
the
server
implementations,
the
Express
graph,
QL
or
graphical
Java.
The
other
servers
that
are
supplying
HTTP
JSON
are
doing
are
captured
here
right
now,
it's
like
a
little.
It's
not
I,
think
it
could
be
more
strict.
You
know
whether
it's
takes
JSON
or
not
in
in
post
bodies,
etc.
A
There's
there's
just
a
lot
of
stuff
that
could
be
crisper
and
I'd
love
to
see
a
subcommittee
boot
up
around
this
that
can
sort
of
come
up
with
a
whole
game.
Plan
of
this
is
what
the
spec
for
graphical
HTTP
should
look
like.
Hero
changes
that
we
need
to
make
to
express
graph
QL
to
other
frameworks
so
that
they
can
be
compliant
with
that.
A
Spec
here
are
changes
we
need
to
make
to
popular
clients,
including
graphical,
so
that
they
can
very
easily
work
with
that,
so
that
we're
reaping
the
tooling
benefits-
and
we
can
have
like
a
big
launch
of
this
thing
with
all
these
tools,
supporting
this
thing
happy
to
host
that
as
part
of
the
graph
gala
foundation.
I
think
this
is
this
is
the
clear
clearly
the
most
important
sub
spec
around
graph
QL,
that
we've
that
we
need
to
work
around.
A
N
Would
like
in
in
this
area,
to
have
some
clarity
on
where
we're
drawing
the
line
as
to
what
belongs
in
the
graph
QL
spec
and
what
does
not,
for
example,
as
Sam
was
talking
about
in
the
beginning
there
HTTP
status
codes.
Is
this
something
that
says
I
mean
we've
already
have
that
everything
should
be
200,
but
there
are
cases
that
are
you
know
it's
still
in
Express
and
not
in
graph
QL,
yet
like
potentially
a
401
for
Rwanda,
not
authenticated
or
some
500
situations.
N
N
S
N
B
A
The
database
queries
are
another
great
example
of
leveraging
transport
agnosticism
or
they
can
submit
database
queries,
which
are
typically
not
done
over
HTTP,
but
HDPE
is
certainly
the
lion's
share
of
how
people
are
using
graph,
QL
and
so
sort
of
for
the
exact
same
reasons
that
we'll
specify
here
I
think
it's
going
to
be
super
valuable
to
have.
You
know
not
just
create
awesome,
consistency
around
services
and
allow
tools
to
be
built
that
can
leverage
those
things
which
that's
certainly
been.
A
The
most
annoying
part
of
a
graphical
tooling
so
far
is
connecting
it
to
everybody
servers
but
really
good
points
on
there's
a
number
of
things
that
Express
graphical
does
that
aren't
represented
in
the
spec
so
far,
we
should
account
for
those
all
the
various
topics
that
are
sort
of
tangential
to
this.
You,
you
mentioned
authentication.
That's
that's
a
really
important
one
to
mention
here.
You
know
the
spec
should
at
least
say
something
about
authentication,
even
if
it
what
it
says
is
this
is
up
to
you.
A
B
Yeah
and
also
I
think
when
we
have
that
spec
somewhere
written
up
it
allows
to
explore
also
other
things
like
Benjy
set
file
uploads,
for
instance,
you
could
exploit.
If
you
have
a
spec
repository
which
describes
the
office
HTTP
spec,
then
you
can
put
our
C's
to
explore
other
things
like
how
should
we
upload
binary
stuff?
If
we
want
to
do
binary
stuff
I
mean
graphical,
is
not
the
best
solution
for
binary,
seems
and
stuff
like
that,
but
you
could
explore
things
like
that,
and
we
cannot
do
that.
C
Just
to
just
to
add
to
so
kind
of
like
the
name
of
a
graph
QL
over
HTTP
and
I
know,
there's
there's
a
part
in
that.
The
spec
that
deals
with
ascriptions
and
possible
implementations
is
there.
Is
there?
Is
the
goal
of
graph
QL
over
HTTP,
also
to
describe
kind
of,
like
maybe
the
polling
solution
of
the
the
subscription
part
or
we're
gonna?
Keep
that
keep
that
out?
It's.
A
This
is
probably
one
of
the
best
examples
of
that,
because
subscriptions
are
complicated
and
doing
real-time
connections
is
complicated.
So
there's
there
is
a
fair
amount
of
explanation
about
how
we
might
do
that
now.
One
thing
that
we
might
want
to
change
once
we
get
graph
kill
HTTP
spec
in
in
a
really
solid
state,
where
we
trust
it
and
we
would
happily
recommend
people
adopt.
It
is
in
the
main,
graphical
spec,
where
we
do
talk
about
HTTP.
A
J
G
N
J
S
B
In
there
I
mean
the
document
that
even
answer
it's
a
good
starting
point,
because
it
basically
describes
a
minimal
sets
that
most
of
the
graphical
service
implement
anyway.
So
you
can
start
from
there
and,
as
we
said
it
could
could
be,
rewritten
may
make
more
crisper
but
I
think
it's
a
good
starting
point
to
use.
F
F
What
and
I
can
alkalis
like
a
coal
seam
or
to
good
graphic
Oh
team
with
current
working
group
and
I
can
take
responsibility
of
trying
to
invite
everybody
who
I
can
promote
the
server,
have
a
public
write
the
I
can
have
introduced
Matt
and
I
think
this
can
be
good,
such
as
word
for
group,
as
I
mentioned
issue.
I
actually
won't
want
respect
to
be
ruled
by
community.
F
Because
what
we
need
to
do
get
more
stuff
so
but
I
think
we
I'm,
ok
with
certain
isin
Wisco
when
cousin
of
the
people
and
when
we
decide
to
go
to
the
next,
so
I,
don't
think
we,
when
you
drop
one,
always
cool
way
to
measure
polite
like
should
we
move
repoing
to
gradually
get
up
grab
it,
how
gradual
urbanization
github
and
like
just
pick
up
like
a
date
for
Nicole
I,
think
and
this
will
would
be
starting
point.
I.
F
F
Even
if
we
test
a
pretty
basic
issue
would
be
useful
to
help
mm
so
boss,
I,
think
like
we
can
have
RFC
SFIL
for
other
stuff,
like
quite
a
botching,
so
I
actually
think
it
makes
sense
to
have
a
separate
repo,
because
it's
like
aspects
that
we
expect
to
be
woven,
for
example,
for
daytime.
If
you
accepted
a
it,
would
be
more
as
one
time
spac.
So
we
just
wrote
it
and
put
it
there
and
hopefully
not
changing
but
graphically
on
GDP.
F
A
A
I'm
also
gonna
strongly
encourage
using
github
issues
because
it'll,
let
us
just
start
to
start
moving
on
this
and
at
least
open
up
a
bunch
of
issues
for
the
things
that
we
want
as
open
questions,
whether
those
are
specific
to
the
spec
themselves
or
it's
just
about
how
we
want
to
manage
the
effort
and
progress
going
forward.
Let's
use
Yvonne's
existing
repo
and
as
a
separate
action
item
I,
will
investigate
what
it
means
to
pull
that
repo
into
the
graphical
foundation,
github
org
and
if
there's
any
any
prerequisites
we
need
to
handle
before
doing
that.
N
F
So
like,
if
we're
moving
with
repo,
so
I
just
create
issues
in
and
I
wait,
didn't
everybody
on
this
working
group
and
I
will
think
everybody
from
every
companies
that
have
public
craft
k-lite
die
like
major
one
like
github
and
I,
think
they
would
be
interested
because
then,
in
the
end,
they
need
to
compile
this
back
up
if
we
make
it
official,
so
I'm.
Taking
this.
This
is
an
action
item.
I
think
everybody
on
this
working
group
and
I
will
try
to
pink.
F
Everybody,
wouldn't
be
interested
and
wait
when
I
rate
a
shoe
with
a
day.
I
can
actually
create
it.
So
it's
right
now
initial
discussion,
date
or
meeting
because
I
have
like
rocks
night
and
rate
issues.
So
you
can.
I
will
create
important
chart
and
you
can
send
it
to
anybody
can
be
interested
in
this
and
we
can
discuss
like
it's
date
and
time
works.
D
D
D
D
Basically,
disallow
making
yeah
defining
such
schemas,
and
what
we
decided
last
working
group
meeting
is
that
we
want
to
examine
the
complexity
of
those
implementations,
but
I
would
like
to
add
that,
because
this
is
just
some
clarifying,
but
the
implementations
don't
really
have
to
implement
anything
to
follow
that
they
only
have
to
badly.
They
are
optimally
along,
they
can
validate
against
it,
but
it's
not
Nitori
for
them
to
do
it.
So
there
have
been
two
implementations
that
have
implemented
such
an
validation.
That's
the
reference
implementation
in
JavaScript
and.
D
So
as
a
objective
measurement
of
the
complexity,
I
looked
at
the
lines
of
code
and
those
implementations
so
for
the
implementation
part
itself,
it's
50
lines
in
the
JavaScript
implementation
and
104
lines
in
PHP.
The
tests
are
114
lines
in
JavaScript
and
138
in
PHP
and
the
validation
function,
which
actually
does
the
validation
has
a
cyclomatic
complexity
of
6.
A
F
Yes,
so
I
can
we
actually
have
a
cycle
detection
in
couple
other
places,
so
it's
not
something
that
ever
matters
need
to
come
at
for
the
first
time
with
the
text,
five
holes
inside
the
fragments
and
so
like
in
permutation
Kosta,
pretty
small,
it's
mostly
like,
where
the
little
beetle
cost
in
a
spider
so
whether
to
a
cup
of
cup
of
Normandy
wines
in
aspect.
So
basically
it's
like
and
I
think
like
questions
back
is
bigger
than
custom
and
permutation.
But
even
an
aspect
is
prettiest
bridges,
falsehoods,
break
top
of
cup
of
wine
suspects
and.
D
F
F
Even
though
we
have
ik
cycles
in
graph
K,
inherently
cycles
on
graph
Gaelic
for
output
types,
I
think
work
it.
It
will
be
great
home,
manage
them
for
input
types
and
cysts.
Last
time
we
agree
that
actually
I
think
it
was
action
item
on
you
to
add
like
note
into
spec.
The
graph
key
is
not
done
that
helped
circle
input
values.
A
D
A
The
expectation
is
that
they
that
they
would
write
like,
if
so
I
mean
the
the
reason
I'm
asking
this.
Is
you
know
right
now?
We
don't
have
compliance
test
suite,
but
it's
something
that
we've
talked
about
building
in
the
past
and
if
we
did-
and
this
was
a
rule
in
the
spec,
then
we
would
certainly
have
a
test
case
that
defines
a
a
cyclic
input,
object
and
and
then
expected
a
validation
error
or
a
schema
validation,
error.
A
Right,
it's
clarifying
something
that
would
right
now,
it's
not
a
schema
invalidation;
instead,
it's
just
something
that's
impossible
to
actually
provide
at
runtime.
So
even
if
you
did
this
you'd
end
up
in
a
state
where
your
graph
kills
server,
just
wouldn't
really
work
correctly,
at
least
for
that
particular
input
object.
It's
basically
advertising.
B
H
S
Yeah
I'm,
ok
with
this,
because
I
think
there
are
some
potential
weird
edge
cases
where
maybe
you
have
some
kind
of
input
that
you
you
want
to
have
you
know
references
and
you
know
force
them
and
you
are
using
a
transport
like
mechanism
that
supports
references,
but
I
think
the
assumption
has
always
been
that
this
would
be
invalid.
So,
like
clarifying
that
in
this
fact,
I
think
it's
fine
now
and
if
someone
finds
a
use
case
later,
I
don't
think
they
would
be
breaking
anything
to
remake
this
possible
in
some
weird
edge
case.
D
Yeah
thinking
about
the
chain
from
from
last
month,
I
found
that
there
are
two
basic
assumptions
that
I
am
that
are
underlies
this
rule,
and
one
is
that
I
think
graph.
Ql
schemas
must
be
variable,
so
they
are
meant
to
be
used
for
query
and
should
function
and
graph
was
not
meant
to
be
a
language
to
express
a
type
system
and
offer
introspection
capabilities
for
that
cost.
D
If
you
were
to
take
just
that
use
case
and
such
a
type
would
be
kind
of-
and
the
second
assumption
is
that
I
think
Rascals
literals
are
first-class,
meaning
that
graphical
operations
must
be
able
to
be
expressed
by
using
just
literal
graph
query
language
so
features
network.
Only
you,
man,
variables
are
both
I.
A
D
D
A
F
M
A
M
A
We
can
discuss
it
absolutely
yeah.
There's
no
need
to
rush
on
this.
We'll
I'll
I'll
take
this
as
an
offline
task
to
both
do
another
review
of
the
spec
text
and
we
can
try
to
run
down
any
remaining
issues.
If
all
looks
good,
we'll
move
this
to
the
next
stage
offline.
If
there's
any
other
remaining
issues,
you
might
wait
for
another
meeting
to
discuss
it
again.
T
T
T
We
have
added
a
criteria
section
that
has
a
handful
of
points
being
made
in
it
for
what
the
shape
of
this
solution
should
look
like.
We
talked
about
that
last
time
and
there
is
also
an
open
PR
to
add
a
couple
more
solution:
criterias
there's
an
open
PR,
which
I
think
is
very
interesting
to
add
a
prior
art
section,
which
kind
of
references,
other
languages
or
kind
of
IDL's
or
whatever
that
have
a
similar
concept.
So
we
can
get
a
better
sense
of
like
the
broader
ecosystem
of
what
is
happening
there.
T
So
that's
kind
of
overview
of
what's
been
going
on.
What's
happening,
open
questions
kind
of
still
remain
around
what
we
would
do
once
we
had
all
these
solution
criteria
in
place
and
all
the
objection
registered.
How
would
we
take
steps
towards
the
decision
making
phase
of
that
of
this
whole
whole
process?.
T
But
I
guess
I
would
want
to
open
it
up
to
discussion
so
around
that,
like
do
do
people
feel
like
the
solution
criteria,
are
reaching
near
completion
order,
or
is
there
still
a
lot
more
work
to
happen
there,
or
are
we
talking
to
the
point
where
we
can
start
talking
about
how
to
reach
a
consensus
decision
on
this
broad
issue?
I.
F
Actually,
like
wanted
to
do
a
couple
more
code
areas,
I
heard
like
because
of
this
graph
care
summit,
I,
think
white
and
some
other
people
like
travel
back
and
forth
and
prepares
a
talks.
So
I
kind
of
wait
for
off.
You
know
with
Alicia
process.
You
know
I
would
try
to
catch
up
next
week,
and
one
thing
I
want
to
point
is
that
working
on
the
research.
F
So
idea
is
not
with
particular
point
by
idea
that
working
on
a
document
can
help
us
actually
to
change
their
own
minds
and
some
of
proposals
so
I
become
open
to,
for
example,
to
registration
and
because
previously
I,
just
like
I,
was
opposing
to
it.
So
what's
what's
so,
I
think
criteria
would
work
that,
if
nothing
added
into
documents
on
time-
and
we
think
everybody
who
participated
in
this
discussion
saying
it
was
last
call
for
ideation
and
nobody
else
anything.
F
T
A
Love
the
prior
art
thing,
especially
if
this
isn't
always
possible,
but
sometimes
you
can
also
go
all
the
way
back
to
like
the
source
of
where
the
ideas
came
from.
So
it's
not
just
that
the
this
feature
exists
in
this
IDL,
but
you
can
find
something
roughly
equivalent
to
our
working
group
process.
The
head
showed
the
introduction
of
such
the
idea,
which
is
almost
always
helpful.
A
So
it
gives
you
like
a
parallel
reality
to
to
jump
into,
which
is
pretty
pretty
awesome,
especially
for
the
ideals
there's
there's
a
handful
of
them
out
there.
That
may
or
may
not
have
something
like
this
and
have
their
own
set
of
restrictions.
You
can
just
kind
of
go
pull
those
communities
to
find
out
what
they
like
or
don't
like
about
those
particular
restrictions.
A
Apart
is
great
in
terms
of
how
we
will
move
to
decision
making
process.
My
hope
is
that
this
document
essentially
becomes
the
decision-making
process.
It
gets
a
way
that
it
takes.
What
in
the
past
has
just
mostly
been
one-off
issues
or
us
sort
of
debating
through
this
in
these
meetings
and
in
it
captures
it
all
and
it
captured
it
in
a
structured
way
and
that's
that's
awesome
and
that
it
keeps
us
from
repeating
ourselves
and
regressing
a
bunch,
and
so
that
alone
is
is
particularly
valuable.
A
T
A
We
might,
it
might
be
careful,
we
may
have
to
be
careful
around
subscribing
subjective
value
to
which
criteria
are
more
important
than
others
or
which
one
sort
of
like
knock
something
out,
because
people
are
liable
to
disagree,
but
that's
actually
a
valuable
thing.
If
people
disagree
right,
that's
that's
the
kind
of
thing
we
want
to
capture
so
I.
Think,
probably
what
I
would
suggest
is
just
simply
listing
out
for
each
possible
solution
like
here's,
how
they
here's,
how
they
rank
against
the
solution
criteria.
A
So
it's
a
solution
criteria
is
you
know
right
now,
it's
kind
of
just
like
a
list
of
a
handful
of
things
that
they
need
to
be
able
to
do.
We
can
say,
like
alright,
it
make
checks
3
out
of
5
boxes
like
here's,
the
two
that
it
doesn't
check
and
here's
why
it
doesn't-
and
my
sense
is
that
almost
all
of
these
are
gonna
be
behind
on
one
of
them,
so
we'll
eventually
kind
of
whittle
this
down
to
like
which
criteria?
A
That's
right
because
I
think
most
of
the
debate
in
the
past
has
mostly
been
people
talking
past
each
other,
because
we
we
don't
totally
agree
on
the
problem
and
the
solution
criteria,
and
you
know
if
one
person's
favored
solution
totally
misses
the
solution
criteria.
They're,
not
you
know,
they're,
not
stupid.
It's
not
that
they
didn't
see
that
it's
that
they
didn't
think
that
that
solution
criteria
was
particularly
important,
but
that's
the
one
that
they
would
cut
in
order
for
having
a
simpler
solution,
which,
which
is
great
like
that
as
language
and
software
designers.
A
That
is
how
we
should
be
thinking,
but
when
we're
doing
that,
it
ends
up
being
explicit
about
the
the
solution
and
implicit
about
the
criteria
and
I
find
that
for
discussion.
That's
just
been
kind
of
really
difficult
and
it's
been
much
more
valuable
like
this
document
has
dramatically
aided
the
process,
because
now
we're
sort
of
pointing
at
the
criteria
and
we're
coming
up
with
objections
and
concerns
about
the
solution
criteria
rather
than
objections
and
concerns
around
particular
solutions,
which
is
like
way
more
crisp.
I.
D
E
A
Can
be
a
living
document?
I
sorry
to
interrupt
I
just
want
to
like
I,
don't
want
us
to
slow
down
on
it.
I
want
us
to
add
stuff,
even
if
it's
partial,
because
I
really
want
people
to
feel
like
this.
This
isn't
something
that
requires
a
lot
of
discussion
before
we
make
changes
to
this
document.
This
document
is
the
discussion,
and
it's
totally
fine.
If
people
throw
up
late
with
additional
stuff
since.
E
A
Totally
one
thing
that
I've
seen
work
decently
well
is
using
the
like
traffic
light
style.
You
know
red
red,
yellow,
green,
wear
green
means
that
it's,
it
totally
meets
the
criteria.
It
looks
great
red
means
that
it
clearly
fails
the
criteria
and
yellow
means,
like
aa
kind
of
somewhere
in
the
middle
here's
some
explanatory
text
of
like
why
this
is
kind
of
bending
the
rules
of
the
criteria
that
that
might
work
but
I
think
it's
totally
fine
if
this
stock
ends
up
being
kind
of
overly
verbose,
but
but
yes
Vince.
A
T
A
Like
that
I
like
that
idea,
yeah,
maybe
like
numbers
for
the
solution,
criteria
and
letters
for
the
solutions,
or
vice
versa,
or
some
shorthand
for
referring
to
them,
yeah
yeah.
That
could
be
pretty
useful.
That
way,
it's
clear
that
there's
like
a
list,
here's
the
list
of
the
solution
criteria
and
it's
and
it's
enumerated
and
here's
the
list
of
the
possible
solutions
and
they're
enumerated.
And
if
you
don't
see
one
that
you
think
can
fit,
then
you
know
we
can
add
solution,
30
or
40.
Oh
right
area,
Q
or
whatever.
F
Actually
like
to
suggest
one
thing
that
can
speed
up
stuff
I
feel
like
for
some
things:
we
kind
of
lose
the
base
because
bears
are
not
much
into
spec
and
it's
partly
my
responsibility,
because
I
can't
have
commit
wise,
but
like
a
lot
behind
I
Hawaii
after
returning
back
to
a
chronic
halfway
point
of
stuff
I
need
to
so
can
we
have
have
a
rule?
One
of
the
reason
why
not
merchant
stuff
and
timely,
freshmen
and
I
think
it's
the
same
stuff
fully.
F
Is
that
you
need
to
read
for
all
the
commands
to
know
that
everything
is
resolved
so
can
we
can?
We
can
I
suggest
like
if
wins,
approve
PR,
for
if
he
it's
like
much
in
it's
just
a
technical
thing,
because
right
now,
I'm
like,
for
example,
I
did
a
budget
created
RFC
with
this
mo
solution
criterias
and
to
know
if
it's
ready
too
much
or
not,
I
need
to
read
it
so
I
think
like
can
we
have
like
no
like
review
process?
F
A
I
have
a
suggestion
here:
I'm
I'm
curious
to
get
thoughts
on
what
do
people
feel
about
opening
dedicated,
get
repose
for
these
kinds
of
RFC's.
That
way,
the
like
maintainer
management
of
this
can
be
up
to
the
champions,
because
I
think,
like
the
the
clear,
miss
and
slow
down
here,
is
that
Vince
is
clearly
championing
this
effort,
but
Vince
doesn't
have
merge
rights
over
the
graphical
spec
and
this
document
lives
in
the
graph,
Gail's
back
repo,
and
so
like
he's
in
a
weird
position.
F
Think
what
book
works,
if
we
can
like
I,
think
like
you
can
require
coordinates
assign
so
so
we
can
reverse
anything.
It's
like
even
creating
separate
ripple
is
good.
One
problem,
I
see,
is
like
wait,
wait
integrated
somehow
to
my
Noriko,
but
keep
history
away
into
somewhere,
so
I
I
don't
think
we
should
ever
delete
such
repose,
but
at
the
same
time
I
don't
think
with
heaven
right,
ten,
twelve
fifteen
mercy
rapist
this
long-term
solution.
T
F
A
We
could
certainly
try
that
as
well.
The
thing
that
I
was
thinking
about
is
it's
not
even
necessarily
that
the
that
the
graphical
foundation
org
is
the
place
where
all
these
need
to
live,
but
what
a
process
that
the
JavaScript
community
has
been
using,
that
I
think
actually
has
been
working
pretty
well
is
that,
since
anybody
can
come
up
with
a
an
RFC,
they
typically
just
do
that
on
their
own
accounts.
A
They
set
up
a
repo
and
then
that's
the
place
where
the
spec
text
lives,
any
explanatory
stuff
lives
any
supporting
files
lives,
and
then
all
issues
are
relative
to
that
specific
RFC
all
can
live
in
that
one
repo
and
then
there's
instead,
there's
just
one
file
that
just
lists
out
all
over
the
current
RFC's,
and
so
there
are
just
links
out
to
all
these
various
repos.
That's
work
pretty
well
because
it
just
lets
people
set
these
things
up
ad
hoc.
A
T
B
I
In
addition
to
that,
perhaps
a
convention
of
just
forking,
the
graph
QL
spec,
repo
and
and
putting
the
RFC
into
their
RFC's
directory,
for
example,
then
that
could
solve
what
I
think
Yvonne
was
mentioning.
As
far
as
like
it's
you
know,
it's
useful
to
preserve
the
history
of
the
RFC,
and
so
then
it
can
eventually
just
get
merged
in
once.
It's
you
know,
there's
there's
less
churn,
which
has
been
accepted.
F
I
F
What
about
github
action
so
and
making
champion
like
for
se
official,
so
it
can
be
like
we
can
project
for
somebody
to
write
action,
or
we
can
borrow
it
from
I
think,
like
some
other
projects,
may
may
have
ways
like
in
PR
I
thought
in
that
clip
community.
When
people
who
have
like
some
rights,
they
can
make
comments
to
both
my
commit
comments
with
comments
with
mud
for
something
over
on
the
test.
So
github
have
action
in
this
action
city.
Then
they
both
own
graphical
organization.
F
A
Alright,
well,
we
have
a
handful
of
ideas
here.
Let's
do
the
stupidest
thing
that
works
for
the
immediate
future,
just
to
unblock
I.
Think
the
stupidest
thing
that
works
is
Vince,
I'm
gonna.
Add
you
as
a
maintainer
to
this
repo
and
we'll
just
have
a
good
trust
relationship
that
you're
not
gonna,
go
like
mess
with
stuff
or
delete
stuff,
or
do
something
crazy,
yep
cool
and
obviously
that
doesn't
solve
the
actual
long-term
problem
of.
How
will
do
this
for
future
RFC's?
A
A
Maybe
we
we
could
try
something
with
setting
up
individual
repos
for
for
some
of
these
more
in-depth
RFC's
that
can
live
in
the
github
in
the
graph
QL
github
org.
If
we're
worried
about
that
becoming
sort
of
a
polluted
space
over
time,
we
can
do
I
know
Facebook.
Has
this
thing
called
Facebook
archives
where
they
just
it's
just
another
github
org
and
they
just
move
things
there
when
they're
sort
of
like
no
longer
maintained
or
they've
served
their
purpose.
A
F
And
actually
another
thing
about
always
specification
because
I
think,
like
it's,
not
working,
racquel
working
group,
its
graph,
clear
specifications,
working
group
innocence
like
how
hostdime
discussing
specification
I
just
remember
that
a
year
ago
we
decided
to
rename
analyze
specification,
remove
away
from
connection
specification
and
from
globally
specification
from
mutation
spec,
just
saying
it
so,
except
expect
for
best
practices.
Gingka
was
the
champion
forward.
F
A
Yeah
I'm
happy
to
keep
this
working
group
is
called
the
graph
care
working
group.
We
tend
to
cover
a
lot
of
ground.
We
spend
we
spend
most
of
our
time
talking
about
the
spec,
but
we
talk
about
other
things
too.
So
I
kind
of
like
to
think
of
this
as
a
like
a
hub-and-spoke
model
where
this
is
our
main
working
group
and
we
spin
off
subcommittees
and
sub
working
groups
for
more
specific
things
that
deserve
dead
discussion
graphical
one
and
the
HTTP
one
could
be
good
examples.
A
Yes,
we
do
not
have
a
specific
date,
but
I
would
love
to
do
that,
either
in
December
or
January.
Thinking,
based
on
the
last
handful
of
things
that
we
have
that
are
sourced
stage,
2
going
on
stage
3
or
stage
3
that
December
might
be
tight
and
January
might
be
more
likely.
But
what
I'd
like
to
do
is
aim
for
December
and
promise
January.
A
But
if
anyone
has
any
opinions
on
that
on
open
years,
I.
F
Think
we
need
to
specify
the
face
period
and
like
with
actual
date,
so
I
just
saying
for
some
period
we
don't
accept
anything
and
setup.
I
would
work
for
generally,
just
because
I
need
to
do
bunch
of
thinking
craft
KJ's,
one
of
the
things
we
want
to
merge
these
five
directives
and
for
that
we
need
to
solve
with
two
stage
introspection
things
that
I
promised
to
do
two
or
three
months
ago,
but
you
did
not
have
time
to
like
so
so
I
personally
word
for
January.
A
A
T
G
A
F
F
A
We
totally
did
not
thank
you
for
touching
that
better
late
than
never.
Let's
take
a
look.
A
Alright,
let's
take
a
look
at
these.
Actually
one
thing
that
I'd
like
to
do
going
forward
is
create
github
issues
for
all
of
these,
so
it's
great
to
have
them
in
the
notes
of
course.
But
if
we
have
them
as
github
issues,
then
we
can
actually
use
github
to
assign
them
to
people
track
progress
right,
yeah,.
A
A
Whoever
is
taking
notes
or
submitting
the
notes
up
as
pull
requests,
should
feel
free
to
have
an
extra
step
at
the
end
of
that
to
open
up
a
bunch
of
issues
that
relate
back.
That
would
be
super
super
useful,
but
let's
quickly
go
through.
All
of
these,
so
Lee
was
going
to
write
up
a
draft
plan
for
Freese
and
release.
Just
ask
about
that
clue.
They
just
have
not
made
that
crisp
enough,
so
that
one
is
still
open,
but
it
sounds
like
January
might
be.
That
plan
adding
an
on
or
move
note
to
explain.
A
You
know
variables
can't
be
so
for
interacial,
that's
a
great
candidate
for
opening
an
issue,
because
that
will
require
a
full
request
which
I
have
written
moving.
Lexer
look
Ahead's
to
stage
three
I
believe
we
are
good
on
I,
had
a
conversation
with
Rob
we're
good
on
that.
That's
gonna
move
to
stage
three
and.
A
And
the
victors
here
actually
grant
website
access
to
today
in
Horta
I
think
I
did
that
pretty
sure
I
did
that
might
have
to
double
check,
give
detailed
feedback
on
website
code
changes.
I
have
not
done
that.
I
had
a
conversation
with
or
two
the
graphical
summit
about.
This,
though,
and
I
still
owe
that
to
him
Mike
and
Yvonne.
This
one
sounds
done
right.
F
A
A
E
A
A
Alright
sounds
as
golden
with
that:
I
will
leave
the
last
half
hour,
scheduled
for
all
of
you
to
take
a
nap
or
drink
a
beer
or
whatever.
It
is
that
you
do
after
this
meeting
thanks
everybody
for
sticking
with
me.
This
has
been
a
great
one.
We've
covered
a
lot
of
ground
and
I
will
see
you
all
in
a
month.
Thanks
all
Cheers
goodbye
thanks.