►
From YouTube: GraphQL.js Working Group - 2021-10-27
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Excellent,
how
was
your
day
it's
been
a
whole
day
of
meetings,
it's
just
jumping
from
meeting
to
meeting
today,
but-
and
actually
I
was
just
on
the
same
meeting
with
ivan,
so
he
might
be
a
couple
minutes
late,
so
we'll
see
but
yeah.
The
meeting
just
ended.
I
I
thought
it
was
gonna
run
a
little
late,
but
it
actually
ended
on
time.
So
that's
great!
That's
good!
Yeah
yeah!
So
it's
been
a
good
week
for
you,
though,.
B
Awesome
to
hear
this
is
my
first
time
joining
the
the
the
graphql
yes
working
group
call
yeah
I'm
joined,
I
go
to
the
other
working.
B
Yeah
every
once
in
a
while
for
sure,
but
I'm
definitely
interested
in
yeah
in
the
future
of
graphql
js
for
sure
yeah
and
I
know
I
I've
talked
to
ivan
a
fair
bit
about
the
the
kind
of
review
team
plan
and
stuff.
So.
A
B
Definitely
want
to
want
to
hear
more
about
that,
but
you've
been
helping
out
a
lot.
Haven't
you
with
graphql
js.
B
Awesome
yeah,
that's
awesome,
yeah,
it's
it's
an
important
project
for
sure,
and
it's
super
important
for
apollo,
like
we
use
it
quite
heavily,
and
I
think
that
it's
interesting
to
think
about,
like
we
have
a
bunch
of
like
utilities
and
helpers
and
all
sorts
of
stuff
that
we
have
in
other
projects
that
we're
using.
D
B
And
like
since
I've
enjoined
us,
he
he's
noticed
like
hey
like.
Why
aren't
these
part
of
graphqljs
and
the
answer
is
they
should
be
totally
so
it'd,
be
really
neat
if
we
can
find
ways
to
get
a
lot
of
that
stuff
kind
of
moved
into
graphql
js
at
some
point
to
make
it
more
open
to
everybody
in
the
community
but
yeah.
I
know
he's
thinking
a
lot
about
that
anyways,
but.
A
B
B
C
Good
I'm
walking
outside,
so
I'm
trying
to
commute
myself
as
much
as
possible.
D
D
E
So
since
we
recorded
and
anyone
who
want
to
join
this
call
in
the
future
and
on
this
call
we
need
to
sign
membership
agreement,
participation,
guide
and
code
of
conduct.
E
It
can
be
done
as
individual
or
you
don't
need
to
involve
a
course
in
your
company
if
you
don't
want
to
so,
if
you
want
to
join
just
sign
them
and
next
thing
we
should
introduce
ourselves
and
I
will
start
from
myself
and
we
will
go
into
order
in
the
agenda
so
hi.
My
name
is
one
and
I'm
one
of
the
maintainers
of
graffiti
jazz.
B
Great
hi,
I'm
hugh
I
work
at
at
apollo
on
various
open
source
projects
currently.
E
Yes,
so
let's
go
through,
I
don't
think
like
we
actually.
Yes,
such
added
about
action
item
also
like
next
next
point
in
agenda
is
action
items
and
from
the
last
meeting
we
have
like
a
new
one
about
otc.
E
I
think
we
need
to
to
do
is
in
future.
One
thing
I
want
to
know
it's
like
it
should
be
based
on
volunteers,
so.
E
Like
I
suggest
to
make
it
based
on
volunteers,
if,
by
the
way
like
I
forget,
to
send
the
link
two
issues
so
we're
on
the
same
same
page,
we
don't
have
a
lot
of
agenda
items
so
yeah.
E
I
think
like
to
increase
responsibility.
We
also
need
to
increase
volunteering,
so
if
people
want
to
support
something
for
one
time,
somebody
needs
to
want
you
to
do
like
backwards
and
be
maintainer
of
certain
release.
Wine
yeah,
but
I
think
if
we
will
still
have
a
time
we
can
include
it
in
agenda
and
also
discuss
it.
Other
agenda
items
like
we
have
a
back,
walk
and
sometimes
some
point.
We
need
to
to
go
for
them,
but
I
think
like
right
now
we
have
with
two
main
topics.
I
said
6.0
and
reviewers.
E
And
by
the
way,
friends,
I
had
wasatch
actually
opening
issue
about
otc
because
it's
easy
to
forget,
especially
since
we
don't
do
notes,
yeah
yeah
and
with
like
the
several
volunteers
for
not
taking.
Since
everything
is
recorded,
and
usually
it's
one
like
three
or
four
five
people
tops.
E
E
I
think,
like
a
couple
at
least
a
couple
of
weeks,
youtube
error.
Like
basically,
I
tried
to
find
nutrition
fast
from
for
poster
from
version
15
to
version
16,
and
it's
not
like
a
poster
specific
issue.
It
just
discovered
it
on
a
power
server.
We
basically
converted
a
graphical
error
from
being.
E
Basically
make
made
it
a
class
and
start
adding
properties
on
into
it,
and
it's
like
part
of
typescript
migration
idea
was
not
too
bad
backboard
not
to
like
convert
workarounds
from
four
times,
so
we
switched
everything
from
es5
to
the
a6
classes
and,
let's
cause
the
issue
on
the
server.
I
finally
figure
out
how
to
do
it,
how
to
support
both
questions
and
have
like
extension
on
the
class.
So
it's
unboxed-
and
I
think
like
since,
since
last
week,
I'm
like
okay,
cut
and
release
we're
just
figuring
like
final
stuff.
E
Since,
even
though
I
win
the
release
phase
for
one
time,
some
of
the
projects
didn't
try
a
try
release
candidate.
E
It
was
a
couple
of
wishes.
I
don't
want
to
go
to
technical
details,
but
it
was
couple
issues,
some
of
them
like
before
c
phase
and
at
least
one
major
one,
either
intuitive
phrase
with
typescript
and
another
thing:
we're
restricting
typescript
to
the
minimum
version
4.1,
so
yeah
yeah,
but
basically
like
one
very
short
right
now,
everything
ready
to
cut
there
is
no
like
brokers.
E
We
still
have,
I
think,
like
today,
envelope
graphql
envelope,
converted
to
16
added
support
for
16
coding
added
support
for
16..
I
figured
out
the
path
for
power
server
to
convert.
I
didn't
try
it
on
federation
and
other
things
yet,
but
I
think
I
think,
like.
E
Yeah,
because
I
cannot
like
wait
for
every
single
project,
one
thing
we
have
an
issue
for
yeah,
it's
a
cage,
actually
link
it
into
yeah
into
agenda,
and
but
I
still
posted
here,
it's
feedback
on
rc1,
but
basically
turn
out
to
be
feedback
on
the
whole
red
line.
E
So
because
of
that
today,
katrin
rob
did
a
great
job
of
replacing
his
branch
on
top
of
west
rc
into
their
cut
release,
and
it's
enabled
us
to
test
on
graphical
from
what
I
saw
looking
at
the
work.
Everything
is
safe.
There
is
like
errors
due
to
missing
stream
and
d4,
but
everything
else
is
passing
if
we
want
to
be
like
super
sure
we
can
wait
for
for
like
because
there
is
a
prto
graphical
to
enable
version
16
support.
E
A
E
A
E
Okay,
especially
since
we
don't
know
like
of
any
any
problems
with
graphical,
and
I
think
ricky
summarized
opened
like
on
top
of
his
issue,
he
had
like
check
boxes.
E
I
can
send
like
sorry
in
the
same
page,
I
can
send
he
market
the
creature.
A
E
It's
involved
like
some
some
changes,
so
I
think
he
summarized
like
problems
in
first
command
with
tick
boxes
and
first
one
is
underweighted.
I
think
it's
related
to
some
called
mirror
config.
He
included
in
the
same
pr
so
yeah.
If
everybody,
okay,
I
will
just
cut
release
after
this
call.
E
It
requires
some
preparation
work.
I
think
what
I
saw
is
usually
take
a
couple
hundred
times
to
to
migrate
big
libraries
and
most
of
the
changes
due
to
we
switching
from
new
any
to
unknown
on
many
types.
So
I
think
it's
good
achievement
for
like
migrating
the
entire
code
base,
plus
we
clean
up
a
bunch
of
like
stuff
like
this
stuff.
E
Stuff
is
kind
of
not
working
seems
like
what
we
learn
is
one
couple
of
months
is
not
enough
as
rc
process
ways
I
need
to
like
coordinate
better
or
we
need
to.
A
E
E
E
E
But
still,
I
think
we
can
think
about.
Another
project
is
having
like
a
repository
to
run
integration
tests
on
proper
projects.
A
So
on
envelope
we
run
ci
on
the
latest
release
of
graphql
js.
We
can
have
it
so
we
can
run
rcs
on
envelope
in
our
ci,
because
we,
because
yesterday
I
was
working
on
a
pull
request
and
it
started
to
fail.
Then
I
found
the
apollo
server
error
that
you
fixed
this
morning,
so
you
can
have
it
so
we
can
also
run
rc
branches
on
that.
If
that's
something,
if
that
would
help.
E
Yeah,
I
think
yes,
ideally,
ideally
like
all
the
popular
libraries
not
only
envelope.
A
A
E
Okay,
cool,
it's
definitely
especially
like
one
one
thing:
it's
kind
of
problematic:
yesterday
I
broke
a
power
server
with
15
release
and,
like
you
cannot
you
cannot
do
you
can
do,
but
it's
strange
to
do
see
really
some
stable
ones.
E
So
I
still
think
it
makes
sense
to
have
like
some
weight
to
test
it
from
from
from
is
a
graphql
jspr
or
run
it
manually.
So.
A
E
E
E
Key
problem
we
have
is
like
we
don't
have
active
active,
not
not
a
lot
of
active
contributors.
E
There
is
like
people
who
do
like
periodical
pairs,
but
not
many
of
them
and
a
reason
is
like
some
person
is
not
getting
response
or
like
review
in
a
timely
manner
and
so
like
for
some
of
them.
It's
like
explainable
way,
spec
process
review
process,
since
it
doesn't
make
sense
to
review
pr
deeply
and
keywords
like
stage
two
but
for
non-spec
release,
and
we
have
like,
I
think,
like
majority
of
them
right
now,
there
is
like
50
years.
E
B
E
So
as
part
of
this
process,
I'm
not
sure
if,
if
everyone
can
see,
if
not,
I
will
like
make
screenshots,
we
basically
created
the
team
just
has
like
creating
gym
and
through
from
the
last
month
I
actually
created
this
team
on
github
graphic.js
reviewers
so,
and
I
think
it's.
E
I
need
to
check
if
it's
public
or
not,
because
it
should
be
public
and
basically
and
idea,
was
as
we
discussed
by
the
people,
that
I
trust
with
ideas
that
if
we
are
stuck
a
person
can
like
ping
with
steam
or
in
future,
we
can
have
like
some
of
them
automation,
but
it's
it
should
be
like
triggered
not
for
not
for
like
normal.
E
They
are
false
not
to
not
over
overburden
the
reviewers,
but
only
if,
like
we
are
stuck
so,
I
think
like
giving
it
like
a
day
or
two
to
to
have
a
normal
fall
and
if
it's
stuck
yeah
and
like
anyone
from
this
team
can
do
review
at
any
point.
They
want
sakhaj
and
jakob
will
both
of
this
team,
and
we
discuss
like.
E
Right
right
and
since
since
not
everyone
actually
wants
to
have
right
permission
on
the
repo
to
I
put
it
as
triage
and
right
now
it's
how
like
five
people,
including
me,
I
think
we
can
scale
it
up
if
right
now,
I
think
five
is
a
good
number.
If
it
not
works,
we
can
scale
it
up
and
another
point
we
discuss
is
to
have
a
time
limit
because.
E
So
basically,
I
give
two
people
reviews
and
approve,
and
sometimes
paths
and
nobody
objects.
It's
get
automatically
matched
so
yeah
one
one
thing
as
we
agreed
it's
experiment
and
it's
main
purpose
to
to
facilitate
new
new
contributors,
not
to
demotivate
new
contributors
with
one
response
time
so
yeah.
E
It's
it's
basically
overview
on
what
is
done
and
yeah.
By
the
way
like
I
can
name
people
it's
like
martin
from
from
a
po.
He
used
graphql,
js
and
extensively
like
for
power,
federation
and
other
projects,
and
he
also
have
a
pretty
interesting
background.
He
like
used
it
in
apollo
ios
to
to
execute
inside
like
apple
platform,
so
yeah
upgrade
totally
trust
him
with
good
quality
he's
familiar
with
that
guy,
and
he
like
have
usage
scenarios
in
mind
plus.
E
I'm
cannot
speak
from
a
polar
side
myself
on
what
was
breaking.
What's
not
breaking
and
what's
because
I
just
joined-
and
I
have
like
limited,
limiting
limited
idea
of
most
of
the
projects
christopher.
He
is
montana
kravkiel.
Python
is
direct
part
of
of
python
library
of
graphql
js2
python,
and
he
I
think
he
is
the
third
most
attractive
contributor
at
the
moment.
He
contributes
a
bunch
of
fixes
and
he
likes
no
entire
code,
basically
because
he
rewrote
python.
E
Jacob
also
contributed
a
lot
and
like
he
had
like
pretty
pretty
interesting
scenario,
with
schema's
teaching
and
deep
knowledge
of
how
the
computer
works
and
the
hedge
like,
who
is
converted
gentile
project
to
typescript.
So
you
also
know
like
like
a
structure
and
ipa,
so
I
think,
is
a
good
starting
set
and
that's
basically
it
any
questions.
B
Just
so
you
know
ivan
it
is
not
public.
The
team.
E
E
Yeah
idea
was
so
in
a
additional
discussion,
the
hardware
I
don't.
I
think
it
was
easy
to
discuss
on
the
call
note
or
just
we
discussed
it
afterwards.
I
think
it
should
be
automatic
release.
E
Let's
set
timeout:
if
it's
not
done,
it's
mean
like
we,
we
should
have
at
least
two
people,
so
I
can
add
you
on
9
pm
a
package
and
it
can
be
done
manually
if
we
can
figure
out
in
reasonable
time
if
we
can
make
it
figure
out
how
to
make
automatic.
Let's
make
it
automatic
because,
like
with
current
issues
of
malware
and
npm,
I
actually
want
to
do
everything
to
go
automatic
as
automatic
as
possible.
E
One
thing
it's
like
stuff
before:
if
we
have
like
some
branches
and
yeah,
but
we
can
try
so
after
my
automate
as
much
as
possible
and
another
thing,
so
we
discussed
how
to
make
how
to
make
it
transparent
as
an
approaches
for
review
teams.
E
I
think,
since
we
agreed
to
make
it
experiment,
I
suggest,
like
razor
start
disc.
I
start
like
issue
discussion.
Whatever
work
best,
I
think
issues
have
better
discoverability
and
we
can
coordinate
there
and
discuss
stuff
there.
So.
E
And
also
it
should
be
a
template,
so
their
template
should
say.
Basically,
if
you,
if
you
feel
like
you,
are
stuck,
please
think,
with
this
group
of
people
an
example
of
a
message
you
can
write
and
to
actually
one
thing
I
spoke
with
with
like
reviewer
team
and
everybody
have
like
a
day
job
and
stuff.
So
we
should
not
ping
them.
E
If,
if
it's,
there
is
a
normal
fall,
so,
for
example,
I
I
open
a
pr-
and
it's
get
much
in
there
like
a
day
like
people
should
not
be
pink
to
it's
better
like
if
they
help
with
reviewing
stuff
from
third
party
from
new
contributors
and
helps
them
to
figure
out
how
to
contribute.
E
So,
what's
my
main,
like
point
of
not
doing
code
on,
why
code
owners
and
other
stuff
is
not
working
because
we
don't
want
every
pr
go
through
this
procedure,.
E
I,
I
will
write
like
short
procedure,
so
people
feel
safe,
even
if,
like
something
happens
with
me
like
because
buffer,
that
is
real
right
now
technically,
like
I
think,
a
bunch
of
people
have
access
to
graphql
js,
like
50
people
have
writes
too
much
stuff
and
like
six
or
seven,
people
have
like
rights
to
release
npm,
but
for
last
couple
of
years
I
was
I
did
like
most
of
the
merchants,
and
I
did
like
almost
all
releases
on
them.
E
So
even
though,
like
people
technically
have
like
rights
to
do
that,
they
need
to
have
like
algorithm
and
all
it's
like
stuff
that
they
can
do
yeah
so
saying
like.
If
nobody
objects
for
two
weeks,
they
can
match
pr
and
there's
a
respect
to
reviews,
since,
as
we
discussed
like
not,
everyone
can
write
access.
I
think
like
such
you
have
alright
access
or
anybody
else
having
the
right
access
can
basically
follow
the
algorithm
and
not
be
like
personally
responsible
for
decision.
E
E
Yeah
yeah,
and
one
thing
I
still
feel
like,
and
we
discuss
it
like
with
you
in
the
chat
and
already
like
issue
right
now,
is.
E
It
will
start
to
wait
for
a
really
long
time,
so
I
think,
let's
move
in
the
steps
so
making
it
like
two
weeks,
because
you
know
like
I'm,
not
sure
how
this
like
system
works
and
what
will
end
up
so
idea
that,
as
as
uri
said
a
bunch
of
times,
basically
like,
I
cannot
like
scale
myself
to
like
review
all
the
stuff.
So
ideally
other
people
like
from
review
teams
and
other
people,
will
comment
on
the
issue
and
suggest
like
how
to
improve
it.
E
A
D
E
Yeah,
so
my
my
objection
with
that
is,
since
we
will
do
automatic
release
one
thing
without
automatic
release,
it's
not
working,
it
will
basically
mean
like
for
some
katy
and
release
need
to
review
like
stuff,
because
he's
responsible
for
release,
I
think,
but
with
automatic
release
we
actually
releasing
stuff.
E
A
A
Like
we
have
to
bring
something
up
or
down
because,
like
not,
everyone
has
the
same
taste
or
like
the
same
quality
bar
as
you,
so
over
time,
people
will
learn
how
to
get
the
same
quality
but
like
because
like,
if
we
think
about
16xxx
like
this,
like
the
type
crypt
migration
started
today
like
a
year
ago
today
so
like.
If
you
think
about
like
one
year,
is
a
long
time
and
the
progress
started
even
before
I
started
working
here
so
like
yeah.
E
A
Yeah,
it
slows
many
things
down
and
like
even
if
we
look
at
our
pull
request.
People
open
pull
requests
for
like
a
very
simple
thing,
like
a
dog
change
and
you're
just
sitting
there
for
months.
D
A
E
A
Took
like
three
months
to
merge
like
yeah
because
like
if
we
take
three
v
even
two
weeks
right,
like
no
one
replies
you
for
two
weeks,
we
are
not
like
a
contributor
won't
like
to
contribute
to
you
anymore,
like
it's
kind
of
like
like
no
one
like
no
one's
replying.
How
do
you
expect
someone
to
just
do
this?
Yeah.
C
B
A
E
This
yeah
so
yeah
we
can
write
it
so
idea
was
to
write
if
it's
like,
if
it's
more
than
48
hours.
So
as
a
member
of
the
review
team,
you
can
review
any
pr
you
want,
but
if
it's
like
more
than
48
hours,
either
like
after
a
pink
like
reviewer
team
or
it
can
be
like
you
me,
any
other
people
or
a
bot.
If
you
write
a
bot
that
pink
reviewer
team
and
say
like
here's,
a
pr
that
is
not
super
fast,
please
review
it.
E
So
I'm
okay
with
any
like
solution
to
it,
so
so
at
what
point
like,
even
before
that
reviewers
can
think
if,
if
they
choose
to
subscribe
to
repo
and
open
every
pr
like
it's
just
additional
message
to
them,
it's
like
your
review
is
encouraged
and
this
pr
is
critical
for
you
to
review.
So
people
start
reviewing
and.
E
E
E
Some
of
like
kind
of
obvious
changes
is
not
obvious,
like
I'm,
I'm
worried
on
opposite
side
of
spectrum,
for
example
like
in
express
graphql,
corson,
open
an
issue
to
support
operation
name.
New
empty
string
is
operation
name
and
it's
against
the
spec
and,
like
people
prove
that,
and
nobody
actually
like
reviewed
the
spec.
E
E
If
we,
if
system
works
in
like
two
weeks
and
if
we
feel
like
everything
going
okay,
we
can
relax
it
further.
So
it's
not
question.
We
should
freeze
it
two
weeks
and
make
a
rules
as
we
said
it's
experiment,
so
we're
not
sure
about.
We
would
solve
our
core
issue
or
not
so
my
suggestion
is
like,
as
we
discussed
like
it's
about
finding
a
compromise,
and
I
think
two
weeks
is
a
compromise.
E
B
A
C
B
E
E
E
B
B
E
I
give
additional,
like
pressure
on
the
on
releaser
to
actually
re-review
the
entire
pr,
because
it's
his
responsibility
to
cut
release
so
yeah.
D
B
E
Any
anything
like
else
we
need
like
yeah.
So
what
what
I
I
wanted
to
summarize
it
before
we
scroll,
but
since
we
have
with
that
release
schedule
I
didn't
end
up.
But
what
I
had
in
mind
is
what
process
of
like
not
over
burning
reviewers
with
with
fast
tracking
pairs,
but
asking
them
to
review
stuff.
That
is
open
for
at
least
a
couple
of
days,
and
when
couple
people
reviewed,
two
people
reviewed
issue
a
time
for
others
to
to.
E
To
provide
feedback,
and
also,
as
a
second
point,
it
gives
opportunity.
It's
remove
a
problem
where
you
have
a
couple,
people
like
very
active
reviewing
because
they
have
like
more
free
time
or
they
have
like
it's
part
of
a
job.
To
do
that,
so
it
makes
like
other
reviewers
was
really
want,
and
the
experience
was
really
one.
I
think
in
a
big
project
like
that
they
actually
need.
E
B
Do
you
is
it
is
the
idea,
is
this
will
be
an
experiment,
so
it
would
be
great
to
have
this
documented.
You
know
maybe
outside
of
an
issue
like,
maybe
even
in
the
readme
or
somewhere
in
the
root
of
the
project.
So
everybody
knows
what
the
review
process
looks
like,
but
I
I
don't
know
if
you
want
to
do
that.
Yet
if
this
is
just
an
experiment,
but
ultimately.
E
E
E
So
it's
like
making
decision
before
we
actually
have
people
who
need
to
follow
it.
So
I
don't
know
like
who
will
be
like
a
future
core
team.
Is
it
like?
People
from
a
company
is
interest
using
graphql,
or
it's
like
individual
contributors
or
mix
of
both.
So
I
think,
like
different
rules,
will
work
for
different
situations,
so
I
don't
want
to
make
it
permanent,
especially
since
we
did.
Ideally
it's
reviewers.
E
We
don't
have
reviewers,
ideally
like
we
have
active
contributors
having
a
back
background
in
graphql
gs
and
onboarding
more
contributors,
maybe
even
it's
like
a
parent
coding
session
or
what
I
learned
with
a
hedge.
It's
like
way
more
efficient,
especially
for
big
features
or
big
refactorings,
is
to
have
parent
sessions.
E
So
ideally
it's
it.
It's
done
like
that.
Ideally,
it's
more
like
done
more
like
by
active
contributors,
not
not
by
like
reviewers
team.
I
think
reverse
him
is
just
a
transitional
idea
how
to
bootstrap
approaches,
because
it's
hard
to
we
don't
have
a
core
team,
so
we
cannot
grow
it
without
having
it
an
idea
that
reviewers
kind
of
substitute
in
in
at
least
like
providing
review
and
feedback
for
four
issues.
B
Yeah,
the
one
thing
I
will
say
is
that
it's
okay,
if
this
is
experimental-
and
you
don't
necessarily
want
to
document
it
as
an
official
part
of
the
repo,
but
getting
this
out
there
could
actually
entice
more
contributors
to
come
and
participate
if
they
know
that
prs
are
going
to
get
merged
in
at
least
more
frequently
than
they
are
now.
That
could
entice
people
to
contribute
more.
So
we'll
just
want
to
make
sure
wherever,
wherever
you
document
this
process
like
make
it
make
it
very
public.
E
B
E
E
D
E
A
person
open
pair
template.
He
actually
see
this
experiment
running
he's
aware.
He
know
why
with
people
providing
feedback-
and
he
know
like
if
he
needs
some
something
additional
feedback,
he
can
tag
them
because
we
cannot
optimize
everything.
If,
if
a
person
makes
substantial
changes
to
pr,
maybe
it
makes
sense
to
ping
everybody
one
more
time
and
ask
them
to
re-review.
E
Yeah,
as
we
discuss
in
the
scope,
like
one
thing,
I
totally
don't
want
to
do,
is
decide
for
other
projects
like
swap
like
data
order.
It's
it's
like
most
of
the
changes
done
by
lee.
There
is
no
like
progress
there.
I
don't
know
its
current
status.
Express
graphql.
E
Yeah
for
a
way
one
is,
I
think
we
don't
have
like
too
much
pairs
back.
Then
all
the
epis
cleaned
up
an
idea
to
match
it,
and
I
want
to
write
the
same
merchant
to
graphql
js,
because
it's
simpler
to
maintain
one
repo
for
that
award
that
I
want
to
raise
this
question
somewhere
swati.
I
think
swagger
can
be
part
of
a
repo.
E
B
E
E
Crack
address
is
the
most
used.
One
I
think
like
express
graphql
is
like
graphical,
but
graphically
so
totally
different
story,
since
it's
like
another
working
group,
another
approaches
but
from
fraud.
What?
If
I
wonder
with
repo
it's
like
second
biggest
express
graph
here,
I
think
we
need
to
solve
this
problem,
I'm
just
like
for
starting
from
a
bigger
problem
and
seeing
what
what
we
can
do
and
when
apply
the
same
process
into
express
graphql.
E
If
we
see
like
it
work
out
and
people
reviewers
are
interested
in
reviewing
stuff
on
express
graphql,
we
can
apply
the
same.
We
can
either
if
they're
interested.
We
can
just
like
start
this
process
there
or
basically
like
from
my
side.
It
boils
down
to
two
questions.
First,
it's
experiment
and
I
want
to
make
scope
limited
and
most
impactful.
E
E
Yeah
yeah
yeah,
basically
at
least
on
graphql
js
like
I'm.
I
have
time
to
dedicate
it
to
you
active
contributors
and
people,
volunteering
to
do
reviews
yeah
so
yeah.
Let's
discuss,
I
think.
E
E
E
Yeah,
because
one
of
the
what
happened
with
graphical,
it's
like
was
the
same
attempt,
global
attempt
to
solve
issue,
and
that's
it.
Some
in
some
sense,
like
graphical.
E
E
E
E
E
They
like
main
responsibility
to
because,
right
now
we
have
some
like
prs
and
I
will
try
to
clean
them
up
so
not
to
over
burn
like
people
will
not
bring
them
on
every
year.
We
currently
have
they're
encouraged
to
do
that,
but
it's
not
that
something
something
they
obligated
to
do.
E
Basically
and
another
thing:
it's
like
sparkle
issues.
I
will
explicitly
say
it's
not
like
until
some
point
spakarevshi
is
mainly
discussed
in
a
working
group,
so
without
doing
exclusions.
I
think
in
a
week
is
a
reasonable
time
to
start
it,
especially
since
we
cut
release
as
for
automatic
some,
some
of
like
points
automatic
releases
and
stuff.
It
can
take
some
time
of
having
like
a
boat
somebody
volunteers
to
do
it.
It's
it's
great.
If
not,
it
can
be
done.
E
E
Yeah,
but
I
don't
want
to
make
it
from
from
a
word
you
know
like
it
should
be
something
written.
Otherwise,
it's
basically
yeah.
We
discuss
the
basic
rules,
so
basic
rules
are
I
like
that,
be
encouraged
to
review
any
past
present
future
prs
anything.
You
see
beef
like
48
hours
passed,
and
there
is
not
it's
not
much.
E
E
Press
approve
is
basically
means
countdown
starts,
and
in
in
two
weeks
they
are
get
like
merged.
It
can
be
matched
by
anybody
with
write
access
with,
basically
a
text
that
I
want
to
write,
but.
D
E
I
wanted
in
a
written
form
because
it's
hard
to
discuss
something
from
from
from
words,
I
think
yeah,
it's
better
to
have
a
feedback
discussion
and
having
some
draft
yeah,
but
I
want
to
keep
it
simple
and
plus
there
is
like
some
minor
stuff.
I
need
to
clarify
work.
You
should
not
spend
weight
if
you
don't
want
to
you,
shouldn't,
spend
too
much
time
on
what
was
the
priority
of
reviewing.
E
E
If,
if,
if
we
publish
issue-
and
anybody
have
like
better
idea-
or
we
have
a
discussion
around
something
and
or
something
not
work
in
the
future,
we
can
always
edit
issue,
especially
since,
like
all
the
reviewers
have
like
dredge
roles,
so
you
can
add
edit
like
issue,
so
I
think,
but
at
the
same
time
you
can
see
history
who
made
the
what
I
just
think
it
will
work
out.
E
So
answering
your
question:
it's
a
one
week,
time
frame
and
mainly
to
to
like
transcribe
rules
and
write
a
text
and
having
people
basically
sign
under
it
to
become
reviewer
technically
we
have
like
people
agreed,
but
I
want
them
to
be
to
read
the
document
and
help
go
on.
It
sounds
good.
E
Yeah,
I
will
try.
I
I
yeah.
Actually
it's
like
working
group
is
more
than
a
week.
It's
a
week.
Yeah.
You
know
what
what
started
if
yeah
it
should.
I
don't
see
any
reason.
Why
not
one
thing
I
need
to
prepare
like
a
talk
from
scratch,
it's
for
graphql
summit,
so
it
will
take
some
of
my
time,
but
I
don't
want
to
make
this
document
big,
so
yeah.
E
B
C
E
F
Yeah
there
was
one
issue
yaakov
here,
one
issue
that
I
wanted
to
just
touch
base
with
you.
If
this
has
gone
on
too
long,
you
want
to
do
it
offline,
that's
totally
fine!
I
I
was
just
curious
again.
I
know
we
talked
briefly
about
how
the
plan
is
to
at
previous
working
groups.
F
The
plan
is
that
the
main
branch
for
graphql
gs
will
become
the
unstable
branch
and
then
and
then
any
any
changes
there
that
are
desired
will
be
back
ported
to
like
v16
or,
I
guess,
even
further.
F
D
F
The
release
what
the
release
cadence
would
be
meaning
my
now,
because
now
that
I
think
about
it,
you
know
I
we,
if
we're
hopefully
going
to
cut
a
v16,
you
know
pretty
soon.
I
I
would
hope
that
now
the
sort
of
floodgates
could
sort
of
open
up
on
getting
incremental
delivery
out
there
as
soon
as
possible,
but
that
would
probably
require
some
breaking
changes.
So
in
theory,
I
would
like
to
see
that
you
know
roaring
forward
like
in
a
couple
weeks.
Even,
but
is
that
is
that
the
plan.
E
Yeah,
so
idea
is
actually
to
do
it
and
it's
also
connected
to
the
velocity
of
repo
one
thing:
it's
hard
to
figure
out
even
for
a
person
familiar
with
codebase,
it's
hard
to
figure
out.
What's
breaking,
what's
not
in
because
people,
it's
proper
library,
people
use
all
kind
of
weird
hacks
or
or
stuff.
E
So,
with
pressure
of
understanding
what's
breaking
and
what's
not,
I
think
it's
hard
to
to
manage
with
with
automatic
release,
and
people
like
approving
people
will
not.
Basically
idea
is
two
people,
proof
pr
is
get
much
and
let's
break
something.
E
E
The
idea
is,
is
we
have
nightly
as
about
streaming
before
and
like
general
idea,
since
the
reference
implementation,
we
kind
of
should
go
for
a
best
outcome
so
best
like
end
result
and
figuring
how
to
go
there
because,
like
if
people
look
and
how
to
implement
another
language
that
should
not
look
into
like
legacy
stuff
or
hacks,
where
that
for
for
not
breaking
compatibility
with
something?
E
That's,
why
idea
of
stableman
in
case
of
stream
d4
idea
was
we
don't
know?
Can
we
add
that
breaking
or
not
so
idea
is
to
edit
as
fast
as
we
can?
Maintaining
one
thing,
it's
experimental
feature
is
not
stage
two,
so
not
all
the
corner
cases
figure
out,
so
we
edit
it
on
main.
E
We
have
people
testing
it
as
a
nightly,
build
providing
feedback,
and
we
will
see
if
it
breaks
something
or
not.
If
it
breaks
something-
and
we
can
do
and
feature
stabilize
like
features,
are
proved
to
be
a
stage,
I
think
stage
two
yeah
stage
two
is
needed
to
to
be
much.
So
if
a
feature
is
stage
two
and
we're
sure
it's
like
stable,
we
will
start
thinking
about
back
porting.
E
If
we
can
do
back
parting
without
breaking
things,
it
just
goes
there.
If
it's
required
breaking
change,
we
can
do
breaking
change
specifically
for
stream
d4.
I
think
I
think
people
will
be
excited
enough
about
stream
g4
to
even
handle
like
unexpected
breaking
change,
so
ideally
to
go
on
16,
but
put
it
on
16
or
15
that
somebody
wanted
to
do.
If
I
cannot
do
it,
it's
like
it
can
be
like
17
with
just
streaming
d4.
F
Okay,
I
I
I
think
I
I
think
I
understand
I
just
would
point
out
that
in
the
current
in
the
current
you
know,
deferred
stream
branch
that
rob
and
the
team
at
first
dibs
and
and
others
have
worked
on.
There
are
breaking
changes
in
the
collect
fields.
You
know.
D
F
You
know
just
because
now
collects
fields
and
patches
and
there's
you
know,
I
guess
semi
obviously
breaking
changes
in
terms
of
the
types
that
are
returned,
so
it's
sort
of
like
a
typescript
breaking
change
so
and
and
my
vote.
You
know
not
that
it
not
that
it
counts
for
much.
But
my
vote
is
just
that
last
option
that
you
said.
I
think
people
would
be
pretty
excited
about
incremental
delivery
and
you
know,
even
if
you
know
if
they
required
another.
F
You
know
b17
fairly
sooner
than
you
know
much
much
sooner
than
the
gap
between
v15
and
v16.
I
think
that
would
be.
That
would
be
great
and
I
think
it's
you
know
just
because
we
have
definitely
have
contributor
a
time
crunch
on
many
of
the
people
involved.
You
know,
even
if
it
might
be
possible
to
make
it
non-breaking.
I
don't
think
that
should
be.
You
know
just
again
my
own,
my
own
personal
opinion.
I
don't
think
that
should
be
the
first
priority,
but
if
it
is
possible,
I
guess
sure
but
yeah,
but.
F
To
hear
that
you're,
considering
that
that
second
option
too
okay.
E
Yeah
yeah,
so
definitely
it's
not
like.
We
need
to
wait
like
a
year
or
something
to
get
it
ideal,
but
one
thing
to
clarify
expectation:
it
should
be
reach
stage
2
in
working
group.
So
until
it's
reach
stage
2
there,
we
cannot
make
something
non-experimental
and
another
clarifying
note
yeah.
E
I
will
add,
but
I
I
don't
want
a
bunch
of
flux
everywhere,
but
I
think
validation,
rule
preventing
three
main
default
directives
to
be
executed
by
default
is
enough
to
to
all
people
running
servers
to
make
decisions
otherwise,
like
even
on
nightly,
if
somebody
decides
trying
stuff
on
nightly,
they
need
to
add
her
to
extremely
for
being
experimental
and
about
back
portion
of
cutting
releases.
Only
after
stage
2
in
spec
release
process.
E
So
I
assume
yes,
anything
else.
We
we
need
to
do
I'm
sorry
about
this
code
taken
too
long
anything
else.
We
need
to
discuss.