►
From YouTube: GraphQL.js Working Group - 2021-09-29
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
A
A
B
B
C
B
D
D
Yeah
fair,
fair
yeah,
we
got,
we
got
people
in
london
and
hamburg,
so
yeah.
That's
like.
B
E
B
And
we
basically
follow
the
same
same
processes,
graphql
working
group,
just
less
formal,
because
usually
it's
only
a
couple
of
people
hi
as
a
help.
If
I
sorry,
if
I
mispronounce
your
name.
B
So,
let's
start
from
item
number
one
yeah
to
participate
in
this
group.
You
need
to
sign
specification,
membership,
agreement,
participation,
guideline
and
code
of
conduct.
B
Hi
everyone.
So
next
item
is
introduction
for
changes.
So
let's
go
in
the
same
order.
We
have
an
agenda
and
we
can
can
introduce
afterwards.
So,
let's
start
from
me,
I
I
joined
apple
a
month
ago
and
I'm
maintainer
of
craftkil
js,
one
of
the
maintenance
of
craftkiljs.
D
Yeah
yeah
hi,
I'm
I'm
alex
I'm
at
yelp,
I'm
currently
championing
an
rfc
for
a
client
controlled.
Nobody,
no
client,
controlled,
nullability
syntax
and
I'm
in
san
francisco.
E
Hey
I'm
jordan.
I
work
at
facebook
on
the
relay
team
or,
I
guess
reacts,
data
team
working
on
relay
and
I
worked
on
the
at
required
annotation,
which
relay
added,
which
has
some
parallels
with
the
rfc
that
alex
mentioned.
So
I'm
here
to
see,
if
I
can,
you
know,
help
with
them,
I'm
also
in
the
bay
area.
B
B
I
I
think
yes
sahaba's
disconnect,
I
think,
he's
connected
at
one
point
and
yeah.
Sorry,
next.
B
So,
let's
move
forward
yeah,
we
usually
don't
do
note-taking
because
we
usually
have
a
quest
packed
agenda
at
some
point.
We
probably
need
to
start
doing
that.
But
at
what
point
we
usually
skip
with
item
yeah
review
agenda
so
we'll
start
from
knowability
implementation
and
release
status.
B
B
No
so
yeah
action
items
so
hit
anything
like
on
my
side.
It
was
interesting
month.
I
had
a
vocation
initially
and
released.
There
was
a
new
job
with
the
power
so.
B
D
Yeah
for
sure,
so
we
got
a
rfc
implementation
that
I'm
I'm
planning
on
sort
of
opening
for
public
review
by
the
next
working
group
meeting,
and
I
want
to
bring
it
here
and
and
and
get
all's
thoughts
on
it
first
to
make
sure
there's
no
like
glaring
issues.
D
Would
it
be
helpful
if
I
briefly
went
over
the
the
proposal.
First.
B
D
B
D
Alrighty
yeah,
so
the
the
concept
is
basically
that
we
want
to
allow
people
who
are
writing
graphql
queries
to
say
that
certain
fields
are
non-null
like
you'd,
be
able
to
say
in
the
schema,
but
just
for
for
the
specific
query.
The
purpose
of
that
is
that
sometimes
you're
writing.
Queries
that
are
working
are,
are
being
used
for
features
and
those
features
do
not
work
without
a
certain
field,
so
we
want
to
be
able
to
have
a
way
to
fail,
fail
out
of
that
fail
early.
D
D
The
syntax
we're
using,
for
that
is
an
exclamation
point,
so
you
put
a
an
exclamation
point
after
your
field
and
it
would
do
the
the
thing
I
just
said.
We
have
also
lee
had
a
suggestion
to
also
include
a
question
mark
syntax,
which
would
do
the
opposite.
It
would
take
a
non-nullable
field
and
make
it
nullable
his
use
case,
for
that
was
for
error
boundaries.
D
So
being
able
to
say
you
know
if
you
mark
this
field
non-nullable
and
it
comes
back
null,
it
would
bubble
up,
but
it
would
only
bubble
up
to
the
the
point
where
you
have
a
question
mark.
That's
yeah,
that's
that's
the
the
whole
concept.
Any
questions.
B
So
I
read
your
some
of
your
documents.
I
think
you
have
google
docs
with.
B
Currently
is
not
solved
or
like
you're
working
on
so
as
I
understand
you
don't
want
to
include
yeah
this
one
least
so
much
so
it's
out
of
scope
all
right.
D
Yeah,
so
it
would
be
nice
to
have
a
solution
for
it,
but
it
sounds
like
the
the
people
that
we're
talking
to
right
now,
which
is
relay
and,
and
then
netflix
also
has
a
directive
that
they're
using
neither
of
them,
have
solved
this
problem
and
it
hasn't
come
up
yet
for
them.
Okay,
so
the
plan
makes
sense
yeah.
B
Yeah,
it
just
makes
sense,
yeah,
yeah
so
and
another
one
you
want
to
have
like
different
semantics
between
schema
enforcement
ability
and
query
enforcement.
No
ability
right
is
a
different
or
same
because
in
this
document
it's
like
mentioned,
but
without
too
much
details.
D
It
is
it
is,
it
is
basically
the
same.
So
there's
there's
an
alternative
that
we
talk
about
here,
which
would
be
non-destructive
and
said
it
would
just
return.
An
error
like
the
the
server
would
return
an
error
to
the
client
telling
the
client
that
you
know.
D
We
expected
this
field
to
not
be
null
and
it
came
back
null
talking
with
relay,
though,
and
jordan.
You
can
speak
to
this.
If
you
want
to
it,
sounded
like
they,
they
preferred
the
bubbling
up
option,
so
the
semantics
are
are
exactly
the
same
as
as
the
as,
if
you
were
market
non-nolan
schema.
B
So
you
have
draft
pr
on
graphql
js
or
is
it
still
like?
D
B
B
D
Gotcha,
okay,
yeah:
I
can
do
that.
We're
basing
this
off
of
like
the
main
branch
right
now,
so
it
would
be
on
top
of
16.0
does
it
is
that
is
that
the
is
that
the
correct
choice,
yeah
yeah,
correct
one.
B
B
B
Awesome
yeah,
so
it's
not
required
if
some
somebody
volunteered
to
do-
and
I
I
can
measure
it,
but
it's
totally
no
requirement
so
you're
doing
like
correct
thing
based
not
mine,
especially
since
this
release
is
huge,
so
we
switched
to
typescript.
So
he
did
a
lot
of
work
on
that.
So
basically,
like
entire
code.
D
D
B
B
It's
stage
one
right,
yeah
yeah,
so
we
cannot
merge
it
anyway
until
stage
two,
so
I
think
it
makes
sense
for
people
to
discuss
like
semantical
feature
and
later
I
can
like
review
it
and
hopefully,
by
that
time,
by,
like
in
next
couple
of
days,
we'll
figure
out
what's
details
in
release
1600,
so
your
your
change
will
come
as
16
1,
0,
okay,
the
next
feature
released.
B
E
Yeah
I'll
just
chime
in
because
alex-
and
I
have
been
having
some
good
conversations
that
I
think
from
the
relay
perspective,
were
like
definitely
in
favor
of
of
this
problem
being
addressed
with
syntax.
E
But
I
think
we
also
foresee
that
this
proposal
is
going
to
sort
of
promote.
Another
challenge
of
of
isolated
fragments
in
that
like
having
to
have
every
field
in
a
single
query.
Agree
upon
the
sort
of
non-nullability
of
a
field
is
a
is
a
pretty
big
limitation
of
how
useful
this
can
be,
but
we
think
that
it's
okay
to
like
accept
that
limitation
and
and
foresee
that
it
will
help
us
move
forward,
potentially
in
the
future,
with
a
some
like
fragment
isolation
proposal
in
the
future.
E
D
B
B
B
B
Connected
to
it's
like
minor,
breaking
changes,
I
I
would
say
so,
for
example,
right
now
we
have
like
validation
function
and
by
default
it's
return
as
many
errors
as
you
want,
so
it
can
return
a
thousand
or
two
thousand
zero,
so
like
10
000
errors
and
we
have,
but
we
have
argument
for
max
errors
to
limit
it.
It's
just
like
not
every
tool
is
using
it,
so
idea
is
to
enable
it
by
default.
B
So
basically,
there
is
no,
not
every
two
properly
sanitized
graphql
schema,
so
idea
is
to
add
with
check
inside
constructor,
so
it's
not
affecting
anybody
basically,
but
technically
it's
breaking
change,
so
I
I
want
to
get
it
into.
I
can
actually,
I
think
what
I
do
is
to
cut
release
right
after
we
score.
I
will
cut
release
at
c4,
so
people
can
test
it
and
I
will
add
this
two
parts
on
top.
B
So
and
another
thing
I
need
to
do
also,
because
I'm
responsible
for
the
power
on
migrating
to
six
and
zero
zero.
I
want
to
ensure
that
I
personally
will
not
have
any
problem
migrating
a
power
repos
to
to
new
versions,
so
I
need
to
surround
these
checks.
Basically
likes
scope,
office
release
defined
everything
is
ready.
B
B
So
the
procedure
is,
I
will
do
next
release
candidate
and
I
will
ping
like
everybody
in
this
feedback
issue,
everyone
who,
who
left
feedback
there
for-
and
I
will
ask
everybody
to
recheck
like
including
you
and
like
woody,
and
I
will
personally
check
this
really
scandal
on
guild.
If
this
is
will
work
for
everybody,
we
will
just
release
the
same
rc
as
six
zero,
zero.
A
B
I
promise
it
for
in
in
the
plan
for
1600,
but
it's
end
up
being
a
more
complex
problem
and
another
another
thing
that
is
cut
out
is
dino
support,
but
dino
is
not
tied
to
npm
releases
or
semantic
version
unite,
always
try
to
commit,
so
we
can
figure
out
what
we
have
was
one.
What
remaining
issue
we
could
figure
out?
It
just
wanted
to
say
that
from
our
initial
goal,
it's
like
to
to
go
that
that
with
is
postponed
to
next
releases.
B
I
think
then,
the
releases
for
them
that
we
cannot
support
without
any
breaking
change
at
all
for
years.
I'm
not
sure.
Maybe
yes,
we
can.
Maybe
we
can
edit
a
subsequent
release,
but
maybe
it
will
require
1700
and
here's
like
original
issue,
with
the
release
plan.
F
B
A
B
B
B
B
Yeah-
and
I
think
part
of
this
discussion
here
that
is
sub
sub
point
is
that's
ahead-
is
proposal
for
a
schedule.
A
So
what
I'm
suggesting
is
so
we
know
like
we
started
the
release
16
plan
like
a
long
time
ago,
and
we
still
haven't
come
to
a
release.
Many
things
happen,
so
I
I
suggest,
like
we
said
we
discuss
every
time.
You're
gonna
cut
a
release,
but
we
are
falling
short
on
every
single
time.
So
I
think
we
we
need
like
a
solid
plan
like
we
need
a
deadlines
rather
than
like
a
plan
that
we
are
going
to
cut
release
on
this
date.
A
So
if
esm
you're
not
supporting
it,
we
should
just
plan
it
out
that
next
working
group-
or
maybe
even
the
one
after
that-
that
we
are
going
to
get
the
esm
support
in
that
or
like
dino
support,
and
that
so
we
know
like
what
what
we
are
trying
to
do
like
and
it's
a
it's
more
about.
Trans
transparency.
A
A
B
A
A
A
E
E
A
B
Like
a
bigger
problem
yeah,
I
partly
like,
I
think
we
should
separate
a
couple
of
things.
We
cannot
estimate
spec
proposals.
So
if
people
work
on
something
new
for
spark
it's,
we
should
not
work
with
process
because
but
at
the
same
time,
if
it's
infrastructure
like
migration
to
typescript
or
better
error
class,
cleanup
error
course
or
yeah,
some
support
arduino
support
some
big
infrastructure
things.
B
A
B
B
Figure
out
export
policy,
like
I
at
least
like
support
policy
needed
to
read
me.
I
think
we
can
just
if
yes,
it's
my
suggestion.
If,
if
anyone
have
proposal
for
post
question
first,
I
think
we
need
to
define
a
set
of
questions
and
have
like
ideas
for
for
what
people
expect,
because
I
don't
think
we
need
to
copy
node.js,
for
example,
support
period
of
I
don't
remember
how
many
years
like
two
three
years,
I
think
it's
too
long
for
library.
It
makes
sense
for
node.js,
but
it's
too
long
for.
C
B
B
B
B
So
like,
for
example,
we
will
write
asynchronously
if
we
discuss
it
and
come
up
with
a
proposal
and
tag
people
from
like
typed,
like
all
big
projects
that
use
graphql.js.
B
C
C
Can
you
hear
me
now
yeah
yeah,
yeah,
sorry,
I
wasn't
yeah,
so
I
I
think
I'm
sharing
my.
This
is
like
a
personal
opinion,
but
I
think
we're
kind
of
maybe,
in
my
opinion,
missing
the
point,
because
my
personal
opinion
is
that
graphical
16
is
taking
so
long,
not
and
when
I
say
graphql16,
it's
actually
also.
We
can
count
it
as
graphql15
because
we
can
call
it
the
typescript
migration.
C
It
takes
very
long
and
I
think
we
actually
addressed
the
reasons
why
it
takes
so
long
in
the
first
working
graphql
gs
working
group.
I
think
we
actually
started
the
graphql
gs
working
group
because
of
that
and
what
we
said
because
you
know
the
types
of
migration
had
nothing
to
do
with
the
spec
release,
yeah
and
especially-
and
I
think
you
know
esm-
support-
this-
definitely
has
nothing
to
do
with
spec
release
yeah.
C
So
all
these
things,
the
fact
that
they
took
you
know
since
we
started
like
you
know
discussing
and
talking
about
it
in
2019.
I
think
you
know
it
has
nothing
to
do
with
the
with
with
that
or
with
breaking
changes
or
with
support.
You
know,
and
that
in
you
know,
working
with
other
libraries
like
apollo
server
or
you
know,
I
don't
think
that's
the
issue.
C
I
think
the
issue
is
that
kind
of
like
what
we've
seen
in
the
working
group
today
there's
tests
that
need
to
be
done
and
they
weren't
being
done,
and
this
it
goes
to
the
first
graphical
js
working
group
where
we
we
said
that,
there's
a
bottleneck
and
we
also
then
we
we
suggested
what
were
the
things
to
do
in
order
to
change
that,
and
the
thing
is
that
nothing
happened
when
you
change
it
like
you
and
ivan
those
were
proposals
that
you
put
through.
It
wasn't
like
solutions
that
we
suggested.
C
So
I
think
the
main
reason
that
those
things
are
are
are
not
happening
is
because
we
do
have
a
bottleneck
and
and
what's
happening
right
now,
even
though
now
you're
working
in
apollo,
the
bottleneck
just
increases,
there's
more
things
that
are
coming,
there's
more
changes
and
on
the
meantime
we
don't
see
any
change
and
things
that,
and
I
think
that
you
know
having
more
of
your
time,
is
not
going
to
help.
What
we
said
at
the
first
working
graphical
js
working
group
is
that
we
need
more
maintainers.
C
C
Because
I
think
this
is
the
real
issue
here
and
if
it's
not
sahaj,
it
could
be
anyone
else,
but
I
think
we
can't
wait
anymore
because,
to
be
honest,
you
know
it's
been
three
years
to
migrate
graphql.js
to
typescript
and
I
don't
want
to
wait
for
16
to
get
out
because
16
is
getting
out
for
a
couple
of
months
now.
B
F
B
B
F
E
B
B
B
B
For
some
of
the
decision
you
need
to
know
a
background
of
why
certain
things
in
certain
ways,
so
I
think
we
have
a
good
progression
in
red
direction
and
especially
since
I
don't
know
like
it's
like
it,
I
don't
know
your
work
condition,
but
I
expect,
since
you
journey
guilt,
you
have
more
time
to
to
work
on
this
stuff
and
I
myself
I
cannot
say
I
will
have
much
significantly
more
time
but
because
part
of
of
my
work
is
still
like.
I
work
on
a
poster
and
other
stuff,
but
it's
more,
it
became
more
reliable.
B
So
previously
it
was
like,
depending
on
my
work
or
this
other
stuff,
and
now
it's
more
yeah.
I
will
have
more
dedicated
time,
so
I
totally
agree
that
montana
says
bottleneck.
B
So
if
you
know
how
to
can
suggest
how
to
speed
it
up
without
sacrificing
quality,
I'm
totally
up
for
it
and
as
like
part
of
this
process,
you
probably
not
see
so
I,
for
example,
like
understood
that
it's
not
enough
to
to
just
have
reviews.
So
we
have
a
bunch
of
video
calls
with
a
hit
and
a
spend,
like,
I
don't
know,
a
lot
of
hours,
getting
him
up
to
speed
with
like
code
bases
and
some
stuff,
some
like
why
certain
thing
is
done
certain
way
or
like
explaining
stuff.
B
C
Effort,
so
what
you're
saying
now
is
that
sahaj
is
a
core
contributor.
B
B
Person
who
merged
like
court
changes,
but
I'm
totally
confident
of
giving
like
him,
commit
rights
having
him
like
review
stuff.
It's
like
even
define
a
roadmap.
I
just
think
some
of
the
for
some
of
the
stuff
we
have
like.
B
So
on
first
period
of
time,
I
still
will
be
a
bottleneck
on
particular
complicated
parts
of
rocket
ljs
and
in
future
amount
of
his
stuff
should
go
down
with
with
the
hit
building
up,
and
I
don't
every
time
he
asks
his
question.
I
spend
like
a
lot
of
time
going
to
into
details
why
it's
done
like
that
or
why
we
so
I'm
actually
working
on
it.
Another
thing
it's
usually
usually
done
in
direct
messages
or
on
video
calls.
C
What
do
you
suggest
for
us
if,
let's
say
because
what
I'm
saying
is
not
that
you're
holding
things
back
purposely,
but
what
what
I?
What
do
you
suggest
for
us
as
a
group
that
you
know
maintain
you
know,
many
libraries
in
the
community
has
a
lot
of
experience.
Maintaining
libraries
in
the
community,
including
creating
multiple,
as
you
said,
prs
for
graphql
gs,
some
of
them
you
murdered
some
of
them.
C
You
took
and
you
merged,
and
you
rebuild
them
yourself
and
if
we
disagree
with
you,
if
we
disagree
and
I'm
not
saying
who
is
right
or
who
is
wrong,
but
I'm
asking
like
what,
if
we
disagree
with
you
about
the
level
of
you
know,
the
person
that
you
know
could
could
maintain
the
library.
If
we
disagree
on
the
on
the
way
to
onboard
new
people
on
the
library
and
if
we
disagree
on
the
way
of
working
and
the
timelines,
what
do
you
suggest
we
should
do.
B
B
B
It's
like
a
lot
of
time
and
effort
on
board
a
new
person,
and
I
learn
it
right
now,
but
I'm
not
controlling,
for
example,
who
who's
ahead,
will
on
board
and
spend
like
time
and
effort
and
onboard
somebody
new.
B
So
it's
a
policy
for
me,
minion
clique,
when
we,
when
we'll
have
two
maintainers,
we
will
have
more
diversity.
In
that
sense,
when
we
all
have
like
three
or
four
five
maintainers
is
basically
questioned.
C
But
yeah,
but
what
I
don't
get
is
like
right
now,
you're
the
only
maintainer
yeah
still
does
still
doesn't
have
can't
just
like,
let's
say,
merger
pr
and
cut
a
release,
and
we
are
let's
say
you
know,
hypothetically,
we
and
again
I'm
saying
we
have
a
disagreement
right
like
you
think
something
specifically
and
you
and
again
I'm
not
saying
that
you,
it's
not
something
personal
at
all.
I
think
that
you
know
you're
the
only
person
that
does
you
know
outside
of
us
that
does
meaningful
open
source
work.
C
You
know
so,
theoretically
we,
you
know,
we
appreciate
you,
you
more
than
you
could
even
think
of.
But
what
I'm
saying
is,
I
think
you
know
everyone
can
learn
from
everyone
and
I
think
the
and
everyone
can
also
improve
themselves
and
I
think
currently,
if
you
look
at
the
results
and
the
discussions
we
are
having-
and
you
know
now-
it's
it's
well
over
a
year
around
and
even
more
around
adding
another
core
contributor
and
and
cutting
out,
you
know
typescript
release
and
the
whole
process.
C
Something
in
my
opinion
is
not
working
well
and
if
we
disagree
with
you,
there's
nothing,
we
could
do
right
right
now,
there's
no
other
maintainer,
and
until
that
point
comes
and-
and
we
disagree
with
you
about
the
the
process
of
onboarding
another
commentator,
so
it's
like
we
are
stuck
and
there's
nothing
we
could
do
yeah.
I
hope
you
understand
our
position.
C
Of
okay
and
I'll
add
another
another
I'll
add
another
point:
you
know
we
are
currently
you
know
you
are
aware
of
all
the
projects
we
are
doing
and
building.
Currently
you
are
kind
of
forcing
us
with
the
only
you
know.
Only
solution
possible
is
to
photograph
qlgs,
and
you
know
other
people
in
the
community
started
doing
that
and
we
always
were
against
that.
But
you
know
you
you
are
currently
forcing
that
into
that,
and
I
think
it
will
be
the
worst
outcome.
If
that
would
happen,.
B
Yeah,
I
agree
it's
it's
especially
like
I'm,
okay,
if
people
fork
it
for
experimental
reason
like,
for
example,
there
is
lightweight
version
of
graphql
js.
Obviously
it's
not
the
goal
of
this
library
to
to
be
like
front-end
only
why,
but
so
what
what
reason
for
working,
but
if
somebody
fork
it
for
organizational
reasons,
I
think
it's.
B
B
B
C
But
you
understand
they
understand
the
paradox
of
what
you're
saying
right
like
we
are
now
in
this
working
with
you
and
in
front
of
you
for
two
years.
We
know
these
arguments,
you
know
we.
The
thing
is:
what
usually
you
do
is
that
in
regular
open
source
projects,
someone
submitted
pr,
you
review
it.
You.
E
C
Or
you
can
even
read
it
in
a
very
short
sentence
and
just
say
overall,
this
is
not
good.
Please
split
it
then
the
you,
the!
If
the
person
actually
splits
it
because
smaller
commits,
then
you
again
you
review
it
and
you
review
the
smaller
commits,
and
then
you
know
at
least
get
someone
that
gets
their
pr's
merge,
but
what's
happening
today
in
graphql
gs
is
that
people
are
submitting
pr's,
many
of
them
by
the
way
are
submitting
them.
According
to
your
guidelines
like
yakov,
for
example,
yeah
yeah,
yeah
and
then
wait.
C
Let
me
finish
and
then
what
you
are
doing
many
times
is
even
if
there
are
small
you
are
like,
because
you
don't
have
a
lot
of
time,
then
it
takes
a
long
time
until
you
come
to
review
the
pr
and
then,
when
you
come
to
review
the
pr
instead
of
like
asking
the
person
to
fix
it
and
then
to
wait
to
give
them
time.
C
Actually,
you
took
many
times
a
lot
of
time
to
review,
to
review
it,
but
then,
instead
of
that,
you
copied
the
code
and
you
and
you
are
merging
it
yourself,
and
then
it
means.
If
you
look
at
the
commit
history
that
you're
the
only
committer,
but
that's
actually
not
true,
but-
and
this
is
actually
one
of
the
things
that
we
disagree
with
the
most-
and
we
have
a
lot
of
examples
of
that.
C
Because
what's
happening
is
that
you
stay
the
only
committee,
and
that
means
that
you
co,
you
keep
yourself
as
the
only
maintainer
and
then
that
keeps
the
bottleneck.
B
B
C
It's
actually
he's
working
nights
and
he's
actually
a
doctor
he's
spending
a
lot
of
time
on
this
he's
very
passionate
on
it
and
if
he's
the
one
there's
a
lot
of
people,
you,
I
think
it's
hard.
It's
it's
hard
for
you
to
say
that
camille
yakov
people
that
maintain
the
most
active
graphql
libraries
in
open
source
and
spend
most
of
their
time
in
open
source,
saying
that
they
don't
have
the
time
to
spend
on
it
or
I
think
it's
like
we
could.
Let's
say
we
disagree
on
that
point.
C
B
So
but
I
don't,
I
don't
want
to
yeah,
because
I
understand
your
basic
question
of
what
you
do.
If
you
disagree
before
what
I
want,
it's
I'm
totally,
I'm
totally
like
I'm
not
happy
about
some
minor
detail,
but,
like
general
contribution
from
echo,
I'm
totally
happy
with
he
is
like
spend
effort
and
trying
to
to
to
make
it
like
small
pairs
and
good
quality
code.
So
on
that
side
it
said
to
it's
said
to
hear
that
he
is
frustrated.
B
I
understand
why,
so
I
think
it's
two
separately
two
separate
reasons
so
yeah,
but
I
understand
your
general
idea
of
why
we
what
to
do
if
we
disagree
so
two
separate
thing
is
not
much
in
code
quality
and
me
basically
writing
prs
and
another
thing
is
review
review
response.
C
C
C
All
we
care
is
the
progress
of
graphical
gs
and
not
creating
other
forks
of
it
and
having
the
community
having
a
stable
and
modern
and
performing
base,
and
currently,
if
the
the
library
was
in
a
good
release,
cadence
if
the
the
prs
and
the
issues
were
answered
in
a
good
way
in
in
a
timely
manner,
and
we
would
feel
there's
enough
progress
on
graphql
js
itself,
putting
aside
the
spec
and
the
new
and
the
new
features,
okay,
that
are
not
related
to
new
graphql
features.
B
Before
so
I
I
wasn't
like
for
years.
Nobody,
I
volunteer
my
own
time
until
in
2000
and
from
19
graphql
foundation
start
paying
me
like
for
one
working
week
per
month,
and
this
amount
of
work
is
big,
including
summer
of
course
summer.
Of
course,
it's
like
you
dedicated
half
of
that
time,
like
for
entire
summer
or
even
more
so,
and
season
of
dogs
is
the
same
and,
like
other
responsibility
for
craft
kill
foundation.
C
I
guess
I
guess
I
think
we
disagree
about
the
process
of
onboarding
a
maintainer
because
we
are
or
or
the
results
of
it.
I
guess
because
we,
you
know,
we
started
graphql.js
working
group,
the
first
subjects
that
were,
if
you
remember
the
first
graphql
js
working
yeah
started
because
of
it
and
all
the
tests
were
around
it
and
and
the
garfield
just
working
group
came
after
we
were
in
the
working
group
itself.
The
regular
working
group
saying
there's
a
problem:
yeah.
E
C
Then
we
started
the
graphical
js
working
group,
so
I
think
in
my
op.
So
in
my
opinion
since
then,
I
haven't
seen
a
change,
a
meaningful
change
in
the
in
the
things
that
actually
matter.
In
my
opinion,
I
mean
if
in
my
if
sahaj
would
now
sahaja
or
any
other
person
that
you
can
think
of
or
want
or
choose.
C
Way
you
want,
but
what
what
I
think
I
think
and
again
let
me
just
very
be
clear.
I
don't
think
okay,
I
think
it's
it's
it's
it's
a
difference
in
of
opinion,
I
think
you
are
really
taking
like
you're
doing
it
from
good
heart,
because
and
also
from
professionalism,
because
you
have
a
very
high
bar
of
code,
quality
of
understanding
and
all
these
things,
and
I
think,
though,
there's
and
you
have
and
there's
a
let's
say,
there's
a
somewhere.
C
There's
needs
to
be
a
choice
right
because
whoever
would
be
on
board,
it
will
be
less
qualified
new
yeah
yeah.
C
So
the
question
is
all
is
just
where
the
threshold
is
right
and
I
think
that
the
threshold
should
be
dictated
not
only
by
the
quality
but
also
by
the
state
of
the
project,
because
because
if
the
state
of
the
project
becomes
like
that
that
you
know
it
types
if
migration
takes
that
long,
esm
support
takes
that
long.
That
there's
hundreds.
E
C
Issues
almost
100
prs.
C
And
people
are,
and
people
that
are
very
active
and
very
passionate
and
very
smart
and
very
experienced
are
getting
discouraged.
I
think
that
this
also
needs
to
be
taken
into
account.
So
that
means
that
maybe
it
means
that
we
will
need
to.
You
know
set
maybe
for
a
period
of
time,
a
certain
different
standard.
C
But
the
thing
is,
I
think
that
maybe
you
don't
see
the
urgency
as
the
way
that
we
see
it,
and
I
think
part
of
it
is
maybe
because
we
are
working
with
the
community
in
production
every
day
and
and
we
maintain
those
libraries
you
know
and
we
need
to
you
know
again:
we
maintain
some
of
the
most
popular
libraries
that
use
graphql
gs
and
we
see
that
urgency.
B
B
What
what
this
mean?
It's
people
duplicating
the
code.
So
if,
if
we
merge
something
into
graphql,
js
people
in
other
implementation
will
follow.
There
is
like
python.
Fermentation
entire
python
community
basically
use
one
by
one
copy
of
graphql
json
to
python,
so
we're
making
decision
not
only
for
javascript
community.
We
decided
for
python
community
also
and
for
other
projects.
C
C
Is
another
point
that
I
agree
with
you,
but
I
also
think
the
solution
is
different.
I
think
what's
happening
right
now.
The
fact
that
this
is
a
reference
implementation
means
that
you
know,
I
don't
think
it
has
to
do
anything
with
the
fact
that
it's
very
slow.
C
I
think
again,
I
don't
think
that's
the
issue,
because
I
think,
if
we
will,
for
example,
have
prs
and
have
them
you
know,
have
a
list
of
people
that
are,
let's
say
you
know,
from
graphql
java
from
python
from
other
languages,
review
certain
pr's
themselves
and
have
a
debate
about
them.
That's
a
way
to
do
it,
but
currently
that's
not
the
reason
the
things
are
slow.
C
B
Yeah
so
two
points,
my
personal
opinion
is
we.
We
should
try
too
much
reasonably
much
quality
or
graphical
specification.
What
mean
like
my
point,
my
personal
opinion
is
that.
B
B
B
B
Let's,
let's
decide
on
two
things
distinguish
two
things
like
bootstrapping
process,
new
contributors
and
like
a
policy
afterwards.
So,
as
probably,
you
don't
think
it's
a
problem
if,
if
we
have
like
five
five
five
core
contributors
and
they
decide
who's
on
board,
if
it's
like
five
divorce,
core
contributors,
it's
like
more
as
normal
situation
right.
It's
not
in
case
that
we
won't
yeah
yeah.
B
So
that's
why
I
don't
want
to
like
initially
idea
was
to
to
form
hours
and
it's
too
much-
and
I
thought
about
that-
and
I
didn't
want
to
do
like
public
disagreement
on
that.
But
basically
I
I
think
every
contributor
should
decide.
That's
why
I
don't
want
to
formalize
it,
especially
since
we
try
to
solve
bootstrapping
process
with
enforcing
policy
that
will
affect
like
projected
no
longer
so
okay.
B
So
how
so
question
how
we
get
to
this
point
of
like
five
contributors
and
another
thing,
some
of
the
issues
should
be
some
of
the
stuff
should
be
collective
correctly.
We're
made
with
time
out.
So,
even
if
we
have
like
five,
let's,
let's
fix
like
five
as
let's
like
go
at
the
moment.
If
it's
five
people,
five
core
contributors,
it
doesn't
mean
like
any
of
them,
decide
to
do
release
on
sunday
without
saying
to
anyone
else.
B
It's
like
this
person
say
like
we
should
do
release
he
waits
for
feedback
from
everybody
else.
For
example,
one
amount
of
time
like
a
couple
of
days
or
one
week,
and
if
nobody
oppose
you
basically
do
release
himself
right.
It's
not
a
question.
It's
the
idea
that
we
try
to
achieve
consensus,
but
if,
but
nobody
broke
this
process.
C
C
Of
everything
the
the
the
times
you
migration,
the
the
releases,
the
release,
cadence
the
issues
all
these
things.
I
think
it
has
to
do
with
that.
So
I
think
in
my
opinion,
a
possible
solution
could
be
currently,
you
know,
there's
just
you
and
one
in
the
the
process
of
nintendo
was
like.
Okay,
let's
sit
with,
you
know,
sahaja
and
maybe
others
and
boredom
and
everything,
but
maybe
a
solution
could
be.
C
Let's
say
you
decide
on
a
group
of
five
people
today
that
you
think
that
are
that
will
be
diverse
right,
so
you
know
some
could
be
from
the
guild.
Some
could
be
from
apollo.
Some
could
be
maybe
lee,
maybe
from
some
people
from
the
technical
steering
committee.
I
think
I
don't
want
to
say
this
group
is
the
technical
steering
committee,
because
most
of
them,
I
think,
are
not
actually
working
with
rough
dlgs
at
all
yeah.
So
this
is
a
problem
exactly
so.
C
So
I
think
what
we
could
do
is
like
you
will
decide
on.
Let's
say
a
couple
of
these
and
then
until
we
get
to
the
point
where
we
have
you
know
more
commuters
or
maintainers
and
everything
those
this
group
that
you
you
decided
and
agreed
on
and
will
you
know
we
can
help?
But
again,
this
is
not
something
that
we
will
push
we'll
we'll
get
in
the
sa.
We'll
do
the
process,
as
you
described
later,
which
is
let's
get
the
consensus
between
the
five.
C
If
someone
is
like
taking
too
long,
they
continue,
and
then
let's
say
I
know,
let's
say
for
you:
it
takes
longer
at
least
there's
four
people
that
are
not
having
you
know:
they're,
not
working
in
the
same
company
they're,
not
you
know,
they're,
not
having
okay.
I
can
think
about
a
couple
like
one
person
that
I
will
for
sure
mention
is
benji,
but
but
I
mean
you
know
but
but
I
think
like
we
can
think
about
a
couple
of
them
and
then
maybe
we
could.
C
This
could
be
a
good
solution
for
everyone
before
it
escalates
even
further.
You
know,
and
that
could
give
us
the
time
to
actually
start
advancing,
and
I
think
it
might,
in
my
opinion,
something
like
that,
would
actually
bring
new
energy
for
contributors,
and
that
would
actually
be
the
engine
that
brings
more
people
more
quality
and
more
contributors
and
to
the
until
a
certain
point
where
we
get
more
core
contributors.
C
Like
we
could
decide
on
the
specifics,
but
yeah
something
like
that
like
if
one
objects
it's
not
going
in,
but
if
someone
gives
feedback
here,
no
like
any
one
of
them,
especially
you
if
you're
saying
no,
this
code
is
not
good.
It's
not
going
to
get
married,
no
matter
what,
but
if
you
know
you
aren't
there,
for
you
know
for
very
good
reasons.
You
can't
do
that
and
then
there's
four
or
three
people
that
reviewed
it.
E
B
B
So
basically
idea
I
if
it's
like
volunteering
with
unfixed
result
so
basically
like
it's
nobody's
responsibility,
and
there
is
no
way
it's
not
affecting
a
process
by
people
less
motivated
to
give
a
feedback
because
they
feel
it's
like
in
the
end.
It's
basically
me
to
decide
what's
much,
you
know
on
what's
not,
but
if
we
give
them
like
this,
basically
with
power
of
okay,
I'm.
B
B
B
Processes
outside
its
own
help
to
have
stuff
yeah.
I
started
by
the
way,
like
I'm
totally
happy.
If
one
of
these
people
will
be
echo,
I'm
like
he's,
you
he's
usually
provide
good
feedback
and
he
he
is
not
from
pragmatical
side,
and
the
fact
is
some.
We
disagree
on
a
lot
of
points
that
provide
alternative
you
with
the
fact.
Most
importantly,
it's
always
argumented,
so
it's
the
same
with
benji.
If
badger
agrees
to,
because
it's
also
commitment
from
a
banjo.
C
C
Yeah,
I
think
I
think,
like
I
mean
this,
has
to
be
a
solution
that
you
feel
comfortable
with
ivan,
so
I
think
it
has
to
be
people
that
you
decide
on
and
you
feel
as
much
as
com.
I
understand
that
this
solution
is
not
comfortable,
as
you
know,
as
it
is
right
now,
but
I
think
you
know
you
choosing.
The
people
would
be
as
much
comfortable
for
you
as
possible,
so
yeah.
E
B
C
B
C
Be
you
know
and
again
I'll
repeat
what
I
said
a
couple
of
times,
but
I
I'll
even
say
it
in
a
different
way.
I
think
you
are
doing
an
impression,
an
impossible
job
and
you
know
you've
been
put
in
this
place
and
I'm
not
saying
you
were
forced
to
this,
but
I
think
the
mechanism
made
it
like
that
and
you
have,
in
my
opinion,
in
the
whole
graphql
community.
C
You
have
the
biggest
weight
of
weight
on
your
shoulders
and
I
think
people
don't
understand
that
and
my
my
goal
here
is
to-
and
I
completely
understand
it
I
mean-
we've
been
talking
and
working
to
together
in
this
way
or
another
for
like
four
years.
You
know,
I
even
remember
talking
to
you
in
graphql
berlin
in
like
2017
or
something
you
know
16.
I
don't
remember,
but
I
mean
I'm
completely
aware
of
everything,
so
I
think
my
goal
here
is
just
to
I
you
know
first
to
I
agree
with
you.
B
B
B
So
and
another
thing
I
I
think
like
it-
will
always
be
stuff
that
we
disagree
on
even
on
like
managing
project
and
stuff.
B
But
I
agree
that
right
now,
it's
not
the
best
situation
and
instead
of
figuring
out
yeah,
I'm
like,
but
I
think
it's
good
compromise
on
every
front
I
mean-
and
my
main
concern
is
that
we
people
should
these
people
should
be.
It
should
be
commitment
from
these
people.
What
the
worst
thing
you
want
is,
if
we
try
this
approach
and
with
five
people.
C
I
I
think
I
understand
the
reasoning
why,
but
I
think
in
that
case
again
there's
one
person.
I
think
that
at
this
stage
sees
the
whole
and
we're
talking
specifically
about
javascript
right
now,
since
the
whole
javascript
ecosystem
has
practical
knowledge
and
sees
the
different
projects
and
is
aware
of
them,
and
that's
you
even
so,
I
think
for
you
to
set
up
this
whatever
we
can
call
it
committee.
We
can
just
say
those
are
just
graphql,
js
reviewers,
you
know
whatever:
okay,
okay,.
B
C
B
Yeah,
I
think
I
think
reviewers
is
better
and
clearly
outlined.
Another
thing
I
don't
want
it
to
be
permanent.
I
wanted
to
to
be
like
bootstrap
approaches,
especially
this
election
and
always
like
think
is.
B
C
B
E
B
B
B
So
I
will
ask,
for
example,
a
sito
from
christopher
from
graphql
python,
no
krakel,
yeah,
graphical
python,
of
course.
Here
like
previously,
I
actually
wanted
to
give
him
a
right
to
match
stuff
because
he's
really
familiar
with
codebase
problem.
That
he's
not
didn't
want
to
do
that,
but
I
will
approach
him
with
face
simpler
task
of
reviewing
pairs.
B
B
What
would
get
some
start
with
timely
but
limit
on
what
thing
one
week
for
me
to
finish
like
what
I'm
doing
right
now
and
think
about
the
entire
idea
and
another
week
to
contact
like
people
and
if,
in
two
weeks
we
have
like.
B
B
Yeah,
so
having
key
people
who
understand
context
is
like
critical,
and
I
don't
want
to
just
like,
like
even
if
lee
agreed
agrees.
Nearly
early
schedules
is
not
working
for
for
such
role.
C
Yeah
I
mean
it's,
it's
a
it's
a
try
and
thanks
for
being
open
for
it,
you
know
thanks
for
being
open.
B
I
also
agree:
it's
not
situation.
I
yeah.
I
want
to
give
this
project
in
good
hands
the
same
with
like
a
lot
of
rust,
is
moving
direction.
I
want
to
try
a
rust,
but,
as
we
discuss
with
support,
I
just
cannot
abandon
this
project
right
now.
I
wanted
to
be
in
better
shape
so
in
good
hands,
yeah
yeah,
and
for
that
yeah.
C
Thank
you
thanks
for
being
open
for
it
and
yeah,
and
you
know
we
want
to
help
as
much
as
we
can
here.
So
you
know,
if
you
think,
there's
more,
we
could
do
and
things
we
could.
C
B
B
B
B
C
Okay,
thank
you
very
much
yeah
and
let's
I
created
a
channel
on
discord
and
there's
an
issue
there
and
yeah
thanks
for
being
open
for
it
really.
I
hope
it
will
be
good
for
everyone.
B
A
A
B
Since
wait,
I
don't
see
any
cons.
The
only
cons
I
see
if
it's
like,
if
it's
it
will
sacrifice
some
like
review
from
my,
for
example.
I
know
something,
but
I
don't
have
a
time
to
review
it,
but
in
that
case
here
I
agree
with
zuri.
So
worry
like.
Maybe
we
disagree
on
the
scale,
but
I
totally
agree
that
it's
okay
to
sacrifice
some
code
quality
for
onboarding,
your
contributors.
B
B
It's
like
yeah,
I
feel
more
confident
doing
a
better
way.
So
it's.
B
C
Yeah,
thank
you
for
yeah
for
for
being
open
for
this,
and
I
agree,
I
think
you
know
I
think,
at
any
long
term,
open
source
project
there's
come
a
point
where
you
have
to
have
more
maintainers,
which
means
there's
gonna,
be
some
effect
on
the
short
term.
But
then,
on
the
long
term,
it's
going
to
be
better
and
I
think
you
know
we
all
see
graphical
yes
continuing
for
years.
C
E
B
C
Okay,
thank
you
thanks
for
the
time
and
thanks
for
listening
and
thanks
for
being
open
for
me
and
thanks
for
all.
C
Okay,
bye,
bye,
everyone.