►
From YouTube: GraphQL over HTTP - September 29, 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Hello,
just
sorry,
I'm
late
did
michael
come
hurry.
A
B
Well,
I
do
not
hear
the
other
voices
and
they
do
hear
your
voice,
so
so
it's
okay,
but
if
you're
on
a
retreat-
and
it
seems
like
most-
people
are
not
available
today-.
A
Yeah,
but
so
we
can
discuss
one
topic
so
and
I
think
is
the
most
critical
one.
I
think
we
can
skip
agendas
in
introductions.
It's
just
too
fast,
I'm
not
sure
if
it's
coming
to
youtube
or
not,
but
like
so
facebook
I
mean,
by
the
way,
like
two
people
is
much
better
than
one
yeah.
It's
like
twice
as
much
yeah
and
it's
highlight
a
problem
that
we
need
to
bootstrap
like
community.
It
shouldn't
be
a
bus
factor.
A
A
It's
like
too
much
work
for
you.
I
can
contact
like
other
people
and
also
ask
them,
but
I
think
I
think
you
you
did
some
volunteering.
You
convert
stuff
just
back
amd
and
you
like
on
most
of
the
calls
anyway.
So.
B
Yeah,
if
it's
not,
I
mean
I
don't
know,
it
sounds
like
it's
not
a
commitment,
so
that's
easier,
because
I
also
I
mean
I've
been
having
things
come
up
to
keep
like.
I
wanted
to
do
a
little
more
volunteering
that
I
didn't
have
time
for
so,
but
I
can
I
mean
I
think
it's
you
know
I
would
like
the
good
spec
to
be
written,
so
I
can
volunteer
sometime
hopefully
to
do
that,
especially
if
I,
if
it's
not
especially,
if
there's
no
requirement
going
in
that
I
can
I
can.
A
Yeah,
so
I
I
guess,
like
the
reason
why
it's
too
fast
here,
for
example,
is
because
ripple
is
slow
moving
and
somebody
need
to
ping
people
or
keep
them
like
motivated
if
stuff
is
not
merging.
If
there
is
nothing
like
important
agenda,
if
nobody
pinging
people
saying
like
guys,
we
don't
have
agenda
items.
Do
we
want
to
discuss
something
this
month,
for
we
just
like
cancel
this
meeting
so
like
organizational
stuff
and
most
part
is
not
time,
it's
attention
so
time.
A
Yes,
so
another
thing
I
like,
I
don't
want
to
be
to
be
with
project
to
have
boss
factor
of
one
same:
it's
not
available
for
like
next.
I
don't
know
a
year
or
something
you
can
decide
how
much
time.
Well,
you
know
like
work
life
balance
yeah.
So
so
I'm
basically
my
criteria.
It's
like
you
need
to
do
some
volunteering
job,
some!
That's!
Why,
like
I?
A
Actually
it's
really
great
that
you
help
with
spec
md,
because
we
discuss
it
like
multiple
times
and
nobody
like
got
actual
work
and
so
like
I'm
also
learning
how
to
do
how
to
facilitate
community
building
and
how
to
like
improve
situation.
But
one
thing
we
can
start
is
like
give
commit
rights
to
other
people,
because
too
many
open
source
projects
died
because
nobody
had
cometh
rights
like
an
original
after
disappeared
situation
with
craft
kill
foundation
is
better
still
like
foundation,
so
it's
not
disappearing,
but
at
the
same
time
it's
like.
A
A
A
Because
I
didn't
know,
maybe,
like
you
have
separate
accounts
for
your
work
at
ibm
and
for
your
personal
github
contribution,
I
gave
you
hey.
How
are
you
doing
yeah
good,
we're
actually
discussing
an
issue?
We
actually
skipped
agenda
because,
like
in
other
form
of
stock,
because
it
was
two
of
us
so
a
topic
is
that
we
need
to
figure
out
because
sam
is
not
available
anymore.
He
left
a
comment
and
he
organized
his
agenda
always
like
meeting.
A
He
created
agenda
item
an
issue,
but
he
started
from
now.
He
is
not
available.
So
I'm
looking
for
somebody
to
help
me
and
ask
morris
if
he
interested
in
volunteering
and
the
same
questions.
The
question
applied
to
you
if
you're
interested
in
like
creating
agenda
items
like
review
and
stuff
and
like
imagine
rfc
like
after
after
everybody
reviewed
and
everybody
agreed
more
as
an
rfc,
just
click
much
button.
C
Yeah,
I
think
so,
do
you
know
about
what
kind
of
time
commitment
there
would
be
yeah
so
we'll.
A
A
If,
if
as
you
can
allocate
as
much
time
as
you
can
allocate,
would
be
great
the
only
one
thing
I
don't
like
when
somebody
have
commit
rights
and
for
like
years
without
committing
because
it's
like
not
for
this
project,
but
in
general,
it's
like
security
concern
that
too
many
non
non-active
people
have
commit
rights.
A
C
Oh,
no,
that's
that
sounds
reasonable
and
I
I
wouldn't
expect
that
anybody
would
have
a
problem
with
that
at
all
and
to
answer
your
earlier
question,
I
think
that
that's
something
that
I
could
help
out
with,
so
I
want
you
to
take
the
steps
you
need
to
take
and
and
I'll
talk
to
sam
about
the
the
kind
of
involvement
that
he
was
having,
and
you
know
I
could
see
how
much
of
that
I
I
could
help
with
probably
most
of
it.
A
Okay
plus
another
thing,
if
I
disappear
for
some
reason,
like
one
thing
is:
if
you
want
to
you,
can,
and
if
you
have
time
you
can
go
for
basically
do
what
the
same
did
for,
like
all
previous
meetings,
go
through
agenda
items
and
ask
people
to
introduce
themselves
and
add,
like
new
agenda
items
for
us.
Another
thing
like,
for
example,
today,
I'm
on
company
retreat
and
so
like,
I
wasn't
sure,
about
quality
of
internet
or
like
adventure.
I
was
in
asia.
A
Some
asian
countries
and
quality
of
internet
was
also
bad,
so
sometimes
it
cannot
join
because
for
some
other
reason
so
it
would
would
be
great
to
have
somebody
to
to
back
up
yeah
yeah,
yeah,
yeah,
definitely
yeah,
and
if
you
interested
in
leading
discussions
the
same
way
sam
did
like
previously.
It
would
be
also
helpful.
A
B
I
think
we
can.
I
don't.
I
don't
have
any
other
questions.
I
think
we
could
start
and
okay
I
mean
I
just
try
to
I'm
sorry.
I
do
have
a
question,
but
it's
not
it's
not
like
a
procedural
question
like
this.
So
maybe
I'll
like.
If
we
finish
this
topic,
we
can
okay,
it's
the
next
topic.
It's
it's
just
one
level
down.
It's
still,
it's
still
not
the
real
details,
but
for
this
I
I
mean
I
don't
know
how
we
do
it.
But
let's,
if
you
give
us
committee
rates,
we
can
do
something.
B
A
So
if
you
have
ideas
submit
them
as
issues
and
we
discuss
them
plus
basically
like
another
thing,
since
we
don't
have
like
procedures
and
like
written
rules,
I'm
totally
okay,
if
you
do
something
that
we
did
previously
so
like,
if
you
have
precedent
of
like,
for
example,
imagine
rfc
after
discussing
it
on
working
group
or
after,
like
a
certain
period
of
time
like
a
month
and
everybody
reviewed.
So
I'm
totally
okay
with
like
doing
if
you
do
the
same.
A
If
you
want
to
do
something
like
totally
new
that
we
didn't
do
previously,
just
open
an
issue
or
if
it's
something
like
not
appropriate
for
a
nation,
you
can
find
me
on
draftkill
slack
and
I
try
to
answer
swark
in
24
hours.
So,
like
my
service
level,
agreement
is
24
hours
like
just
write
measure,
and
I
will
answer
like
any
question
related
to
maintenance,
graphql
or
ctp,
or
anything
quick
like
that.
So,
like.
A
B
A
B
A
If
you
don't
have
agenda
items
to
discuss
nobody
planning
to
discuss
anything
next
call,
we
can
figure
out
like
how
to
do
stuff,
asynchronously.
So
basically
start
discussion
and
moderate
discussion
and,
after,
like
I
think,
like
five
six
people
is
active
in
this
repo,
so
at
least
we
need
to
synchronize
with
them
asynchronously
for
issues,
and
you
can
use
like
cc
inside
the
issue
text
basically
the
same
way
as
some
did
like
class
time,
and
we
can
figure
out
what
to
do
with
this
working
group.
Maybe
like
at
this
point.
A
We
don't
need
goals
every
month
and
or
maybe
like
we,
we
experiment
with
fully
asynchronous
stuff,
so
I'm
actually
interested
in
hearing
what
what
other
people
want
to
say
on
this
topic
and
it's
also
a
good
experiment
in
massachusetts
communication.
If
nobody
like
answer
this
issue
or
let's,
let's
strive
for
opening
an
issue
and
describing
the
problem
problems,
we
need
to
to
make
this
ripple
more
active
in
a
sense
and
disquiet
community
graphical
overseas
becoming
active.
C
Yeah
in
general,
I
like
the
idea
of
an
asynchronous
communication
model
and
I
think
that
well
this
meeting
as
an
example,
there
might
not
be
interest
every
time,
and
so
we
would
set
some
kind
of.
C
Bar
you
know
a
minimum
amount
to
discuss
or
if,
if
there's
something
that
we
deem
appropriate
to
discuss
verbally
for
whatever
reason,
then
we
can
schedule
a
meeting.
I
I
don't
know
we'll
we'll
decide
what
it
takes
to
be
to
schedule.
A
meeting
is
what
I'm
trying
to
say.
A
One
thing
by
that
look
at
just
an
idea
and
when
you
open
an
issue
I
put
it
there,
I
duplicated
it
as
a
text.
One
problem
I
see
is
that
people
don't
take
time
to
review
stuff,
so
we
have
like
some
rfcs
and
pr's
like
for
one
time.
A
Instead,
I
we
can
try
some
model
where
vcc
we
have
like
a
list
of
interested
developers
and
we
see
all
of
them
and
if
they
don't
like
they
review
it
or
have
a
like
object,
something
for
some
period
of
time,
maybe
like
couple
weeks,
maybe
a
month,
we
just
match
stuff
because
without
I
feel
like
without
calls,
we
don't
have.
B
B
Into
I
think
this
is
or
is
this
kind
of
getting
towards
what
I
told
you
had
a
question
to
ask:
that's
like
not
real
technical
question,
but
it's
still
it's
not
organizing
meetings,
but
how
should
we
decide
what
actually
gets
merged
like?
I
feel,
for
you
know
the
last
six
months
or
something
like
you
said
we
we
often
have
somebody
with
the
pr
and
it's
pretty
good
and
it's
got
some
problems
and
they're.
Not
many
comment.
I
me
also
like
I
don't
put
many
comments
in.
B
I
put
some
comments
in,
but
you
know
we
don't
get
many
comments
from
people,
but
then
in
the
meeting
suddenly
there'll
be
a
whole
bunch
of
good
comments,
and
so,
if
we
did
just
push
ahead
before
the
meeting,
the
pr
would
not
be
as
good
as
if
we
had
the
meeting,
because
people
aren't.
If
you
don't
pay
attention,
that's
not
ideal,
but
I
also
don't
know.
Okay,
so
that's
one
input
and
then
the
other
thing
is
maybe
we
should
move
towards
more
merges.
B
I
I
don't
know
how
I
feel
about
it,
but,
like
we've
been
saying,
basically,
we
need
a
lot
of
consensus
to
merge
something.
I
think
the
alternate
approach
is
to
say:
if
nobody
objects,
we
go
ahead
and
merge
it
yeah,
and
then
we
can
have
more
pr's
to
undo
it
later.
If
it
was
bad,
you
know
what
I
mean
like:
let
less
confidence
in
what
we
merge,
but
it
it
forwards
the
conversation.
Otherwise,
when
we
look
at
what's
on
master,
it's
really,
you
know
it's
just
not
changing.
A
A
So
we
can
price
of
mistake.
Oh,
like
it's
not
big.
Until
we
we
get
out
of
draft
stage
until
we
start
asking
several
implementers
to
actually
implement
with
spec
right.
So
yeah
like
before,
I
think
like
before
we
pull
pluck
or
like
do
some
something
like
basically
publish
it.
We
can
go
one
by
one
review,
so
I
actually
feel
like
we
like.
In
a
sense,
we
adopted
strategy
from
graphql
spark
main
spec,
but
there
is
too
big
difference.
Main
spec
have
bigger
community
of
people
like
contributing
interested
in
it.
A
C
I
I
agree
as
well,
and
I
and
I
agree
for
the
same
reasons-
that
with
the
draft
spec
there's
nobody
that
will
immediately
be
affected
by
a
change
we
make
or
be
upset.
If
we
reverse
a
change
we
made
because
they
implemented
something.
So
I
think
that
we're
fine
for
now,
one.
A
Thing
yeah,
one
thing
I
will
advocate
is
that
since,
like
let's
understand
and
no
company
like
sponsor
your
activity
or
my
my
activity,
it's
like
everybody,
volunteering
their
own
free
time.
So
I
feel
like
we
need
to
for
every
pair.
We
need
to
get
some
some
like
period
when
people
actually
can
review
it,
so
I'm
like
and
for
hybrid
model,
so
people
can
discuss
and
review
and
make
pr
better.
A
A
A
A
C
A
A
I
need
to
have
time
frame
to
plan
my
time,
so
if
I'm
like
in
like
right
now
and
at
company
retreat-
and
I
get
email
about
new
pr-
should
I
preview
it
immediately
because
it
can
be
marching
like
a
day
or
two
or
do
I
have
like
time.
When
I
return
back
to
my
my
city,
I
can
like
open
it
and
without
like
any
pressure
to
review
it,
so
I
feel
like
we
should
have
minimal
timer.
So.
B
A
Shouldn't
be
much
faster
because
it
will
pressure
people
to
to
constantly
stay
up
to
date
and
it's
normal.
If
it's
you,
if
it's
your
work,
but
if
you
volunteer
you
and
free
time
to
work
on
something
and
if
we
try
to
do
asynchronously,
we
should
not
it
shouldn't
be
like
you
should
be
in
a
rush
to
review
stuff
or
your
who's
a
chance
to
voice
your
or
your
concerns.
C
I
agree
and
let
me
clarify
my
point:
I
wasn't
saying
that
we
could
be
fluid.
I
was
saying
that
we
would
not
be
required
when
the
stopwatch
goes
off
to
merge.
If
there's
no,
so
I
was
saying
that
we
should
allow
for
things
to
go
longer
on
a
case-to-case
basis.
If
we
deem
discussion
is
necessary.
B
B
B
B
Is
there
stuff
I
feel
like
there's
also,
I
don't
know
what
to
do
about
this,
but
there
there
is.
We
used
to
have
longer
calls
like
six
months
ago,
yeah
and
there
was
a
lot
decided,
but
there
was
also
like
a
lot
of
disagreement.
Where
we
didn't
come
to
decisions
you
might
have
better
recollection
of
all
of
it.
Like
is,
do
you
think
you
can
go
through
like
at
the
one
page
of
the
spec,
or
I
don't
know
like
how
do
I'm
wondering?
B
Can
you
help
us
maybe
remember
what
we
already
decided,
so
we
can
try
to
put
in
some
like
if
we
really
get
into
this
new
model,
where
we
say
heroes
go
in
and
then
we,
even
if
we're
not
sure
the
pure
goes
in,
and
then
we
can
change
it
later,
then
maybe
we
should
try
to
take
some
of
the
history.
We
decided
and
push
it
in,
even
though
there
are
objections
and-
or
you
can
give
people
the
two
weeks
and
see
if
people
object.
A
Okay,
so
one
thing
we
have
like
videos
on
youtube,
so
some
of
the
past
killer
over
http
working
groups
is
on
youtube,
so
you
can
watch
them.
I
think
everything
that
was
recorded,
including
in
this
one,
is
also
goes
to
youtube,
so
you
can
watch
them.
One
thing
I
think,
like
major
major
thing
that
changed
so
initially
I
advocated
for
non-breaking
release
so
meaning
like
every
every
graphql
server
implementation
is
compliant.
A
A
B
A
I
initially
it
was
lee,
came
up
with
this
idea
and
he
said
like
we
need
to
publish
stuff
that
we
like
how
it
should
work
instead
of
like
documenting
how
it's
work
right
now.
So
I
think
it's
the
main
consensus
that
we
achieved
in
including
me,
I'm
like
I'm
brought
to
spec
initially,
and
my
idea
was
to
combine
by
default
for
first
release,
but
a
couple
of
things
changed.
Respect
was
adopted
foundation
so
right
now
we
kind
of
have
like
some.
A
A
A
A
So
mime
type
give
us
a
clear,
clear
like
breaking
point,
meaning
like
it's
really
bad.
If
you
publish
something
which
is
look
like
graphql,
that
is
used
currently
but
differs
from
how
people
actually
implement
it,
because
you
cannot
like
it's
not
a
clear
break,
you
you
cannot.
You
cannot
check
if
server
support
like
prospect.
A
A
If
it's
like,
if
requests
don't
contain
the
application
graphql.json,
you
can
do
whatever
you
did
before
or
whatever
you
want
and
if
respond
yeah-
and
you
should
respond
to
this
application.
Graphql.Json
and
response
should
be
this
format.
B
A
Another
thing
about
error
codes:
we
also
agreed
to
yeah.
It
was
big
discussion
about
returning
500.
So
if,
if
your
return,
payload
doesn't
contain
data,
so
you
should
return
500
and
if
you
play
what
contain
like
partial
data,
just
some
some
data,
it
should
be
200
or
like
2
to
something
like
not
200
exact
but.
C
A
C
The
http
status
code
stuff
has
been
represented
in
pr's.
A
Okay
yeah,
so
this
is
like
main
discussion
we
had
like
in
the
last
half
a
year.
Please
would
put
them
right
away
from
from
a.
B
Memory,
I'm
just
I'm
remembering,
like
the
http
era
code.
Discussion,
for
example,
had
like
lots
of
almost
consensus
on
a
few
more
specific
points
that
we
didn't
quite
have
full
consensus
on.
Okay,
but
maybe
we
can
go
back.
I
don't.
I
don't
remember
the
details,
but
some
of
that
stuff
like
if
there
is
some
things
that
have
most
consensus
but
not
full.
Maybe
we
can
get
that
that
stuff
we
held
back
and
didn't
merge
into
into
the
master
branch,
and
maybe
we
could
go
back
and
actually
merge
some
of
that
stuff.
A
B
A
I
think
we
need
to
do
that
because,
like
our
current
tempo
is
good
for
for
first
release
pack
so
like
release
something-
and
we
try
to
be
very
careful,
but
it's
it's
not
working
for
prerelease
pack,
because
we
like
in
current
tempo,
will
ship
something
in
like
year
or
two
and
and
that
point
where
people
will
switch
to
http
2
or
some
some.
I
don't
know
like
so
every
year.
We
we're
losing
some
relevance
of
this
fraction
sense.
So
I
think
it's
good
to
be
to
be
more
aggressive.
B
I
agree
yep
that
makes
sense
to
me.
I
think,
you're
right.
I
think
we
are
we're
already
getting
to
the
hdb2
time.
So
it's
anyway,
I
agree
it's
probably
better
to
get
something
out,
but
on
the
other
hand,
you're
right
that
we
we
can't
actually
release
something
that
we're
not
sure
about,
because
then
it
gets
into
the
problem
of
needing
to
be
very
careful
about
everything.
So,
but
I
think
what
we're
all
getting
is
that
the?
B
A
Yeah
and
at
some
point
so
we
also
had
discussion
at
some
point.
We
will
contact
when
we're
more
or
less
sure
between
of
active
people
on
the
repo.
It's
like
working
thing.
It
makes
sense,
we'll
reach
like
a
poor
guys
and,
like
some
other,
like
some
some
other
communities,
and
some
of
them
are
represented
in
this
group,
mikhail
forms
like
seashore
community
from
hot
chocolate
he's
like
active
in
this
group.
So
it's
a
at
the
point
where
we
have
something
that
makes
sense.
He
we
can
ask
people
to
implement
it
and
get
feedback.
A
A
Yeah
and
another
thing
about
this
point
that
we
almost
agree
since
we
have
our
videos
on
youtube,
if
somebody
volunteers
actually
to
watch
them
and
note
with
things
that
we
agreed
on
some
of
them
captured
inside
the
notes.
A
But
I
feel
like
watching
a
video,
give
you
more
idea
of
on
consensus
and
how
people
felt
about
stuff
during
discussion.
So
if
you
interested
in
doing
that,
it
would
be
great-
or
you
can
create
issue
about
that
and
like
help
want
that
issue
and
some
somebody
who
interested
in
that
can
like
watch
it
and
summarize
stuff.
A
We
also
have
notes
from
the
meetings,
yeah,
yeah
and
also
you
can
process
notes
here.
But
for
for
some
recent
meetings,
I
think,
like
three
three
or
four
last
meetings,
we
actually
have
a
video.
B
B
A
Yeah
yeah
basically,
but
and,
as
you
said
like,
we
had
some
almost
agreement
on
some
topics
and
I
think
like
it
would
be
helpful
to
have
a
topic
listed
and
if
somebody
objected
like
mentioned
like
like
what
was
concerned
about
and
like
a
person
who
was
that
concern
so
like
when
we
create
rfc,
we
can
try
to
address
concerns
if
they
like.
If
we
agreed
with
these
concerns
and
also
targeted
person
asking
like
do,
is
you
I
disagree
with
that?
And
can
you
please
review,
and
can
you
have
more
details?
A
I
will
think
about
that
and
when
you
post
the
issue,
I
think
about
that
and
will
answer
the
only
thing
I
need
some
stuff
to
prepare
for
working
group
on
thursday,
some
some
action
items
that
I
promise
to
do
and
like
I
need
to
finish
them.
So
I
will
probably
write
something
on
saturday
sunday.
A
B
B
A
A
Had
a
lot
of
text
and
a
lot
of
stuff
and
it
was
hard
to
agreed
on,
but
when
smaller
chunk
was
extracted
from
it
and
we
actually
emerged
so
one
of
the
two
and
toe
box
for
getting
stuff
merged
is
to
extract
thing
and-
and
I
would
even
suggest
that,
if
original
after
don't
have
time
or
interest
to
extract
stuff,
that,
like
everybody
agrees
on,
it
can
be
like
anybody
like
any
volunteer
who
wants
to
do
actual
job
of
extracting
like
a
non-controversial
part
and
creating
separate
pair.
So
we
shouldn't
be
blocked
by
pr.
B
A
B
B
Yeah,
I
agree
and
for
th
for
the
other
one,
the
one
of
you
know.
Maybe
we
just
merge
it
anyway.
I
I
don't
remember
the
details,
but
I
am
motivated
somewhat
from
that.
Like
the
error
code
discussion
or
the
the
there's
another
discussion
we
had
also
similar,
where
like
it
did
seem,
there
was
a
by
the
time
we
had
to
go
for
full
consensus.
B
B
I
would
want
people
still
to
discuss
the
remaining
part,
but
if,
even
though
it's
slightly
controversial,
if
the
whole
thing
just
gets
merged
like
sometimes
that
might
be
the
right
thing
to
and
then
have
the
discussion,
you
know
what
I
mean
like
from
a
base
of
we
merge
like
or
instead
of
everything,
always
turning
into
shoulds
and
no
musts
and
like
there's
nothing
actually
in
the
spec
at
all.
It's
not
it's
just
a
it's
a
non-normative
one,
page
of
text.
B
Eight
out
of
ten
people
like
them
or
nine
out
of
10
people
like
them
and
then
and
then
let's
continue
the
discussion,
because
I
one
person
has
a
strong
objection:
they're
they're,
quite
possibly
right.
So
I
don't
want
to
cut
that
off,
but
but
at
certain
point
becomes
hard
when
nothing
merges,
then
there's
nothing
to
continue
the
discussion.
C
Are
you
asking
if
there
are
individuals
with
the
ability
to
override.
B
No,
I
just
kind
of
see
if
there's
like.
If
we
go
through
a
discussion-
and
it
seems
like
you
know,
everybody
mostly
agrees,
but
there
is
a
little
bit
that
a
couple
of
people
disagree,
but
most
other
people
do
agree
like
it.
I
don't
know
just.
I
think
our
our
prior
plan
of
action
was
until
we
have
a
hundred
percent
agreement.
B
We
don't
merge
it
at
all
and,
like
like
yvonne's
saying
it's
really,
we've
said
people
should
take
the
consensus
part
of
it
and
that,
but
sometimes
that's
taken
like
two
months
to
get
the
one
consensus
line
merged
and
it
leaves
out
a
whole
bunch
of
stuff
that
was
mostly
consensus,
which
again
I'm
not
trying
to
get
that
into
the
final
spec
version.
I'm
just
thinking,
maybe
if
it
merges
to
master
it'll,
encourage
more
discussion.
A
So
what
I
would
suggest
it's
to
go
iteratively,
so,
let's
start
with
process
and
when
we
have
actual
like
pr
that
is
stuck
on
and
somebody
object
and
we
go
through
like
psycho
discussion
and
it's
feel
like
we
making
circles.
So
if
discussion
is
not
going
into
circles,
it's
like
helpful
discussion
because.
A
B
I
don't
know,
maybe
I
didn't
want
any
more
rule,
just
it's
just
the
one
line.
I
already
read
to
you
that
I
thought
that
it's
kind
of
I
think
it's
kind
of
saying
that
at
a
high
level,
the
high
level
idea
is
this:
this
it's
not
a
hard
and
fast
deck.
Yet
it's
not
as
high
a
bar
to
merge
right,
and
so,
if
they're,
if
something
comes
up,
it
just
means
we
can
fall
back
to
them,
say
look
it's.
B
C
C
That,
though,
because
merging
into
master
does
actually
mean
that
it
could
make
it
into
the
spec
and
if
nobody
ever
has
anything
to
say
about
it,
but
you
know
missed
that
it
was
merged
for
whatever
reason,
then
it
will
make
it
into
spec.
So
that's
not
necessarily
solely
encouraging
discussion.
It
is
semi
dangerous.
A
A
A
It's
not
like
yeah,
because,
as
you
say,
right
now,
it's
look
like
every
pr
is
like
pr
that
at
something
in
final
spec.
By
saying
that
you
have
a
period
of
time
that
you
can
submit.
A
C
C
Even
to
go
more
specific
than
that
to
say
we
want
to
be
semi-aggressive
in
merges,
and
so,
if
somebody
is
an
outlier
and
disagrees
with
the
pr,
but
so
many
people
agree
with
the
pr
and
we
want
to
merge
it,
we
will
send
a
notification
that
says,
given
that
we
have
one
outlier,
this
will
be
emerged
in
you
know
in
a
certain
time
period,
and
then,
if,
if
we
don't
hear
anything,
then
we
encourage
separate
pr
to
make
the
changes
that
they
want
to
see.
A
B
Figured
out
I
like
reviewing
the
open
pipeline
of
prs,
but
also,
I
think
it's
reviewing
the
whole
spec.
It's
kind
of
saying,
yeah
we're
starting
to
treat
the
spec
on
the
master
branch
a
little
more
of
a
draft.
It
was
always
labeled
draft.
B
C
B
Notes
here
I
just
sent
in
the
chat.
This
is
what
I've
got
written
up
in
the
issue
I
could
open.
I
also
have
a
line
saying
the
three
of
us
discussed
and
I
copied
everybody
else.
Yeah
we're
here.
A
One
thing
I
remember,
we
actually
discussed,
and
you
mean
more-
is
brought
like
last
time
about
publishing
a
spec
is
to
actually
explain
what
draft
mean
and
publishes
spec
as
like
rendered
html,
but
we
agreed
to
change
draft.
I
don't
remember
what
we
agreed,
but
to
some
other
like
text
more
explaining
more
what
job.
B
A
Yes,
I
don't
want
to
like
somebody
because
it
will
aggravate
graphql
server.
Implementers
like
it,
can
motivate
them
to
give
feedback
about
or
open
pr
to
exchange
or
remove
stuff.
But
in
a
sense
I
think
we
need
to
clarify.
If
we
go
with
strategy
of
a
live
document,
we
need
to
point
it
out.
It's
wired
document
and
it
will
be
reviewed
before
final
release
and
nothing
is
like
fixed.
Everything,
can
change
before
final
release
and
plus
don't
treat
it
as
like
as
mandatory
spike,
as
prescribing
of
all
on
how
you
should
implement
graphql
servers.
A
C
Have
a
release
process
documented,
you
know
with
first
we
go
to
draft,
then
we
review.
Then
we
call
it
something
else
and
then
the
final
release
or
anything
like
that.
A
A
C
Now
that
we're
part
of
the
officially
a
part
of
graphql
working
group
that
we
could
look
to
see
what
documents
they
have
and
follow
the
same.
A
So
it's
problem,
solving
graphql
working
group
is
main
one.
We
we
try
to
make
release
for
for
like
now
for
two
or
two
years
already
of
three
years
already
so
like
it's
not
a
place
that
you
should
learn
about
releasing
stuff,
because
in
main
group
we
also
have
this
problem.
It's
a
little
bit
different
because
it's
like
not
for
surgeries,
but
so.
C
Consistency
there
I'm
not
referring
so
much
to
timelines
more
nomenclature,
something
that
has
a
designation
at
a
certain
level
so
that
people
would
understand
when
they
should
start
to
implement
things.
A
I
I
think
we
can
actually
use
this
like
wine,
you
know
wines
that
currently
say
working
in
draft,
so
morris
submit
pr
explaining
like
its
current
status
and
our
strategy.
So
basically,
when
this
one
is
saying
we
encourage
you
to
impo,
it's
still
a
draft,
but
we
encourage
you
to
implement
it
and
give
us
feedback.
B
B
You
said,
a
live
document
that
can
change
dramatically
backwards,
and
you
know
I
don't
know
what
you
say,
but
I
can
try
to
come
up
with
some
text
and
then
and
then
say
you
know
at
some
point
in
the
future
it
should
switch
to
is
to
switch
to
being
a
a
formal
draft
for
a
spec
and
and
then
go
through
normal
revisions
as
a
draft
of
a
spec
before
it's
released
kind
of
clear
right
like
it's,
it's
not
we're
not
at
the
draft
of
a
spec,
yet
we're
at
the
live
document
trying
to
come
up
with
the
first
draft.
A
A
Maybe
this
one
is
draft.
Next
one
is
experimental
when
it's
still
like
seo
is
not
a
final
spec,
but
we
encourage
people
to
experiment
and
when
we
will
have
release
and
if
somebody
like
some
some
short
description
of
stages,
I
don't
feel
like
it's
a
good
time
to
to
describe
all
criterias
for
moving
to
stages,
but
at
least
we
have
ideas.
B
C
B
So
like
so,
do
you
want
like
to
go
with
gabriel's
earlier
point
of
matching
the
graphql
spec?
I'm
not
sure
what
the
graphical
factor
has
for
all
the
stages,
but
the
current
thing
has
been
a
draft
and
when
they
say
draft
it's
much
much
more
formal
than
what
we
have
here.
So
maybe
this
should
not
even
be
a
draft
yet
and
the
you
know
once
we
stop
loose
with
it,
we
should
call
it
a
draft,
but
for
right
now
we
should
be
sling
before
draft
stage.
B
A
C
C
Referring
to
stages
for
the
spec,
because
we
are
we,
we
would
aggressively
merge
prs
into
a
spec
and
we
want
to
accurately
communicate
as
simply
as
possible
to
server
implementers
that
they
could
pay
attention
to
this
and
see
the
progress
of
our
discussions,
but
it
by
no
means
feel
that
this
is
necessary
for
them
to
implement
by
a
certain
date
or
anything
like
that.
C
But
once
we
reach
a
certain
point
in
our
process,
then
they
should
start
considering
it
in
more
formally
and
start
working
to
implement
the
things
in
our
spec
in
anticipation
of
its
being
released,
you
know
for
them
they
look
at
this
and
say
yes.
Most
of
this
is
highly
likely
to
change
and
then
at
some
point
the
likelihood
of
change
becomes
a
lot
more
or
a
lot
more
slim,
that's
the
point
where
they
should.
You
know,
start
thinking
of
implementing
and
then
it's
and
the
the
last
stage
is
okay.
We've
finalized
this.
C
A
C
University
for
them,
though,
I
think
the
rfc
stage
stages
are
are
more
appropriate
because
the
spec
doesn't
get
released
as
a
whole.
If
you
add
it
to
the
spec,
it
is
now
part
of
the
main
spec,
but
for
us
no,
no.
A
B
A
separate
process
of
really
small
spec,
so
that's
what
I'm
saying
when
the
rfc
is
getting
merged
in
then
the
graph
kills
there.
They
go
into
the
draft
graphql
spec,
which
is
called
draft,
and
then,
after
like
several
years
at
some
point,
then
there
can
be
a
decision
to
promote
that
draft
to
be
an
actual
released.
Spec.
C
Yeah
I
see
okay,
so
yeah.
So
then
I
think
it
could
be
much
more
simple
for
us,
then,
which,
like
you,
said
earlier
morris
that
we
have
to
come
up
with
a
name
for
what
our
spec
is
now,
because
it's
not
what
people
know
of
as
a
draft
and.
B
And
I
think
it's
that
it
might
just
be
that
simple.
We
just
have
a
name
which
I
don't
know
what
it
is,
but
some
name
to
describe
now,
which
we
all
know
on
the
three
of
us
understand
what
it
means
and
then
at
some
point
say
we'll
promote
it
to
draft
and
once
it's
draft
that
means
don't
merge
anything
unless
we're
really
sure
to
master
branch,
get
people
to
review
everything.
That's
there
to
get
consensus
around
the
text,
that's
there
and
then
eventually
turn
that
draft
into
a
released
spec.
A
So
I
would,
I
would
say,
like
right
now
we
in
the
face
of
yeah.
I
agree
about
this
idea,
so
I
would
say
like
right
now
what
we
discussed.
It's
like
basically
editing
content
and,
like
figure
out
the
content
that
most
most
people
are
greeds
and
just
add
them.
So
it's
like
in
a
sense
brainstorming
for
us
for
us.
A
I
actually
think
we
can
add
a
couple
of
words
if
we
put
them.
That's
fine,
yeah,
yeah,
yeah
yeah,
I'm
not
I'm,
not
a
native
speaker.
So
I'm
like
totally
open
like
to
any
suggestion
and
you
can
discuss
it
an
issue
and
some
people
actually
agree
with
naming
bench
is
really
great
with
coming
with
good
names
so,
and
I
think
like
so,
it's
like
tiny
detail.
A
B
A
C
C
Think
that
just
choosing
a
simple
word
makes
the
most
sense
to
show,
and
we
can
even
put
it
in
a
document
that
says
we
chose
this
word
because
we're
not
ready
for
a
draft.
B
B
B
No,
no,
the
ones.
I
said,
I've
brainstorming
stage.
I
think
that
one
was
from
from
yvonne
brainstorming.
B
Or
open
state-
I
I
I
don't
know
the
right
word,
I'm
I'm
very
happy
whatever
people
are,
I'm
happy
with
preliminary.
I
think
the
thing
you
said
is
the
key.
The
key
is
to
say
like
that.
If
I
can,
I
can
try
to
write
some
pr
that
just
gets
it
like.
This
is
not
yet
in
draft
stage
like
I
think
that
kind
of
communicates
at
all.
This
is
not
yet
a
draft.
C
Yeah,
it's
it's
more.
This
is
what
this
word
means
from
here
on
out
that
you
know
when
you
see
this
word.
This
is
what
to
expect.
B
B
At
this
point,
every
merge
to
master
would
need
strong
consensus.
C
Yeah
right
the
the
purpose
of
draft,
as
far
as
I
can
see
it
is
we
think
this
is
ready.
We
just
want
to
make
sure
and
we
could
modify
it
if
problems
arise,
but
we
are
not
going
to
add
anything
new.
A
Yeah,
I
agree
what
one.
B
A
A
Agree
with
these
two
points,
one
thing
I
would
add
like
when
we
review
opr's,
so
it's
like,
should
be
free
option.
We
make
measured
rejected
or
say
it's
like
post
release
so
like
we
can
device
create
some
like
milestone,
github
or
some
other
mechanism
to
mark
or
some
label
to
mark
bears
that
yeah
we're
interested
in
it.
But
we
don't
think
it
should
be
in
like
first
release.
C
C
Could
do
that
and
we
could
play
around
with
labels
a
lot
in
the
future.
A
C
Okay,
not
close
request
changes.
C
Okay,
am
I
I
mean,
of
course
they
could
be
closed
as
well.
So
maybe
that's
a
fourth,
but
that's
what
I
think
you
meant
when
you
were
bringing
this
up,
you
could
accept
and
merge,
or
you
could
request
changes.
C
Okay,
I
see
yes
you're
right
then
so
merge
rejec,
I
mean
merge,
close
or
label
for
a
future.
B
B
Because
it
seemed
orthogonal
yeah,
I'm
fine,
then,
like
I
mean
I
I
don't
I
like,
I
can't
go
either
way.
So
I'm
asking
you
but
the
I
think
the
main
issue
I'm
trying
to
get
is:
maybe
we
can
get
consensus
around
that
we
are
at
a
preliminary
stage,
not
a
draft
stage.
Therefore,
we've
got
different
rules
for
now
and
if
we
can
get
consensus
on
that,
then
the
whole
spec
can
start
moving
more
quickly
and
it's
kind
of
a
separate
question
of
like
how
will
we
eventually
disposition
prs.
A
A
C
Yes-
and
I
like
that,
what
we're
discussing
today
is
ultimately
going
to
be
in
a
pr
so
that
we
could
get.
We
could
promote
asynchronous
discussion
about
our
asynchronous
discussion.
B
A
So
I
think
right
now
we
have
a
good
good
list
of
points.
I
I
wouldn't
over,
complicate
it
personally
suggestion,
because
the
more
non-essential
points
yet
the
bigger
like
discussion
and
like
disagreement
about
stuff.
So
I
think,
like
this
set
of
points
that
morris
wrote,
it's
like
show
like
enough
to
bootstrap
his
community.
What
what
do
you
think
agreed.
B
All
right,
I've
also
have
taken
more
notes,
and
I
got
enough.
I
made
a
summary
line
before
the
proposal,
so
here
it
is
summary
we're
trying
to
separate
preliminary
stage
from
draft
stage
to
get
the
spec
moving
more
quickly
until
we
get
to
draft
stage
yep
how's
that
so,
if
somebody
reads
only
one
line,
maybe
they'll
read
that
one
line.
B
A
Another
technical
note:
can
you
so
maurice
I
have
your
email
for
adding
as
as
a
committer
on
github.
So
gabrielle
do
you
have
like
they
have
email
public
on
github
or
can
you
send
it
me
some
hoes
that
that
so
I
I
make
you.
C
I
have
are
you
asking
for
my
github
handle.
C
A
You
yeah,
so
can
you
can
you
just
in
case?
Can
you
both
ping
me
on
slack
slack,
I'm.
A
So
be
in
communication,
if
I
like
I,
I
I
would
try
to
figure
out
how
to
add
you,
I'm
not
paying
quick
a
lot
of
people,
so
I
don't
have
a
lot
of
experience
with
adding
new
committers.
A
So
I
can
ping
you
if
something
goes
wrong
and
or
if
I
need
your
email
or
other
stuff,
can
you
just
to
accept
some
random
message?
Yeah,
no
thanks,
okay,
yeah
yeah
yeah,
so
yeah
great.
So
I
will
try
to
add
tomorrow
today
I
will
join
my
colleagues
because
I
have
company
retreat,
but
tomorrow
I
will
add
you
as
committed
to
repo
and
we
we
can
discuss
apr
and
do
other
stuff.
A
Yeah
yeah
so
yeah,
yeah
yeah.
It
was
great
thanks
for
one
year
confess
to
actually
taking
the
time
to
join
it.
I
think
it
was
like
super
productive
in
a
sense.
At
least
we
have
like
a
plan
to
bootstrap
and
to
to
solve
a
core
issue
of
this
community.
In
a
sense,
you
will
see
a
result
and
I
would
definitely
in
couple
of
days
I
will
definitely
like
review
and
comment
on
this
pr
and
we
will
try
to
continue
asynchronously
and
see
how
it's
work.
A
B
Connected
and
it
might
take
some
time,
we
have
to
wait
a
little
bit
to
see
if
people
have
comments
on
this
issue,
but
then
maybe
in
a
couple
weeks,
I
could
take
any
feedback
and
turn
it
into
a
pr
and
then
also
once
we've
got
a
pr.
Then
then
we've
got
the
new
process,
so
we
can
start
doing
more
other
things
more
quickly.
A
A
So
what
I
would
encourage
you
to
create
like
some
pr
against
like
is
the
existing
document
or
a
new
document
outlining
like
with
points,
and
I
think
it's
better
to
discuss
like
such
stuff
as
pr,
because
people
can
suggest
like
edits
and
they
can
comment
on
individual
lines.
So
discussion
is
more
productive
and
more
like
and.
B
A
B
Stuff,
otherwise,
otherwise
it's
a
big
discussion
on
how
to
make
a
pr
about
making
prs
right
yeah.
But
if
it's,
if
it
works,
then
it
could
be.
You
know
it
could
save
six
months
twelve
months
to
to
release
suspects.
Hopefully,
hopefully
it's
good
yeah.
I'm
excited
very
good.
Thank
you.
Lester
excited.
That's
great
yeah
thanks
thanks
gabriel
thanks
evan.